Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 33

Thread: 11-Way Intel Ivy Bridge Compiler Comparison

  1. #11
    Join Date
    Jan 2012
    Posts
    16

    Cool

    Quote Originally Posted by Wilfred View Post
    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!!!
    Last edited by China_Guy; 05-30-2012 at 11:41 AM.

  2. #12

    Default

    Quote Originally Posted by kiputnik View Post
    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)?

  3. #13
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,995

    Default

    Quote Originally Posted by Wilfred View Post
    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.

  4. #14
    Join Date
    Jun 2011
    Posts
    829

    Default

    Quote Originally Posted by AnonymousCoward View Post
    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?

  5. #15
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by China_Guy View Post
    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.

  6. #16
    Join Date
    Jan 2009
    Posts
    1,603

    Thumbs up

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

  7. #17
    Join Date
    May 2011
    Posts
    1,450

    Default

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

  8. #18
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by AnonymousCoward View Post
    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.

  9. #19
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by johnc View Post
    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?

  10. #20
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by elanthis View Post
    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.

    Quote Originally Posted by elanthis View Post
    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.

    Quote Originally Posted by elanthis View Post
    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.

    Quote Originally Posted by elanthis View Post
    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.

    Quote Originally Posted by elanthis View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •