CODEWITHSUNDEEP
c++openglg++gprof
E.Benoît
E.Benoît

Reputation: 806

C++ performance weirdness w/ OpenGL

I am rewriting some rendering C code in C++. The old C code basically computes everything it needs and renders it at each frame. The new C++ code instead pre-computes what it needs and stores that as a linked list.

Now, actual rendering operations are translations, colour changes and calls to GL lists.

While executing the operations in the linked list should be pretty straightforward, it would appear that the resulting method call takes longer than the old version (which computes everything each time - I have of course made sure that the new version isn't recomputing).

The weird thing? It executes less OpenGL operations than the old version. But it gets weirder. When I added counters for each type of operation, and a good old printf at the end of the method, it got faster - both gprof and manual measurements confirm this.

I also bothered to take a look at the assembly code generated by G++ in both cases (with and without trace), and there is no major change (which was my initial suspicion) - the only differences are a few more stack words allocated for counters, increasing said counters, and preparing for printf followed by a jump to it.

Also, this holds true with both -O2 and -O3. I am using gcc 4.4.5 and gprof 2.20.51 on Ubuntu Maverick.

I guess my question is: what's happening? What am I doing wrong? Is something throwing off both my measurements and gprof?

Upvotes: 0

Views: 338

Answers (2)

Julien Guertault
Julien Guertault

Reputation: 1334

Without more information, it is difficult to know what is happening here, but here are a few hints:

  • Are you sure the OpenGL calls are the same? You can use some tool to compare the calls issued. Make sure there was no state change introduced by the possibly different order things are done.
  • Have you tried to use a profiler at runtime? If you have many objects, the simple fact of chasing pointers while looping over the list could introduce cache misses.
  • Have you identified a particular bottleneck, either on the CPU side or GPU side?

Here is my own guess on what could be going wrong. The calls you send to your GPU take some time to complete: the previous code, by mixing CPU operations and GPU calls, made CPU and GPU work in parallel; on the contrary the new code first makes the CPU computes many things while the GPU is idling, then feeds the GPU with all the work to get done while the CPU has nothing left to do.

Upvotes: 1

IronMensan
IronMensan

Reputation: 6831

By spending time in printf, you may be avoiding stalls in your next OpenGL call.

Upvotes: 3

Related Questions