11-Way Intel Ivy Bridge Compiler Comparison

[China_Guy]

Indeed nice article. Any chance of also testing the intel c/c++ compiler?

Intel C++ Compiler mostly is best optimized Compiler on planet in Intel platform, but it is proprietary and close source. GCC is on second place immediately, Only subordinate to Intel C++.

　

Regarding Clang??? Crappy clang has always been stupid rubbish shit!!!

[AnonymousCoward]

SOn some hardware due to PGO you can get ridiculously high speedups; Michael, why are you consistently ignoring this great (and free!) optimization?

How is PGO free if you have to recompile your application after running it with a representative load (and finding that in the first place)?

[curaga]

Well obviously not on sparc or arm or so. But it would be interesting to see if the generated binaries would also be faster on AMD hardware.

You've been under a rock perhaps? The binaries by ICC will suck on AMD, VIA and anything else non-Intel x86. See Agner's site for insightful explanations, including benchmarks where he changes his Via to introduce as Intel.

[ninez]

How is PGO free if you have to recompile your application after running it with a representative load (and finding that in the first place)?

I think he means 'free' as in 'libre' ... and regardless, it is still free even if you have to do some extra work. (vs. ICC which is not free)

As a side note: Firefox is compiled with PGO. I used to have to manually compile Firefox to use PGO ~ and the difference was very noticeable in some situations. However, from what i have seen/the impression that i have gotten is that the source code of a given app has to support it.

LTO (Link time optimization) has stabilized in GCC 4.7 ~ it would be interesting to see some benchmarks showing differences there (between non-lto and lto binaries)... LLVM also has LTO, which if i remember correctly is enabled by using the -04 flag. (it might be interesting to compare those too)

@Michael - how about an 11-way AMD compiler comparison?

[elanthis]

Intel C++ Compiler mostly is best optimized Compiler on planet in Intel platform, but it is proprietary and close source. GCC is on second place immediately, Only subordinate to Intel C++.

　

Regarding Clang??? Crappy clang has always been stupid rubbish shit!!!

Except that GCC has always been "stupid rubbish shit" -- and has _intentionally_ been that way due to RMS's paranoia -- except for the barely-relevant part where it produces faster binaries than irrelevant compilers almost nobody uses (Open64) or a compiler that's practically an infant in comparison (Clang/LLVM). Clang matches the performance it took GCC 25 years to achieve, not to mention the fact that it has an equivalent level of language conformance and features (again, from zero to that complete in a teeny tiny fraction of the time it took GCC), plus the so-freaking-awesome toolset support it enables that GCC goes out of its way to make impossible to write.

In the few cases where binary performance in a few specialized micro-benchmarks actually matter, it's worth noting that GCC is still not even top dog, so it has the unpleasant distinction of being neither the faster compiler nor the more featureful, flexible, maintainable, extensible compiler. The only crown it can hold is "most popular compiler for UNIX systems." Yay.

Without Clang, the world of Open Source compilers would be stuck forever with glorified Notepad apps (Vim, Emacs) and a practically tools-free development environment. With Clang, the FOSS scene actually has a chance to start playing catch-up to Visual Studio / VAX. There's a chance to have actually useful code completion (real-time, no need to regenerate ctags and wait 5 minutes for it to complete), to have powerful code refactoring (nobody but VS/VAX has this yet, which is why it's so important for FOSS to catch up), and most importantly to have a compiler that provides a valid test ground for new language extensions and features to propose to the relevant committees (GCC is a nightmare to extend, maintain, learn, or improve; only a small handful of people can deal with its horrific internals). This is of course why just about every company on the planet with an interest in C/C++ have gotten involved with Clang: it is a massive improvement on all fronts that _actually matter_, and the performance of compiled binaries non-issue can be improved as time goes on (and again, it has improved at a much MUCH faster rater than GCC has).

But thanks anyway for your input as a non-developer fanboy. The world would such a worse place without your clueless rants and abuse of fonts.

[89c51]

off topic but i think that i have developed a thing for elantis's rants

[johnc]

I remember quite a lot of fuss was made about that EKOPath compiler being open-sourced.

[XorEaxEax]

How is PGO free if you have to recompile your application after running it with a representative load (and finding that in the first place)?

It's certainly not free as in 'just adding another flag', as you stated you need to run the code between two compilations in order to produce the optimized binary.

However the whole 'representative load' thing doesn't really make any sense unless you have an application with vastly different code paths under different 'loads' (any examples?).

It's not as if while profile-optimizing a game, you would have to finish it in order to gain profiling performance increase. The game, just like basically any other application will consist of a main code path, it's 'engine' or 'main loop', and by simply playing the game for a short while you will 'touch' all the code areas which have an impact on performance which in turn will gather runtime data necessary for optimizing the code.

This profiling stage can of course be automated, and for applications which comes with PGO support when building like Firefox, x264, they have config variables which enables this automatic PGO stage.

However I agree that this lies outside the scope of a testsuite like Phoronix as it would be quite unrealistic to expect Micheal to write automatic profiling scripts for these tests. x264 as mentioned does have automated PGO building but it seems Micheal isn't using x264 in benchmarking anymore, likely because it showed little to no difference between compilers which in turn was because he refused to turn off hand-optimized assembly for this test, all it would need is './configure --disable-asm', not exactly rocket science.

PGO is an optimization which can yield tremendous results in cpu intensive code but it's certainly non-trivial to apply given that it relies on gathered runtime data, which is likely why it's generally only used in applications where the 'gathering' is automated.

Looking forward to seeing Dragonegg mature, it's one of those things that looks great in theory -'combining the optimization power of GCC and LLVM', but isn't really delivering in practice as of yet.

[XorEaxEax]

I remember quite a lot of fuss was made about that EKOPath compiler being open-sourced.

Yes, the code which I have been able to compile with ekopath have had underwhelming performance to say the least. Maybe it's because I have core i5/i7's and it's targeted primarily at AMD cpu's or that I've only yet tried nightlies which may not be representative of the 'real' product? I've tried different flags, the best results I had iirc was with '-Ofast -march=auto', maybe there are better?

[XorEaxEax]

Except that GCC has always been "stupid rubbish shit"

While I understand how someone can get really tired of trolls like China_guy etc who just go on about how clang/llvm is 'just suxx0rs' you are just another side of the same coin.

Your 'gushing like a schoolgirl' attitude concerning anything clang/llvm while spewing vitriol towards GCC is fucking sad, particularly since you actually have some technical knowledge.

With Clang, the FOSS scene actually has a chance to start playing catch-up to Visual Studio

Lol, yes well count me out of wanting a 'Visual Studio' experience.

The only crown it can hold is "most popular compiler for UNIX systems."

It's likely the most used compiler toolchain in the world, it generates the fastest code of the open source compilers and it supports the widest range of architectures and languages of all compiler toolchains. Stop making yourself look silly.

Without Clang, the world of Open Source compilers would be stuck forever with glorified Notepad apps (Vim, Emacs) and a practically tools-free development environment.

Bullshit, the reason lots of people use Vim, Emacs style development in *nix is because they WANT to use them. Those who don't can use solutions like Eclipse. The lack of a 'Visual Studio' top-down solution obviously hasn't hampered open source development as we can see from the huge amount of open source code and projects out there. I personally can't stand bloated IDE's like Visual Studio but each to his own.

and most importantly to have a compiler that provides a valid test ground for new language extensions and features to propose to the relevant committees (GCC is a nightmare to extend, maintain, learn, or improve; only a small handful of people can deal with its horrific internals).

'nightmare', 'horrific'... could you try any harder in exaggerating? If GCC was that bad then the LLVM/Clang devs should be fucking ashamed that it hasn't passed it in performance/supported systems during the 12 years (LLVM) and 7 years (Clang) they've been in development. The reality is of course that while LLVM is a more modern codebase GCC is nowhere as bad as you try to paint it, and is also improving with each release.

Now if we could have fanboys like you and China_guy just STFU and actually discuss these compilers rationally by objectively comparing their respective strenghts then this could turn out to be a worthwhile discussion.