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

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.

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.

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.