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."

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

Did Intel fix the "-ipo"-bug in 6.0?

[Lars T.]

From the article:

The options used for compiling were: [...]

icc -O3 -axK -ipo .

Article (in German) [heise.de] describing the bug in vers. 5.5 of the compiler. In short: when using the "inter procedural optimization" ompimization, the compiler would sometimes generate faulty code, as an example they give POV-Ray rendering tinted images.

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.

Inlining slows performance?

[Anonymous Coward]

Why would function inlining slow performance? Ought the removal of function calling overhead (pushing and popping of params, jumps, etc) speed up execution in all cases? I can see how it would fatten up the object code, but I can't see how it would slow it down.

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: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: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.

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 :-)).

Re:Please

[Bert64]

The performance gains on x86 are far from small, theyre quite noticeable, especially on the P4, and if the whole system was recompiled using this you would DEFINATELY notice.
But just try benchmarking gcc to SUN Workshop compiler on Sparc, or the Compaq C Compiler on Alpha, or even MipsPRO on Mips, the difference between gcc and these compilers is MUCH bigger than icc`s.
If code were written cleanly (ie not using ANY nonstandard extensions present in compilers, including gcc) then this wouldnt be an issue, people would just be able to go ahead and compile using the compiler of their choice. Many programs do infact compile without gcc, and result in huge performance gains.

gcc is to C compilers what msie is to browsers - commonly used, and easier to code for - while making your code incompatible with others, and yet inferior in MANY ways.

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.