Originally posted by Wilfred
View Post
Announcement
Collapse
No announcement yet.
11-Way Intel Ivy Bridge Compiler Comparison
Collapse
X
-
Last edited by China_Guy; 30 May 2012, 11:41 AM.
-
Originally posted by kiputnik View PostSOn some hardware due to PGO you can get ridiculously high speedups; Michael, why are you consistently ignoring this great (and free!) optimization?
Comment
-
Originally posted by Wilfred View PostWell 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.
Comment
-
Originally posted by AnonymousCoward View PostHow is PGO free if you have to recompile your application after running it with a representative load (and finding that in the first place)?
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?
Comment
-
Originally posted by China_Guy View PostIntel 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++.
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.
Comment
-
Originally posted by AnonymousCoward View PostHow is PGO free if you have to recompile your application after running it with a representative load (and finding that in the first place)?
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.
Comment
-
Originally posted by johnc View PostI remember quite a lot of fuss was made about that EKOPath compiler being open-sourced.
Comment
-
Originally posted by elanthis View PostExcept that GCC has always been "stupid rubbish shit"
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.
Originally posted by elanthis View PostWith Clang, the FOSS scene actually has a chance to start playing catch-up to Visual Studio
Originally posted by elanthis View PostThe only crown it can hold is "most popular compiler for UNIX systems."
Originally posted by elanthis View PostWithout Clang, the world of Open Source compilers would be stuck forever with glorified Notepad apps (Vim, Emacs) and a practically tools-free development environment.
Originally posted by elanthis View Postand 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).
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.
Comment
Comment