• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
broady

Performance with different compilers

21 posts in this topic

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
0

Share this post


Link to post
Share on other sites
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:
[font="'Courier New"]_SCL_SECURE_NO_WARNINGS[/font]
[font="'Courier New"]_SECURE_SCL=0[/font]
2

Share this post


Link to post
Share on other sites
[s]Are you running a debug or release build when you measure those times?[/s]

Nevermind.
0

Share this post


Link to post
Share on other sites
[quote name='BitMaster' timestamp='1309950516' post='4831721']
Are you running a debug or release build when you measure those times?
[/quote]

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

I would go with Hodgmans suggestion.
0

Share this post


Link to post
Share on other sites
[quote name='AndyEsser' timestamp='1309952415' post='4831730']
[quote name='BitMaster' timestamp='1309950516' post='4831721']
Are you running a debug or release build when you measure those times?
[/quote]

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

I would go with Hodgmans suggestion.
[/quote]

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

Share this post


Link to post
Share on other sites
Thats pretty wierd. Without even adding that setting, my speed in VC2010 is about 3x codeblocks when both are in the default release modes
0

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1309950450' post='4831720']
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:
[font="'Courier New"]_SCL_SECURE_NO_WARNINGS[/font]
[font="'Courier New"]_SECURE_SCL=0[/font]
[/quote]
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.
1

Share this post


Link to post
Share on other sites
Try running your program through a profiler (such as [url=http://developer.amd.com/tools/codeanalyst/pages/default.aspx]AMD's CodeAnalyst[/url]) to get a better look under the hood.
0

Share this post


Link to post
Share on other sites
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).
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1309950450' post='4831720']
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:
[font="Courier New"]_SCL_SECURE_NO_WARNINGS[/font]
[font="Courier New"]_SECURE_SCL=0[/font]
[/quote]

How do you do this? Under which section?
0

Share this post


Link to post
Share on other sites
You would set those in the preprocessor definitions.
0

Share this post


Link to post
Share on other sites
[quote name='_Unicron_' timestamp='1309965124' post='4831813']
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).
[/quote]

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?
0

Share this post


Link to post
Share on other sites
Yes. CTRL+F5 (which I bind to F6 for ease of use) is run without debugging (basically just running the exe)
0

Share this post


Link to post
Share on other sites
[quote name='broady' timestamp='1309971708' post='4831870']
Thanks mate it worked. Where is defined the CTRL+F5 shortcut?
Thanks a lot.
[/quote]

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.


[quote name='broady' timestamp='1309971708' post='4831870']
EDIT: if i build and run my project from outside the ide its equal to launching with CTRL+F5 from inside VS?
[/quote]

Yes
0

Share this post


Link to post
Share on other sites
yes i was expecting to see ctrl+F5 in the debug menu. Its not there, at least by default.
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
[quote name='broady' timestamp='1309995970' post='4832020']
yes i was expecting to see ctrl+F5 in the debug menu. Its not there, at least by default.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
[quote]The code is for the 99.9% the same.[/quote]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.
0

Share this post


Link to post
Share on other sites
[quote name='Antheus' timestamp='1310042423' post='4832233']
[quote]The code is for the 99.9% the same.[/quote]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.
[/quote]

Thanks for your time it's a good reading.


0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
[quote name='Aressera' timestamp='1310062951' post='4832407']
I'll also note that I'm heavily using the __forceinline directives for each compiler[/quote]

There is next to no reason to use any kind of inline indications anymore. The heuristics behind optimizing compilers these days make them obsolete and forcing inlines will typically do more harm than not.

When it comes to inlining, the much more productive route is to understand why branching and function calls cost and how to avoid them. A typical example is:[code]
if (not_enough_space(current, max)) {
resize(2*max);
}
add_element(...);[/code]

Unfortunately, this tends to be the default and most sensible way containers are written. But it goes against CPU-friendly code flow. Branches should prefer to take the common path as default, whereas resizing of container will be not only the undesired path but also something that will run at most n times.

The alternative might behave better:[code]
if (has_enough_room()) {
add_element();
return;
}
resize(2*max);
add_element();[/code]An important observation here is that add_element might or might not be inlined. Having smaller code that takes expected path might run better despite potentially having extra function calls.

It is effectively impossible for a human to perform inlining optimizations on today's CPUs. And definitely ban use of forced inlining, It can do no good, at most it will offer minimal improvement on a microbenchmark but preventing or harming the bigger picture.

Even at this level, algorithm trumps micro optimizations. Algorithms merely refer to how CPU works rather than what C++ code says.


Also, we're bikeshedding again, this type of optimizations are not done in real world.

[quote]Could it be that GCC's optimizer is better than MSVC's?[/quote]No. gcc is generally worse than any of other commercial compilers. But, the compiler differences amount to a single-digit percent in performance. Losing 25% at application is unlikely.

[quote]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...[/quote]
#1 cause - difference in drivers. I've experienced a factor of 50 difference on same machine, simply due to drivers.

Since the project is portable it likely uses OGL. Some Windows drivers have abysmal OGL support.
0

Share this post


Link to post
Share on other sites
Ok, so I tried compiling in MSVC with regular inlining and saw a small but negligible performance drop. It can't be an OpenGL driver issue because I've isolated the timing for graphics/sound simulation so I only get the time reported for the sound portion (I'm not doing anything graphically intensive anyway). The sound stuff is totally isolated from any system libraries (most of the time is spent doing ray tracing). I even tried changing the floating point model to fpfast and trying different optimization option but to no avail.

I think I might try compiling with GCC under windows and see if that makes any difference.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0