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

Re:Huh?

[Omega Hacker]

Both machines are running SMP kernels because Hyperthreading makes the single P4 processor look like two processors. If you don't run an SMP kernel, you don't get access to the second virtualized CPU.

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

[zenyu]

Unfortunately the C++ from the two compilers is not compatible, yet. I think they are working on it, perhaps with gcc3.3 and Intel 9.0. Also, the being a different compiler it won't just compile a program that you've got working with gcc 2.x, gcc 3.2, and Visual C++ 6.0, esp if you have a long compat.h to do it.

I like icc, esp since I'm using a lot of floating point and gcc isn't too good with that on the PentiumIII & 4. But so far haven't had the time to unit test every component with my C++ project, and you can't just drop in icc compiled classes, it's all or nothin' (or lots of hacks and C code, but I'd rather put the work into a proper port at some point.) gcc 3.2 is also better than those benchmarks show, I've gotten a doubling in speed on some code compared to gcc 2.x. It's often a matter of trying different flags on each unit and rerunning your benchmark, I think the -Ox's aren't finely tuned yet on the gcc3.x series.

There is a real problem with compilation speed on gcc3.2, I thought it hung when I ran a "-g3" compile and it was stuck on one short file for 10 mins, nope, just REALLY slow. I modified my makefiles to do a non-debug compile to check for errors before doing a "-g" Then I only "-g3" the files I need, when I need them. I mention it mostly because it may explain why the -Ox flags aren't optimal yet.

Re:c++ programs

[bunratty]

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

The last I heard, the reason that Linux builds of Mozilla are slower than Windows builds is that Linux Mozilla builds use g++ 2.95 with -O optimization. When they can switch to g++ 3.2.1 with -O2 optimization, the speeds should be comparable.

Re:gcc and Intel compilers

[Screaming Lunatic]

I wasn't trying to imply anything that you are implying that I tried to imply. Intel writes an optimizing compiler. The compiler optimizes well for Intel hardware. I don't think that there are undocumented instructions or any other conspiracy theory. Intel would be stupid do that. It would give AMD more opportunity to whip them with programs compiled with msvc or gcc.

I do believe that Intel engineers probably have a better understanding of branch prediction and cache misses on Intel hardware.

I don't think these benchmarks give gcc a black eye at all. gcc aims to be a cross-platform compiler first, optimizing compiler second. icc aims to be an optimizing compiler first, cross-platform compiler second.

And chill with the conspiracy theories.

Not my experience.

[WasterDave]

I've been writing some integer only video compression code, and these results don't really bear out what I've been seeing with GCC 3.1 and Intel C++ 6. I'm getting a consistent 15-20% more framerate under Intel, using an Athlon. An Athlon, god alone knows what we'd be looking at if I was daft enough to buy a P4. Admittedly there are some vectorizable loops in there (that are going to be replaced by primitives at some point), but even without those the performance improvement from C6 was consistent and noticeable.

More relevant is how the performance of C7 is markedly worse on the P3 platform than C6. Very disappointing, makes me wonder what they've done.

Dave

some practical issues

[blackcoot]

i've been using icc on a realtime computer vision project that i'm working on. intel's compiler ended up giving me an approximately 30% boost over all --- a difference which is not to be sneezed at. in terms of empirical performance data for my application, icc wins hands down.

that said, icc does a lot of things that really irritate me. for one, it's diagnostic messages with -Wall are, well, 90% crap. note to intel: i don't care about temporaries being used when initializing std::strings from constants --- the compiler should be smart enough to do constructor eliding and quit bothering me. the command line arguments are somewhat cryptic, as are the error messages you get when you don't get the command line just right. the inter procedural optimization is very *very* nice; however, be prepared for *huge* temporary files if you're doing ipo across files (4+mb for a 20k source file adds up very quickly).

this all said, i don't think that i'm going to give up either compiler. gcc tends to be faster on the builds (especially with optimization turned on) and has diagnostics that are more meaningful to me. fortunately, my makefiles know how to deal with both ;-)

Re:Could this replace gcc ?

[T-Ranger]

Unfortunatly the reality of the compiler world is that everything has there own unique extensions to ANSI-C. And for that matter, there own unique bugs related to there implementation of ANSI C as well.

Any peice of software as large, complex, and critical, as a OS kernel is going to, at the very least, be tested agianst a specific compiler. Linux was developed primarly with free tools, ie GCC. So Linus and his cohorts have taken the test-on-gcc mindset one step further and used GCC extensions.

So what? What do they loose? No functionality, they could implement things in ASM if need be, so convience. And convienent things are probabaly understandable things, and understandable things mean less buggy code.

If people never used compiler extenstions, then you would never have to run ./configure :)

Mail sent to author

[guerby]

I sent this on December 10th, no answer or update to the page:

Hi, I just saw your posting on the GCC list and was surprised by your analysis about Scimark 2.0 "Overall, Intel produces code that is 15% faster". If you look at the detailed result, you'll find out that the Monte Carlo tests is an obvious problem for GCC since it produces code 3 times as slow as Intel whereas on other tests it is on par. This discrepency explains about all of the 15% difference in the composite difference (which is a simple arithmetic average), so "overall" is a bit strong :).

Interested I took a look at the Monte Carlo test, and it turns out to be 20 lines of code that generate random numbers using integer arithmetic, ie not floating point intensive stuff at all which is quite at odd with your statement "I've found this benchmark reflects the performance I can expect in my own numerical applications".

My conclusion is that GCC is probably missing one obvious integer optimisation that Intel compiler does, but I don't think we can generalize from this particular point.

You can quote me on a public forum if you want to. I write numerical intensive code for a living at a big bank.

Sincerely,

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