Hacker News Reader

Comment by vog | Hacker News Reader

What is preventing you from using MinGW? That way, you could use the GNU toolchain (Make, GCC, Binutils etc.) and still have full access to the Win32 API. You could reuse almost all of your Unix build scripts, and the rest boils usually down to making your scripts aware of different file extensions (.exe/.dll instead of /.so).

Even better, you can do cross compiling with MinGW. So if your toolchain dosn't perform well on Windows, just use GCC as a cross compiler and build your stuff on a Linux or BSD machine. Then use Windows for testing the executable. (On smaller projects, you usually don't even need Windows for that, since Wine does the job as well.)

(Full disclosure: I'm the maintainer of a Free Software project that makes cross compiling via MinGW very handy: http://mingw-cross-env.nongnu.org/)

View on HN

VC++ generates significantly better code than GCC. Enough so that performance-minded projects usually wouldn't consider MinGW/GCC for Windows code.

Does it matter during development though? You could always develop on GNU toolchain and then make a final build in VC once the feature code is complete.

Only if you are careful to only use the subset of the C++ spec supported by both compilers and avoid all gcc specific features.

I mentioned that in a context of application which is crossplatform already and when something is being developed, it affects (in most cases anyways) all platforms in the same way - so this limitation is "built-in" already.

In my experience, you don't have to be careful. I've written lot's of C++ that compile fine on Windows (using mingw/msys) or Linux/Mac using gcc. Can you provide an example of where gcc specific features are included w/o the developer explicitly doing so?

This is pretty common and not particularly difficult. Most large cross-platform C++ projects (ie most browsers and game engines) compile in both gcc and msvc. It is easy to naively write code in one compiler that won't build in another, but it's also easy to fix said code once you try to build it with another compiler.

Which might be a good choice for working on Chromium anyways, what with it being cross-platform :)

(Granted, there might be windows-specific stuff. I haven't checked the windows code)

They would be doing this anyway.

I actually don't understand the original poster's slowness with Windows. We use Perforce and VC++ .slns, sometimes with apps split into DLLs and get none of the slowness the poster talks about. Actually we get significantly better performance with this than under Unix with GCC. No-change or small change rebuilds take a few seconds, with the time being dominated by the link and proportional to the link size.

Please show me something to back this nonsense up.

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.

Reply on news.ycombinator.com