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

Re:c++ programs

[halfnerd]

I'm running mozilla compiled with gcc 3.2.1 with no problems at all. Even got java working thanks to the excellent portage system in Gentoo. And I heard that flash 6 can be used with gcc3.2.1 compiled mozilla

Re:Could this replace gcc ?

[swmccracken]

A while ago, no. Intel explicitly documented that their C compiler could not compile the Linux kernel because the Linux kernel used a significant amount of gcc-specific functionality. (Specifics of inline keywords, the inline assembly bits interfacing with the c written bits, for example.)

I do not know if this is still true, but I imagine it is.

The Kernel developers use gcc - I wouldn't entirely trust using a different compiler. Besides, there probably isn't a huge performance penality.

I've looked at using the Intel compilers (the have a FORTRAN one) and their main advantage is in number-crunching applications. I suspect the differences aren't so important in interactive / non-crunching applications.

-
-

Re:gcc and Intel compilers

[swmccracken]

Instruction selection isn't that simple - knowing what instructions there are isn't difficult, as that is documented.

But, knowing which instruction would be the fastest in each particular situation, how to organise things to reduce the chance of a cache miss and that sort of thing. So, yes, Intel know more about their chips than anyone else does.

(However, AMD know more about AMD chips than anyone else does...)

Interesting...

[Pathwalker]

I wonder why he didn't turn on -fforce-addr under GCC?

Under the versions of GCC that I have used, I've always found that -fforce-addr -fforce-mem gives a slight speed boost when combined with -O3 -fomit-frame-pointer.

Under GCC 3.2, it looks like -fforce-mem is turned on at optimization -O2 and above, but -fforce-addr does not appear to be turned on, and it seems like it may be of some help in pointer heavy 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:Glibc 2.3 issues?

[ChaoticCoyote]

I'm running Intel C++ and Fortran 95 with Debian "unstable" as my distro (though I provide my own kernel), and it's currently using glibc 2.3.1.

Intel has stated on their web site forum that their compilers don't work with the glibc provided with Red Hat 8.0. I don't have an installation of Red Hat here, so I can't verify the problem.

SPECint vs. SPECfp

[yerricde]

Why did SPEC dudes bother splitting between SPECint and SPECfp after all?

Because encryption and other heavy number theory doesn't use floating-point.

Because analog modeling of physical systems such as circuits doesn't use integers except as loop counters and pointers.

Because floating-point hardware draws a lot of power, forcing makers of handheld devices to omit the FPU.

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 ;-)