User forums > Using Code::Blocks

HUGE openGL frame rate difference between Code::Blocks and VS2005

<< < (2/4) > >>

nestumkiller:
Hi guys!
Thank you again for the huge :) explanations, but I think you're missing a little bit the issue. Since my source code was precisely (well, I just removed the windows precompiled headers - stdafx.h - so I could compile it on Code::Blocks) the same, and I didn't enable/disable VSync on my graphics card, then it shouldn't be related to that, right? I though the VSync belonged to some sort of option in VS or even Code::Blocks (I never used it before, so... :P), that's why I asked where I could enable/disable it. Nevertheless, I found it.
Another important issue, is that the code was run on same machine: a Asus laptop with a Centrino 1.7, 1Gb Ram, well, and most importantly, an ATI Radeon X700 128Mb (fully dedicated). What bugs me the most is, supposing the VSync hasn't changed for Code::Blocks or VS, what could make this huge differences?
Regarding the performance, well, obviously I try to make it work quicker. But the fact here, is that I'm having the course and lecturing it. And since it's a Introduction to CG everything is very unefficient and slow. But changing from 30FPS to 800FPS? My VSync option is set like this: Default Off - so it should be disabled for both VS and Code::Blocks, right?

Finally, and of big importance, I noticed some time ago, that a major bottleneck on VS was related to the usage of STL and push_backs, yada yada yada. So, I tried to improve it as much as I could (or I know). When I skipped all those calls, my FPS really increased. Then I changed to Code::Blocks... and Et Voilà :D

thomas:

--- Quote ---major bottleneck on VS was related to the usage of STL and push_backs, yada yada yada. So, I tried to improve it as much as I could (or I know).
--- End quote ---
Yes, that's a common experience. STL is not free :)
It is quite possible, as mentioned before, that a slightly different STL implementation is significantly faster in extreme cases. In fact, if compiler and STL were really the only parameters that changed, then what else could it be :)

How can such gross differences between different STLs occur if they do the same thing?
For example, suppose both implementations start with a vector size of 5. One implementation reallocates in steps of n*1.5 elements, and the other in steps of n*2 elements. The implementation is not required to use a specific number, so the assumption that different implementations use different numbers is not unrealistic. Insignificant, one might say at first. Really?

What happens if you push_back 10000 elements? The first implementation would run this sequence:
5;8;11;17;25;38;57;85;128;192;288;432;649;973;1460;3284;4926;7389;11084.
while the other would run that one:
5;10;20;40;80;160;320;640;1280;2560;5120;10240
Remember that a new memory block is allocated and the whole dataset has to be copied every time. Allocations are slow, and worse, copying takes linear time.
Clearly, the second implementation will be a lot faster (even though it is still very, very inefficient).

Many people make claims like "the STL is evil" for reasons like the above. However, when people say that the STL is the problem, they are wrong almost every time. Rather, they are no using it correctly. For example, push_back is mostly harmless if you reserve appropriately. Actually, in that case, using vector is not any worse than using an array, only more comfortable and safer. Since you normally know the number of elements that you'll need (if not exactly, then at least approximately), that is usually not a problem.

Personally, I use STL a lot, and I bow to the people who wrote it. In almost every case, the STL is very close to or beats hand-written, optimised code, and you don't have to worry about the "hard stuff".
But one has to be aware that the functionality behind STL is no arcane magic, nor is it generally free. Especially when using containers in an inappropriate manner (or with inappropriate objects), the cost can be quite high. That's not a bug, though. That's due to design.

mandrav:
Don't forget that the choice of the right container for the job is a major optimisation one could perform.
For example, if you 're going to use push_front() on a std::vector a lot, think again. std::deque might fit the job better...
What I mean is learn about all the available containers, their strengths and weaknesses, and choose wisely which one you want to use.

Vampyre_Dark:
Not sure if I maybe misunderstood thomas' whole meaning here, but immediate mode always makes a difference! It's the difference between 1 function call per batch, and 9+ for every triangle.

When I toggle my app between immediate mode and using arrays with just 4400 triangles, there is a HUGE difference. That's (4400 * 9) calls in the place of the just 6 calls it takes me to get m 6 different types of objects drawn. Immediate Mode in my scene still operates around 60~ fp, however, I'm not using shaders or any advanced extensions. Using arrays I get into the ~100-200fps zone.

The difference becomes less negligable as the polygon count increases, because more and more time is wasted waiting on immediate mode call overhead to feed data one by one, and the card isn't functioning the way it was meant to (for performace) which is to operate on 1 large batch.


--- Quote ---That's why I said you should use frame times. Differences in frame times are much more meaningful and intuitive.
--- End quote ---
I agree. However, I say to wait, because people sometimes assume that after the initial drop in frames per second, that they will get an equal drop after every command they add. Which is not the case.

Here is a nice STL reference I have been using.

Michael:

--- Quote from: Vampyre_Dark on May 04, 2006, 02:47:59 pm ---Here is a nice STL reference I have been using.

--- End quote ---

Look interesting :).

I also find this one not bad at all:

http://www.sgi.com/tech/stl/

Best wishes,
Michael

Navigation

[0] Message Index

[#] Next page

[*] Previous page