User forums > Using Code::Blocks

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

(1/4) > >>

nestumkiller:
Hi!

I've installed recently Code::Blocks and created a new project (not imported) - Win32App - getting some files that I already had in a VS2005.
After removing the #include <stdafx.h> of all of them, I compiled the code, run it and... a difference of +- 800FPS comparing to VS2005, yes, you read it correctly.
In VS2005 for the same code (the difference is mainly on the precompiled headers) I had 30FPS and now, when I run it on Code::Blocks: +-800FPS.
Somebody has an idea of what could make such a difference? It's incredible!! I would really appreciate to know something regarding that.
Thanks

thomas:
Nobody will be able to tell for sure, but if you did not change any other code, it is probably a systemic error, not an actual speed improvement. It is not probable that gcc is 26 times faster than the MSVC compiler under the same conditions.

The most likely reason is you compared debug mode with vertical sync enabled against release mode without vsync.

Debug mode can be a lot slower than release, and it is well possible that you just get over the 16.6 ms per frame threshold, and pronto, you only draw on every other vblank = 30 fps.

As a sidenote, frames per second is a bad measure that you should not use. Frame times are much better as a measure since they are linear.

nestumkiller:
Hi again!

Well, I also checked the release/debug part. In VS I was actually under debug mode. However, I did the same in Code::Blocks by generating debug information and putting a breakpoint (just to make sure :)). Regarding the vsync. I don't have single clue about it. How and where can it be enabled/disabled? Do you have any suggestion on where/how could I try to do some modifications in order to find the source of such a colossal difference?
Thanks for the tip about frame times.
BTW, since the code I'm using almost doesn't use openGL: it's some Lab code for a course Introduction To CG. So, I'm doing all the culling/shading/transformation "by hand". I only use openGL for the rendering, using simple primitives as glVertex with GL_LINES and GL_TRIANGLES. Could the bottleneck be around something else but openGL? Like STL usage, or other stuff?

Vampyre_Dark:
VSync can be toggled on and off in your videocard settings. Or it can be toggled in GL using an extension ext_gl_swap_interval() I think (been awhile). But the driver can be set to overide this, so check your driver options first.

You can have an OpenGL app that just clears the screen running @ 1000fps, and then draw one triangle and drop to 100 fps. It doesn't mean anything. Wait until you are actually using the gfx card properly, and sending proper batches in the proper order to minimize state changes to see what your actual FPS is going to be.

Also, glVertex, glLines, and glTriangle ARE a bottleneck. Using these is what is known as immediate mode. It's slow, and it's not what you use when you are programming with performance in mind. You will use vertex arrays for that.

You will want to sort your data by shader/texture and set these once per batch. Then you send over a vertex array containing all the triangle data using that shader and texture. Then you stop, set the new shaders, textures and any other options, and send over all the triangles using those new options.

*I say triangles just to keep my example brief, it could be any primitive type...

thomas:

--- Quote from: Vampyre_Dark on May 04, 2006, 01:27:11 am ---You can have an OpenGL app that just clears the screen running @ 1000fps, and then draw one triangle and drop to 100 fps. It doesn't mean anything.
--- End quote ---
That's why I said you should use frame times. Differences in frame times are much more meaningful and intuitive.

The reason why I suggested that VSync might be involved is that this is a common experience which baffles a lot of people. "Uh.... it just ran at 60 fps, and now it runs at 30 fps, I did not really change a lot, why does it drop to 50%?". The answer to this is that they had a frame time of maybe 16.5 ms before and 16.7 or 16.8 afterwards. If your monitor has a refresh of 60 Hz, one frame is 16.666 ms. If you are done before that time, you're fine. Otherwise, you'll wait for the next sync. Thus, even if your frame time only changes insignificantly, if it crosses the "magic border", then your frame rate will suddenly drop by 50%. Many people are surprised to see that happen, as it is not intuitive, but it is perfectly logical.

As Vampyre_Dark already said, it can be tricky to turn on/off vsync as the drivers may or may not allow you to. Speaking of driver preferences, you're sure that you did not inadvertedly turn on 16x antialiasing on one PC and none on the other, aren't you :)

Immediate mode calls are slow, granted. However, on reasonably recent hardware this does not matter too much (remember, you do not intend to program an action game). I've seen demos that draw surprisingly large scenes entirely in immediate mode and still obtain high frame rates (100-150 FPS). If you're just doing some teaching demo stuff, then putting a lot of time into vertex buffer objects and sorting objects for shaders and textures may be a waste of time.

Regarding your question on the STL, this highly depends on your usage. If you use the STL "correctly", then it should not matter too much, as both implementations probably use nearly the same algorithms and have comparable run times for the same operations.
However, it is of course possible that seemingly unimportant differences make a huge difference in extreme cases. The classical example for "stupid" STL usage in CG is to store vertices in a vector and do 1,000,000 push_back() operations each frame. In this case, a STL implementation that reallocates larger chunks of memory will be a *lot* faster (but you should of course not do that at all in the first place).

There are techniques to locate bottlenecks, both nVidia and ATI have papers on that.
The most obvious one is to use a profiler, if all your CPU time goes into some library that you don't know, then it is the OpenGL driver choking on your immediate mode calls :)
Another possibility is to use identical GPUs on different CPUs and vice versa.
A quick and easy way to check whether you're fillrate limited is to resize the window (unluckily, it is not that easy for all other bottlenecks).

Navigation

[0] Message Index

[#] Next page