Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel C/C++ compiler vs. GNU gcc/MS Visual Studio

Posted by michael on from the baby-steps dept.

the_real_tigga writes "OpenMag features a benchmark review of the Intel C/C++ compiler as opposed to gcc on linux and Microsoft Visual Studio compiler on Windows XP. Not surprisingly (for me at least), icc beats them both, with dramatic performance improvements. Too bad they chose to review gcc version 2.95, and not the 3.x series, which is known to produce faster code. What is surprising, even AMD CPUs benefit from the icc-compiled code. There is another version of the article here, and they provide a download of the used tools , so you can try it at home too!"

6 of 35 comments (clear)

  1. AMD by fault0 · · Score: 3, Insightful

    > What is surprising, even AMD CPUs benefit from the icc-compiled code.

    This isn't suprising, as AMD CPUs have always shown remarkable increases in performance with icc (sometimes even more than equivalent intel chips). I guess AMD does a really good job in making the Athlon a x86 chip.

  2. VC6.0, GCC2.95 by spongman · · Score: 5, Insightful

    It would be nice to see the same comparisons but with compilers that aren't over 3 years old.

  3. beta of gcc 3.x? by norwoodites · · Score: 3, Insightful

    They said gcc 3.x was beta software, it has more regression testing than windows have security testing.

  4. how is this benchmark useful? by capoccia · · Score: 4, Insightful
    Key Findings
    On Linux, numerically intense CPU performance improved by 47 percent compared to GNU C v2.95.
    On Windows, numerically intense CPU performance improved by 37 percent compared to MS Visual Studio.
    CPU performance for Intel on Linux and MS Visual Studio .NET on Windows was a dead heat.
    AMD Athlon-based systems benefited equally with Pentium III-based systems.

    GCC 2.95??? in 2003???
    what are these guys thinking? i mean, it may have been the compiler that came with the Suse 7.3 they were using, but still. Suse is on 8.1 now which does ship with gcc 3.2.
  5. Yeah, that article is a little old by TwistedKestrel · · Score: 3, Insightful

    I'm pretty sure that Visual .NET isn't beta software anymore, and neither is GCC 3.x ... this is somewhat out of date. However, somebody who wants a Slashdotting could just download the aforementioned tools and write their own up to date comparison ... (note that I don't want a ./ing)

    All things considered, though, I'm fairly sure GCC hasn't gotten quite *that fast* in the elapsed time since the article was written :p.

  6. Changing too many variables at a time? by Confuse+Ed · · Score: 4, Insightful

    re:

    Target specific object code and executable file format notwithstanding, what really makes the Intel compiler so very interesting is the fact that it delivers the same instruction sequences on both Linux and Windows platforms.

    Doesn't gcc also have the same property when running under Linux or windows? (for the OS-independant parts of your code, obviously)

    Although the main thrust of the article is to compare the new intel compiler to gcc and visual studio, they are also talking about comparing performance accross platforms - their initial comparison is gcc on Linux vs Visual Studio on Windows (no mention of what optimizations are performed, what other service are running, what nice levels the programs are executed at, whether they are measuring user cpu time or total execution time, and so on)

    It would be nice to see tests varying each of these variables individually, or showing all the possible combinations:

    • Operating System : Linux 2.4, Linux 2.5, Windows XP. I wouldn't expect the O.S. to have any impact on the performance of computationally heavy stuff that the compiler can affect (but would make a big difference when it comes to memory management, and any IO)
    • Compiler : Gcc, Intel C++, Visual Studio
    • Optimizations : no optimizations (should theoretically all be the same?), max optimizations without violating ANSI/IEEE rules, max optimizations not caring about rules (e.g. using -ffast-math for gcc), enabling or disabling different targets (ie compile for 386 against compile for 686). Maybe even anti-optimizations such as turning on some extra debug/profiling options under each compiler (the time taken to create and debug a program can be more important the time it takes to execute)

    On a (big) plus point - this article does at least show us some error margins on their measurements (none of this "Graphics card A lagged behind with a mere 47.6, but graphics card B stormed ahead with a score of 47.7" nonsense which seems to be all too common in most reviews)