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.

Integer performance?

[crow]

In looking at the selection of benchmarks, it seems like they're all based on scientific numeric problems. In other words, they're all very floating-point intensive. I'll admit that I didn't read it all that carefully, but it looked a bit like reporting SPECfp numbers without looking at SPECint.

Also, the benchmarks used are probably much more loop-oriented than much of the real-world code, but that's typical of benchmarks.

What I would find interesting would be to compile glibc, apache, and something like perl or mysql with both sets of compilers and see what difference you can get with some web server benchmarks. Or compile X and some game and see how the frame rate compares between the two compilers. Or compile X and Mozilla, and find some really complicated pages to see what gets rendered the fastest (possibly using some trick to get it to cycle between several such pages 1000 times).

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.

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,

Re:Could this replace gcc ?

[Xner]

... because the Linux kernel used a significant amount of gcc-specific functionality.

I have the impression that a significant point is the difference in assembler syntax. GCC uses the AT&T syntax, where the register you want to store into comes last, while the Intel compilers (and just about any other x86-native tool) uses the Intel syntax, where the distination register is the first one in the list. There are other differences as well, regardign the way type information and indirection is handled.

My impression is that Intel does not want to implement an AT&T style assembler parser, and the GCC folks got bothered so much about Intel syntax by all the x86 newbies that they'd rather jump off a cliff.

Re:gcc and Intel compilers

[MikeBabcock]

Or take a look at the info on x86.org.

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.

Why temporaries matter

[Anonymous Coward]

MOJO. This is a link to a detailed report on how to handle unneccessary copying of temporaries and why the compiler can't do it for you.

Re:Why temporaries matter

[e-Motion]

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.

Constructor elision trick? The code

const std::string& s = "some string";

implicitly constructs a temporary std::string and binds it to the reference s. I don't know how the compiler could eliminate the construction of the temporary each time the function is called, unless it compiled it to something like the following:

// C.hpp
#include <string>
class C {
static const std::string S_DEFAULT;
public:
C(const std::string& s = S_DEFAULT);
};

// C.cpp
#include "C.hpp"
#include <iostream>
const std::string C::S_DEFAULT("some string");
C::C(const std::string& s) {
std::cout << "C::C() called with: " << s << std::endl;
}

You may wish to rewrite your code in this manner because it virtually guarantees that the std::string for the default parameter is constructed once and only once. It also provides an added benefit: if the value of the default changes (from, say, "some string" to "some other string"), then only the C class's translation unit needs to be recompiled.