I'll also note that I'm heavily using the __forceinline directives for each compiler

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:
if (not_enough_space(current, max)) {
resize(2*max);
}
add_element(...);

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:
if (has_enough_room()) {
add_element();
return;
}
resize(2*max);
add_element();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.

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.

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.

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.