Jump to content

  • Log In with Google      Sign In   
  • Create Account

Performance with different compilers


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
21 replies to this topic

#1 broady   Members   -  Reputation: 119

Like
0Likes
Like

Posted 06 July 2011 - 04:59 AM

Hello gd people,
i had my c++/opengl project running fine on CodeBlocks (with MINGW compiler). The debugger but was not so handly so i decided to move all the code in VS2010 Express edition.

The code is for the 99.9% the same. The 0.1% difference comes from stuff that compiles on CB and not in VS and i had to change.

My program is a win32 project. In the strarting it has to do lot of calcs because it has to build a mesh representing an image. The mesh is a complex object containing members like stl Vectors of pointers to vertices, edges, faces etc...

Why the hell when i run the program in VS it takes much longer respect to CB? Of course i run everything in release. Once the mesh is builded i cant notice any different in performance.
But at the start, before the first image appears in the drawning window, we speak of 1-2 seconds in CB versus 10-15 seconds in VS.
Might be express edition the problem?

Thanks fellows!
Riziero

Sponsor:

#2 Hodgman   Moderators   -  Reputation: 30388

Like
2Likes
Like

Posted 06 July 2011 - 05:07 AM

By default, MSVC generates debug-safety code for STL containers (even in release builds), which makes iterating over them (and other operations) excessively slow.

In your projects properties, you want to add the definitions:
_SCL_SECURE_NO_WARNINGS
_SECURE_SCL=0

#3 BitMaster   Crossbones+   -  Reputation: 4098

Like
0Likes
Like

Posted 06 July 2011 - 05:08 AM

Are you running a debug or release build when you measure those times?

Nevermind.

#4 AndyEsser   GDNet+   -  Reputation: 386

Like
0Likes
Like

Posted 06 July 2011 - 05:40 AM

Are you running a debug or release build when you measure those times?


He did say he's running in Release when measuring the times.

I would go with Hodgmans suggestion.

#5 broady   Members   -  Reputation: 119

Like
0Likes
Like

Posted 06 July 2011 - 06:02 AM


Are you running a debug or release build when you measure those times?


He did say he's running in Release when measuring the times.

I would go with Hodgmans suggestion.


Thanks for fast reply.
I will try when i am back to homeand let you khnow :D

#6 zacaj   Members   -  Reputation: 643

Like
0Likes
Like

Posted 06 July 2011 - 06:28 AM

Thats pretty wierd. Without even adding that setting, my speed in VC2010 is about 3x codeblocks when both are in the default release modes

#7 SiCrane   Moderators   -  Reputation: 9598

Like
1Likes
Like

Posted 06 July 2011 - 06:59 AM

By default, MSVC generates debug-safety code for STL containers (even in release builds), which makes iterating over them (and other operations) excessively slow.

In your projects properties, you want to add the definitions:
_SCL_SECURE_NO_WARNINGS
_SECURE_SCL=0

Actually, that only applies to MSVC 2005 and 2008. In MSVC 2010 _SECURE_SCL is disabled by default in release builds. Also, _SCL_SECURE_NO_WARNINGS has no performance impact.

#8 fastcall22   Crossbones+   -  Reputation: 4334

Like
0Likes
Like

Posted 06 July 2011 - 08:48 AM

Try running your program through a profiler (such as AMD's CodeAnalyst) to get a better look under the hood.
c3RhdGljIGNoYXIgeW91cl9tb21bMVVMTCA8PCA2NF07CnNwcmludGYoeW91cl9tb20sICJpcyBmYXQiKTs=

#9 cstony   Members   -  Reputation: 410

Like
1Likes
Like

Posted 06 July 2011 - 09:12 AM

How are you running your app? If from within the IDE make sure you use CTRL-F5 (start without debugging) as opposed to just F5 (Debug).

#10 Andrew Kabakwu   Members   -  Reputation: 728

Like
0Likes
Like

Posted 06 July 2011 - 09:53 AM

By default, MSVC generates debug-safety code for STL containers (even in release builds), which makes iterating over them (and other operations) excessively slow.

In your projects properties, you want to add the definitions:
_SCL_SECURE_NO_WARNINGS
_SECURE_SCL=0


How do you do this? Under which section?

#11 SiCrane   Moderators   -  Reputation: 9598

Like
0Likes
Like

Posted 06 July 2011 - 09:56 AM

You would set those in the preprocessor definitions.

#12 broady   Members   -  Reputation: 119

Like
0Likes
Like

Posted 06 July 2011 - 11:01 AM

How are you running your app? If from within the IDE make sure you use CTRL-F5 (start without debugging) as opposed to just F5 (Debug).


Thanks mate it worked. Where is defined the CTRL+F5 shortcut?
Thanks a lot.

EDIT: if i build and run my project from outside the ide its equal to launching with CTRL+F5 from inside VS?

#13 zacaj   Members   -  Reputation: 643

Like
0Likes
Like

Posted 06 July 2011 - 11:55 AM

Yes. CTRL+F5 (which I bind to F6 for ease of use) is run without debugging (basically just running the exe)

#14 cstony   Members   -  Reputation: 410

Like
0Likes
Like

Posted 06 July 2011 - 12:01 PM

Thanks mate it worked. Where is defined the CTRL+F5 shortcut?
Thanks a lot.


You can see if in the Debug drop-down menu. Or do you mean where is the keyboard mapping defined? If so :

Tools->Customize, Click the keyboard button. Scroll down to Debug.StartWithoutDebugging in the next window and you can see the keyboard shortcut and change it if you wish.


EDIT: if i build and run my project from outside the ide its equal to launching with CTRL+F5 from inside VS?


Yes

#15 broady   Members   -  Reputation: 119

Like
0Likes
Like

Posted 06 July 2011 - 05:46 PM

yes i was expecting to see ctrl+F5 in the debug menu. Its not there, at least by default.

#16 taz0010   Members   -  Reputation: 275

Like
0Likes
Like

Posted 07 July 2011 - 03:54 AM

Is your startup code very heavy on memory allocation? Some parts of my program incur almost twice as much overhead within the IDE in release mode due to the debug allocators (which are only used when running inside the IDE, so don't worry).

Also are you compiling with SSE extensions and the floating point model set to fast? The default settings (no SSE, fp:precise) are extremely slow (factor of 4-5x) when doing heavy work with floating point values.



#17 Cambo_frog   Members   -  Reputation: 712

Like
0Likes
Like

Posted 07 July 2011 - 06:08 AM

yes i was expecting to see ctrl+F5 in the debug menu. Its not there, at least by default.


It should be. The menu item is titled " Start Without Debugging Ctrl + F5".

I have pro version of VS2010, but I can't see it being any different in the express version.
For the love of god, please tell me that you've just omitted your error checking code for brevity, and you don't really assume that all those functions succeed.

#18 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 07 July 2011 - 06:40 AM

The code is for the 99.9% the same.

The code you see is 99% the same. In reality, your entire codebase represents the 0.01%. The first large invisible part is standard library aka the STL, which is compiler specific and implemented independently. Then there is compiler itself. Final unknown is the operating system. Depending on what gets linked and how, resulting executable could be using different parts of OS. One reason for this might be that MSVC will be up to date with latest "secure" versions while gcc-based ones would use older versions.

But as far as low hanging fruit goes:

The heuristics of std::vector implementation (and other containers) differ between MSVC and gcc. One of likely causes would be not sizing them at the beginning. Additional resizing could add to performance issues. This may require some code change, but tends to be biggest algorithmic gain. Preallocating can result in up to factor of 10 improvement in some cases.

Another factor would be how operator new/malloc are implemented. MSVC's was improved over time, but it does not strictly prioritize running time. If there are many allocations, this would be lead to overall increase in running times. If you use new frequently for small objects (<16 bytes), then gcc is likely to behave better. MSVC and underlying WinAPI syscalls do not prioritize small allocations by default. It depends on choice of containers.

std::string and vector in MSVC are coded (IIRC) slightly more defensively, so they tend to have bulkier operations. While they were algorithmically better, there are many cases where they could take longer than GCC equivalent. I don't know if this is still true.

#19 broady   Members   -  Reputation: 119

Like
0Likes
Like

Posted 07 July 2011 - 07:09 AM

The code is for the 99.9% the same.

The code you see is 99% the same. In reality, your entire codebase represents the 0.01%. The first large invisible part is standard library aka the STL, which is compiler specific and implemented independently. Then there is compiler itself. Final unknown is the operating system. Depending on what gets linked and how, resulting executable could be using different parts of OS. One reason for this might be that MSVC will be up to date with latest "secure" versions while gcc-based ones would use older versions.

But as far as low hanging fruit goes:

The heuristics of std::vector implementation (and other containers) differ between MSVC and gcc. One of likely causes would be not sizing them at the beginning. Additional resizing could add to performance issues. This may require some code change, but tends to be biggest algorithmic gain. Preallocating can result in up to factor of 10 improvement in some cases.

Another factor would be how operator new/malloc are implemented. MSVC's was improved over time, but it does not strictly prioritize running time. If there are many allocations, this would be lead to overall increase in running times. If you use new frequently for small objects (<16 bytes), then gcc is likely to behave better. MSVC and underlying WinAPI syscalls do not prioritize small allocations by default. It depends on choice of containers.

std::string and vector in MSVC are coded (IIRC) slightly more defensively, so they tend to have bulkier operations. While they were algorithmically better, there are many cases where they could take longer than GCC equivalent. I don't know if this is still true.


Thanks for your time it's a good reading.




#20 Aressera   Members   -  Reputation: 1419

Like
0Likes
Like

Posted 07 July 2011 - 12:22 PM

I'm having a similar issue with the sound propagation simulation library I'm developing: Compiling with GCC under Xcode I'm getting around 50fps, while when compiling using MSVC it runs at around 37fps. I'm dual-booting the same computer and compiling with all optimizations turned on in release mode for both platforms. I tried the 'run without debugging' option and didn't notice any improvement. My project doesn't make any use of STL so I can't blame different implementations. I'll also note that I'm heavily using the __forceinline directives for each compiler, so I don't think that it could be differences in inlining strategies.

Could it be that GCC's optimizer is better than MSVC's? Does anyone have any ideas for how I could improve the performance of my system when compiling using MSVC? I suppose I could always use GCC to compile under windows if I had to...




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS