Intel Compiler Compared To gcc

Screaming Lunatic writes "Here are some benchmarks comparing Intel's compiler and gcc on Linux. Gcc holds it own in a lot of cases. But Intel, not surprisingly, excels on their own hardware. With Intel offering a free (as in beer) non-commercial license for their compiler, how many people are using Intel's compiler on a regular basis?"

Comments

c++ programs

[reaper20]

So does this mean tha mozilla compiled with the intel compiler would run comparable to it's windows counterpart?

I would like to see a test with real desktop applications and desktops, ie. gcc GNOME/KDE vs. icc GNOME/KDE. Would these projects see significant performance improvements from the Intel compiler?

Re:c++ programs

[swmccracken]

The Intel Compilers are not linux specific. They come in both Windows and Linux flavours - and there's nothing stopping you from compiling Moz for Windows using it, afaik.

And, no, I supsect not really. Intel Compilers are designed for number-crunching work - eg: finite element alaysis, engineering simulations, that sort of thing. They perform optimizations designed to improve CPU bound processes. I suspect that interactive / IO bound processes wouldn't be so affected.

Secondly, it depends where the bottleneck is - I could be the runtime linker, or the X-Window system itself or who knows.

Those projects should see some level of improvement, but I wouldn't imagine it's twice as fast. (Things like a paint program might though - as the Intel compilers can take existing "normal" C code and generate SSE and MMX using code.)

Head Start

[ChaoticCoyote]

Historically, Intel has always been ahead of the competition in terms of code generation; I've used their Windows compiler for years as a replacement for Microsoft's less-than-stellar Visual C++.

On the Pentium III, the gcc and Intel C++ run neck-and-neck for the most part, reflecting the maturity of knowledge about that chip. The Pentium 4 is newer territory, and Intel has a decided edge in know how to get the most out of their hardware.

I have great faith in the gcc development team, and as my article clearly states:

If anything, these tests prove that free software can produce products that rival -- and sometimes exceed -- the qualities of their commercial counterparts.

This article is an ongoing effort; I assure you, I'll be updating and expanding the material in response to the comments of readers and further experience.

Re:Why temporaries matter

[blackcoot]

My specific issue has to do with code that looks like this:

class C {
public:
C(const string& s = "some string");
};

icc wants code that looks like this:

class C {
public:
C(const string& s = string("some string"));
};

The only real difference I see between the two is the explicit creation of a temporary. Now, as to why GCC doesn't complain is another issue --- maybe its diagnostics for temporaries aren't turned on with -Wall (perhaps -pedantic fixes that); however, I have this feeling that GCC's constructor elision is the trick here. To be honest, I'm very curious to find out why this happens. As an interesting aside, Stroustrup tackles the issue of overloading operators in a "smart" way so as to avoid unecessary copies.

Personally, I think Java (and whomever it "borrowed" these particular semantics from) got it right. Unfortunately, Java isn't exactly a good language for talking to hardware ;-)