Slashdot Mirror
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?"
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.
GStreamer - The only way to stream!
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?
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).
I'm a little ignorant when it comes to this... gcc and linux have always gone hand in hand in my mind.
Could we see versions of linux distributed with intel compiler instead of gcc? Can the intel compiler compile the kernel?
Clue me in!
--noodles
But Intel, not surprisingly, excels on their own hardware.
Do you mean to imply that Intel knows something about the Pentium architecture or instruction set that the authors of gcc don't? Does the code emitted from the Intel compiler use undocumented instructions? Intel's compiler is newer than gcc and wasn't developed with the "many eyes" that have looked at gcc over the years. It looks like Intel's engineers wrote a better compiler, simple as that.
These benchmarks give gcc a black eye, but I doubt Intel was using undocumented secrets of their chip to defeat gcc. Sometimes the open source community has to admit that not every open source project represents the state-of-the-art.
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
I write a blog now, you should be afraid.
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
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.
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:
All about me
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.
All about me
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