Benchmarking Intel C++ 6.0 to GNU g++ 3.0.4

axehind writes: "Here is a good article detailing a benchmark [comparison] between the two compilers. The results are very interesting."

Comments

Hey, it being available is just -cool- to me.

[Talonius]

More support from mainstream companies like Intel means more recognizable brand names associated with Linux which means more "reputation."

I still use gcc just because everything I have (theKompany's KSG, for instance) is presetup for gcc. :)

Maybe I'll play with the Intel compiler though I do nothing that "intensive." Most of my stuff waits on the user.

.:|T

Kudos to GCC

[zulux]

Given that GCC is cross-platform to the extreme, I'm verry impressed with GCC ability to hold up well to Intel's finest. Plus GCC has diferent front-ends for other languages, it gets even more impressive.

Aside:
Personally, for initial developemnt of cross platform stuff, I actually use Borland's C++ Builder compiler and linker. It produces slow code, but it's amazingly fast at compiling and linking. The debug and compile cycle goes so much faster - that I get more work done faster than with Emacs and GCC. After the code runs well on Windows - I move on to testing with GCC on other platforms.

Speed isn't everything but...

[leastsquares]

Often pure speed isn't a crucial requirement. (With my code speed _is_ critical, but that's besides the point). However, this isn't the only advantage of icc.

Icc also:
* Supports OpenMP.
* Has a great debugger for multithreaded code.
* Has handy profiling and optimisation tools.
* Is highly standards compliant.

Granted, gcc wins hands down on portability though.

Please

[photon317]

Please people, don't go making patches and whatnot for all the standard linux distro package source code to get everyone compiling on this Intel compiler. For normal system services, the performance gain isn't worth the loss of the highly multiplatform and highly GPL gcc we have today, and it would be a shame for gcc to fall by the wayside in common use (probably 80% of gcc compilations are x86 linux) because of small performance gains you won't really notice.

The Intel compiler sounds pretty damn good, but it should really be left for those one-off needs (like compiling a custom scientific application for your beowulf cluster), not general use.

Re:Please

[Permission Denied]

I don't particularly care for one compiler over the other - almost all of my code runs fine under both (I've only recently started playing with icc). The only compiler-dependent thing I've ever used was gcc's inline assembly (which is extremely useful when you need it), but that was only for one project.

I personally like using more than one compiler/libraries just because it makes my code more portable, and it catches dumb mistakes. I usually develop on FreeBSD with gcc, but I'll occasionally I'll compile on a Linux/glibc or Solaris box (using Sun's cc, not gcc), just to make sure I'm not including the wrong header or something.

I have this old Sparcstation 4 running SunOS 4.1. I don't use it for anything vital, but I just like playing with it for nostalgia purposes. Lots of stuff won't compile on it, even using gcc. People sometimes just compile some software for Linux and assume it will work everywhere - I kind of feel sorry for those that have to use HP/UX or AIX, as I know those guys are going to have all kinds of problems.

In short, I agree that the minimal performance gain isn't useful, but portability is important.

Re:Please

[0x0d0a]

Actually, the Linux kernel has lots of bugs with regards to being correct C code. If you port it to another compiler, you're going to fix a lot of bugs. Making Linux more portable is likely to clean up a lot of issues.

Question?

[chfleming]

Theses two compilers both use glibc right?

Intel's compiler beat gcc badly on the Monte Carlo and Mazebench(w/o image saves). Both these two apps use rand() and there are multitudes of different algorithms for random numbers.

Perhaps the Intel compiler is using it's own algorithm for rand() that cuts corners?

Re:Intel Compiler & Exceptions

[lprimak]

Intel compiler works great, except for handling exceptions in a multi-threaded program. The exception stacks get mangled if multiple threads throw/catch exceptions at the same time. gcc exception handling is completely thread-local so there is no locking and it works great. That's why I can't use icc for my own product. My info is about 3 months old. I wonder if they fixed this...?

Re:Please - ICC and a meritocracy.

[Zeio]

The difference isn't as small as you say. We saw an immediate 15% gain in our production C code, and that was on a Pentium 3, the Pentium 4 test machine gained quite a bit more from ICC. In certain cases, others have claimed two or three times performance for their respective program.

I believe in 'may the best man win,' Intel's compiler is certainly worth buying, and if your production code needs the speed boost the be more competitive, then there is no choice - it must be done the best way.

This isn't about licensing, who makes, if its open or not, its about a meritocracy voting on what's the best way to see performance on a given platform.

I would love for Gentoo to allow the use of ICC to compile the whole distribution. It not possible for certain things, but I'd like to see it done.

Re:Inlining slows performance?

[V. Mole]

What can happen with inlining is that code size expands to be larger than the available CPU cache memory. (Re-)Loading code from main memory (or slower cache, for CPU's with multi-level caches) is slower than a few register updates. You can see the same effect with loop-unrolling, although given the way CPU caches have grown means it's becomeing less of a factor.

Note in particular the article's observation that "inlining doesn't show any slowdown" is exactly that: an observation, applicable to that particular processor. A serious project would have to benchmark their particular application on their particular target machine to determine the best choice of compiler options.

Why use -fast-math?

[V. Mole]

While there are some uses for it, I doubt that any serious floating-point codes would use "fast-math" (shorthand for "not-quite-right-math"). IEEE math is not perfect, but it allows one to estimate and control error accumulation reliably. The correct response to discovering that ICC defaults to fast-math is not to enable it in GCC, but disable it in ICC.

I've no idea whether it change the relative result of the benchmarks, but at least they'd be representative of actual use. (Or run them both ways, actually, to see which compiler is "cheating" more :-)).

Official Addendum

[ChaoticCoyote]

At the least the site stayed running with the spike in hits...

I'm putting together some "large" benchmarks for the "rematch" when gcc 3.1 hits reality next week. The problem with most "real world" programs is that they're interactive or I/O bound, masking the code generator's abilities.

I need to be clear about one thing: Anyone who tosses out gcc over this review is a fool. Intel C++ is a good product for very specific applications, but it does not replace gcc. All the benchmarks show is that Intel C++ can provide a performance boost for certain classes of computationally-bound programs. For some of my scientific work, Intel kicks ass in comparison to gcc... for some other projects, gcc comes out on top. What's important is choice and competition, which fuel evolution...

I urge people to read the entire article before making any assumptions about my goals or the results.

Profiling feedback

[Skuto]

They missed the most important part: profile feedback optimizations.

This is one part where Intel C really gets way and beyond the GCC compiler. Compile first with -prof_genx, run program, recompile with -prof_use.

The speedups are _big_. Intel C will totally kick GCC's butt with this option enabled.

GCC can also do profiling feedback optimizations, but it is not nearly as good.

--
GCP

Inlining problems

[p3d0]

I compared icc to gcc on a recent project, and came to two conclusions that surprised me. The first is that icc can understand gcc-oriented code very well, including the asm syntax. I was pleasantly surprised at how easy it was to switch from gcc to icc.

The second conclusion is that gcc is better at massive inlining. The coding style I used on this project was to make heavy use of inline functions instead of macros. Often, to get decent code to be generated would require a few dozen functions to be inlined into each other, and the results to be attacked by -O3. Afterward, these things would produce small, fairly tight code sequences of only a dozen or so instructions.

When I switched to icc, I noticed an immediate tenfold decrease in performance. The culprit: lack of inlining. icc has a number of strict requirements for functions that are to be inlined, and most of my functions broke at least one of these rules. (For instance, ironically enough, it can't inline functions that contain asm directives.) For some of them, I couldn't tell what rule was being broken; I could only see that the function wasn't inlined. Furthermore, icc essentially ignores the "inline" directive, so there was nothing I could do about it. By contrast, gcc obeys "inline" unless that is totally impossible.

Granted, the optimizations that gcc does after inlining are less than ideal, but people are working on that, and I gather that the 3.x releases are supposed to be much better than the 2.x. Anyway, that was a price I was willing to pay in order to use inline functions instead of macros.