How about you back up calling it nonsense?

We've done compiler tests between VC express 2010 and GCC (Mingw gcc 4.6.x branch) at work with GCC beating VC express at '-O3 -ffast-math -march=corei7' vs '/O2 /arch:SSE2' for our code on Intel Core i7 nehalem. GCC even beat ICC on certain tests on that same Intel hardware.

What we weren't able to compare between the compilers was link-time optimization and profile-guided optimization since Microsoft crippled VC express by removing these optimizations.

So when someone makes claims that 'VC++ generates significantly better code than GCC' I want to see something backing that up. Had I made a blanket statement that 'GCC generates significantly better code than VC++' someone would call me on backing up that aswell, and rightly so.

So when you didn't use the two most important perf features in MSC, its performance was underwhelming. This is no surprise.

Also, if you were doing anything heavily floating-point, MSC 2010 would be a bad choice because it doesn't vectorize. Even internally at Microsoft, we were using ICC for building some math stuff. The next release of MSC fixes this.

Well we obviously didn't enable PGO/LTO for GCC either when doing these tests as that would have been pointless.

It would have been interesting to compare the quality of the respective compiler's PGO/LTO optimizations (particularly PGO given that for GCC and ICC code is sometimes up to 20% faster with that optimization) but not interesting enough for us to purchase a Visual Studio licence.

And yes we use floating point math in most of our code, and if MSC doesn't vectorize then that would certainly explain worse performance. However this further denies the blanket statement of 'VC++ generates significantly better code than GCC.' which I was responding to.

I believe that at least one of the projects the original blog post mentioned - Chromium - can't be compiled with LTO or PGO enabled. Apparently the linker just runs out of memory with it and most large projects.

Well it makes sense that LTO would have high memory requirements given that the point of the optimization is to look at the entire program as one entity rather than on a file by file scope and I have no doubt this can cause problems with very large projects.

PGO on the other hand seems very unlikely to fail due to memory constraints, atleast I've never come across that happening, the resulting code for the profiling stage will of course be bigger since it contains profiling code but I doubt the compilation stage requires alot more memory even though it examines the generated profiling data when optimizing the final binary.

It seems weird that PGO would not work with Chromium given that it's used in Firefox (which is not exactly a small project) to give a very noticeable speed boost (remember the 'Firefox runs faster with windows Firefox binary under wine than the native Linux binary debacle'? That was back when linux Firefox builds didn't use PGO while the windows builds did.)

With respect, this is not how claims work. You can't make a claim and then expect your opponents to have the burden of proof to refute it.

If you make a claim such as 'GCC produces significantly worse code than alternate compiler A' then it's completely reasonable to ask for something to support it. Tone wise perhaps the post could have been improved, but the principle stands.