views:

170

answers:

2

Hi,

I have ported a piece of C++ code, that works out of core, from Linux(Ubuntu) to Windows(Vista) and I realized that it works about 50times slower on VS2008! I removed all the out of core parts and now I just have a piece of code that has nothing to do with the hard disk.

I set compiler parameters to O2 in Project Properties but still get about 10times slower than g++ in linux!

Does anybody have an idea why it is this much slower under VS?

I really appreciate any kind of hint!

Thanks,

+2  A: 

Do you use a lot of the standard C++ library? If so, you might want to turn off the "checked iterators" feature that is on by default in Visual C++ (even in Release mode). Put this before including any standard headers:

#define _SECURE_SCL 0

More info here.

Dean Harding
@Nima. Does this work? It sounds very likely.
Duracell
Wow, it's sounds so nice... Let me try it. :)
Nima
Actually, my code uses OpenGL(GLUT) and GLUI for the UI.Glui won't work if you run it in debug mode! (I dunno why, just read it somewhere... and it worked on release mode)Now, after adding the line you mentioned, it again gives me the same runtime error that I was getting by running it in Debug mode.It says:Unhandled exception at SOMEWHERE in FILE.exe: Access violation reading location SOMEWHERE.
Nima
Run the program in debug mode and try to figure out this problem first. You should always aim to make your program *correct* before you try to make it *fast*.
Dean Harding
It is correct. I was working, even on the same dataset, on Linux perfectly.And now, its runtime error is not related to my piece of code.at this line:right_panel = GLUI_Master.create_glui_subwindow( main_window, GLUI_SUBWINDOW_RIGHT );it crashes in debug mode, but passes in release mode.do you have a guess?It is the one of the most starting points of the code...
Nima
@Nima: If something crashes in debug mode, it generally means there is something wrong with the code. Remember that debug builds have significantly more checks in place, many of which _cause_ the application to crash when something is wrong. Those checks are taken out in a release build for performance reasons. That said, if your code crashes, that's usually a sign that it is not correct. Like I said above, start breaking your code down piece by piece and get small pieces working first before you try getting the whole thing working.
James McNellis
@James: I know but I see exactly where it crashes, and it has nothing to do with my code.Note that GLUI's code is done by a CS student... it is not very well maintained.And I found it somewhere (maybe on this site) that people has solved that issue by running it release mode!I know that it's a stupid solution for sure but seems to be the only way. However, it was working perfect in Linux.
Nima
+1  A: 

No need to guess. Just hit the "pause" button and look at the stack. The chance that you will miss the problem is 1/50. If you're not sure, do it several times.

Mike Dunlavey