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

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.

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.