Intel C/C++ Compiler Beats GCC
jfonseca writes: "An article from Open Magazine claims the new Intel C/C++ compiler's geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC. They also predict the end to the ubiquitous GNU compiler due to low performance. Many other compiler/platform combinations also compared. A bit pretentious, yet an interesting read."
GCC is the only compiler you can count on being present on every Linux (or BSD) system. Thus most code released is going to continue being compilable by gcc, and it's going to remain the baseline for source distribution.
/Janne
Trust the Computer. The Computer is your friend.
I guess I'm not that surprised that the corporation that designed the CPU would produce a more optimized compiler.
The interesting thing is that the Intel compiler's code ran at 'virtually identical' speeds on an Athlon.
I was always under the impression that a vendor supplied compiler would almost always out-perform a generic cross-compiler, which is available on much more other platforms. GCC is all fine and dandy, but it's it shines in other aspects than pure optimization and fast code (they may be faster on some architectures than the vendor supplied compiler, but that's not my point). The produced code x86 was always sub-optimal. Because of that, projects like pgcc exist(ed).
-- The plural of 'anecdote' is not 'data'.
Could this be more full of itself? Somehow I have trouble accepting sweeping generalizations about the fate of compiler technology from someone who obviously dropped out of a creative writing program at some third-rate school.
sic transit gloria mundi
Sometime I analize assembler code produced by gcc-2.95.3 and I am dissapointed. Gcc can do so stupid things like inserting instruction inside - instead outside of loop. Probably gcc3 is fixed, but I heard it still produces slow code (not faster than gcc-2.95.3). So which compiler should I use today?
I know gcc3 is better, becouse it supports more platforms, but what about speed improvements? To have fast inner loop in linux application I must code that loop in assembler. That is a problem for someone, who's creating a computer game.
geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC.
The testing didn't involve compiling kernels at all.
The 47% performance improvements were on a numerically intense benchmark program.
The preferences of the article's authors is pretty clear:
"Nonetheless, the magnitude of the performance differential in numerically intense applications is such that only the most dramatic sort of improvement in the long-awaited version 3 of the GNU C/C++ compiler will stay the hammer that drives a stake through the fibrillating heart of the aging technology behind the GNU C compiler. May it rest in peace."
These are not the words of objective observers, and such comments strike me as being quite irresponsible.
If you're not part of the solution, you're part of the precipitate.
Gcc's speed sucks because of its fundemental design focus on supporting as many languages as possible and being avaliable on as many platforms as possible instead of optimizing for a particular language on a particular platform. Although code generator of gcc can use a lot of improvement, its speed can't be taken to levels possible with tailored compilers. If an open source alternative that can beat intel's compiler comes along, it won't be based on gcc.
Gentlemen, you can't fight in here, this is the War Room!
I am sure that Intel's compiler is better than gcc at crunching numbers, in fact, it's probably signficantly better. But my guess is that for most folks gcc is "good enough" at a much lower price.
The commercial compiler companies have been trying to rid the world of gcc for quite some time now, and yet, come the close of the day it's the commercial companies that are getting closed down or bought out, and it's gcc that continues to gain users.
Now, if Intel were to allow you to use their compiler for free (even without source code) for commercial purposes, then perhaps I would start to worry about the future of gcc. But that isn't going to happen, and gcc will continue to chug right along.
This sound somewhat like a bit biased comparison - even though I think that Intel's compiler is indeed better in x86 optimization - most of gcc developers would confirm this...
...at a conference I went to on computer vision. You see, intel also has an optimized computer vision library. They began their talk for the day with the statement "Intel is in the business of selling chips. However, everyone already has enough processor power to do word processing and that sort of thing. We need people to make more complicated applications so that it make these faster chis we come out with worthwhile."
I imagine that similar logic applies to their compiler: they give it away for free (binary version, so they can control it), but build in the hooks that make it work faster with their newer chips than with the competitions' while at the same time encouraging people to write more CPU intensive programs because they have the power to do so.
Ultimately, they succeed at their real goal: to sell more chips. By the way, AFAIK, Intel still gives away its compiler in binary form, though only for Windows. Of course, the last time I checked was a year and a half ago...
Mod me down and I will become more powerful than you can possibly imagine!
It's not exactly new news that Intel's compilers are better than Microsoft's or GCC, as any astute watcher or compiler of SPECbench results can tell you. GCC has never been a performance barn-burner. People who wanted that paid the money, signed the forms, and tweaked their software to run under Intel's compilers.
No, what's great news is that Intel's compilers are available now on Linux. So an ISV like Red Hat can compile the OS (or specific math libraries) on them for either real-user or benchmarking benefits.
"Driving a stake through the heart" of GCC is a gross exaggeration, given the ubiquity, freedom, and free beer nature of GCC. "Giving GCC a kick in the pants" might be more accurate. And a good thing, too.
--LP
A while ago I tested the Intel compiler on some graphic-stuff I've been coding (using Visual C++). I got between 20-30% performance increase. The compiler was horribly slow though, MSVC was probably 4 times as fast compiling the entire project.
I'm using GCC 3.0.x for Gameboy Advance development (ARM7TDI cpu). It works fine for me, but the vendor compiler generates between 30 and 40% faster (and smaller code) (or something like that, don't have the exact numbers right now). But as many others have pointed out, GCC is free, other compilers are not.
GCC is excellent for multi-platform development and cross-compiling. Using the same compiler for Windows, Linux, *BSD, Irix, Solaris and Gameboy Advance is a huge advantage.
Speed (on the generated code) isn't always the issue. At work we always compile and run with full debug information and no optimization (except for tiny, speed-critical parts and very very thouroughly tested libraries). The code is used in weapon systems (we ship the entire system, including the hardware). Coredumps are very nice if you want to find out why something crashed :)
Compaq's (formerly DEC) C compiler for alpha's have always been excellent and far ahead of GCC. The problem is that a lot of compilers (we haven't tested the intel yet) won't compile all the code that you may want or need. In the *NIX env. GCC seems to provide the highest level of compatibility over a wide variety of platforms n(SUN, AXI, BSD, Linux, Tru-64, Windows, et al).
Until there is only one chip left to support (Intel is fast working on it, with the support of turncoats Compaq, HP and others) GCC will be a viable option. GCC is a great "cross platform" compiler that works for much of the current written open soruce code base. You can get that compiler to work for many different OSs and archs.
In the end, remember apache wasn't the fastest web server, but it was the "most correct" and it was free! It really doesn't matter how well your C compiler works if it won't compile your code or run on your system.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
While I will agree with some of the infighting bullcrap,I disagree with your bullets.
:) Well, no, I would rather have the fast one, but I am a poor married man with a kid and have no money to wast on a compiler when I can get one for free.
...well, people should just download Mozilla and fergeddabout Netscape. I am not saying this because I am a Open Source Zealot (because I ain't). Mozilla is doing good and who gives a rat's rearend if it was late. I personally don't care if crap is late....I care if it works. Case in point, one could say the rewrite of Enlightenment is late, but I just think that raster and mandrake (if he even works on e anymore) are trying to make E the best GUI they can by not only making it a GUI but a shell as well.
Sure GCC may not be the best compiler on the face of god's green earth, but to me, if I was running a project with tight money constraints, and I had to choose between a $499 and a $0 dollar compiler and the only reason was the expensive one was faster, unless I absolutly had a better reason for paying the $499, I would have to choose gcc. For one, gcc is well known, in common use, and everything works pretty well on it. I am not saying it doesn't have it's caveats, but to me, compile speed means diddly. Personally, I would rather take the slow one because it gives me more time to drink my coffee while waiting on a compile!
Yeah Linux crashes....so does Windows, Solaris, FreeBSD, OpenBSD, z/OS, DOS/VSE, BeOS, Windows CE, PocketPC, Palmos..........get what I am getting at? And so far as covering these crashes up, I JUST don't see this happen, at least from the Linux realm. Oh and anyone trying to contradict what I am saying about other OS's crashing needs to be smacked in the head with a massive Clue stick. There has almsot never and probably never will be a uncrashable os. There has almost never been a completely bug free piece of code. Sure, some others in the list are better and crash MUCH less then windows (Linux fer sure as well as about 90 percent of the list), but to say that people are tying to cover Linux crashes up is BS!
Mozilla not delivering? Where the heck have you been? Mozilla, as of late, is TON's better then it was. And with the earlier post that Mozilla will also support anti-aliased text, well, besides Konqueror, I see noone else that competes and surely not that bug ridden, crash pron piece of filth called Netscape 6 (or 4.78 for that matter....). I know it's been updated since 6.0 came out, but heck it was based on a sub point 1 release of Mozilla and even Mozilla was better then Netscape 6 when 6 came out! Plus there's that AOL/Time Warner FILLED bookmark list that installs with it and
Loki is dead. Long live Linux. Listen, most people are not like us. They use their computers as tools and not gaming machines. Joe sixpack will ask if it's being made for PS/2 not for the PC. Now that's not to sayt gaming on Linux isn't important. It is, but just because Loki has died doesn't mean their won't ever be games on Linux, commerical or free. There are lots of great free games for Linux. Armegatron, GLTron, Tux Racer, Rocks and Diamonds, Maelstrom and the list goes on. Sure, they might not be a 3d shooter, but then there's Quake for that. Also, the time is ripe for a new gaming shift. MMPORPG and 3d Shooter cookie cutter games can only last so long before something, anything comes to take it's place. Right now is the time for a truly innovative game to come out and steal the show. Oh and Wolfenstien and Doom 4 won't be it...they'll just be another 3d shooter.
Slashdot is censoring.....well, I doubt it. They aren't censoring. I can post anything I want under each new topic. If your talking about story submittals, well, when you are on the other end getting all of the submissions and a vast number are either duplicate, trolls or worse, well, then you start to develop a finely tuned BS detector that sometimes can be faulty. You can usually filter out most BS but sometimes some falls through and get's posted. Rob, Jeff, Chris and Neal are human you know.
Gorkman
As a sysadmin who often compiles packages, but doesn't write them, all I care is that
Mozilla (the shining jewel of Open Source)
BS. Konqueror is better, and KDE and Gnome the shining jewels, after Apache of course. (Sendmail? Bind? Proftpd? PHP? - not jewels perhaps, but great workhorses.)
Loki ... listened to the Linux zealots and got screwed
So sad, Linux may never be primary platform for gaming. I could care. And my Toyota will never enter the Indy 500.
Slashdot ... dream is gone and good riddance.
/. works for me - what gets modded up is generally what I end up agreeing is most worth reading.
If you don't like the moderation, set up your own board and invite in only folks you agree with.
"with their freedom lost all virtue lose" - Milton
How can GCC die when Intel can't come close the impressive list of Supported Platforms by GCC?
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
It seems like it would be a nice move for AMD to support GCC optimizations for Athlon processors. The idea would be similar to IBM supporting Linux as a way of chipping away at market dominance by Microsoft.
AMD should supply GPL'd contributions to GCC that optimize code for its Athlon processors. This would give them a relatively cheap way of putting out a competing compiler to Intel's proprietary version since it would leverage all the work that has already been done by the GCC group. It could also make them the preferred chip for open source OS's by ensuring that Athlons run GCC code faster than any other processor. This would be strategically very valuable at a time that they are about to push their new 64 bit instructions while Linux is simultaneously becoming viable/validated as an enterprise platform. Since GCC is not limited to Linux, these performance enhancements would also translate into gains for non-open source development projects as well.
All in all, it seems that this could be a be a great way for AMD to give developers a way to produce AMD optimized code while at the same time encouraging the use of their new 64 bit instructions in the booming open source OS server/workstation market.
Next time the zealot in you decides to come raging out, take a deep breath and count to 10. Think about how this news might be good for the open-source community before you begin bashing wantonly.
Now, as for GNU C and benchmarks, GNU C has never produced the fastest code on any platform. Unless you lived under a rock and never did any high performance computing, you'd know that. And if you took the time to look at the GNU C documentation, you'd also know that this is no accident. But to most GNU C users, this fact never mattered. GNU C generates decent code and it has many other attributes that make it the "best" compiler for many applications.
You see, there is another misunderstanding that you and Bill Gates share: you think that there is a single "best" solution to everything. In real life, there isn't. What is "best" for you isn't necessarily "best" for me, and there may well be no way to reconcile our conflicting needs in the same piece of software.
I do agree that Slashdot moderation tends to exclude voices like yours and I think that's wrong. Why? So that one can point out how uninformed and confused you actually are.
So? The GNU project does not have a mission statement that includes "produce major breakthrough every couple of years". The FSF's top level page has a couple of links that are essential when trying to evaluate its success: why we exist (as relevant as ever), what we provide and where we are going.
But of course, that's just my opinion, so flame me.
I rarely flame people for their opinions. I occasionally flame people who clearly haven't bothered to try to understand what they're talking about and who don't let facts get in the way of their opinions. You seem to fit that category nicely. In particular, your comment "I think we need a lot more non-GNU involvment for gcc (gcc-foundation?) to get some fresh blood into this project. And if RMS doesn't allow that, we need a fork." shows you to have little understanding of gcc's development process. Gcc's development process was broken open in 1999 (by the FSF effectively admitting the failure of its cathedral-style development model of gcc 2.8.x and embracing the bazaar-style development model of the EGCS fork) and has an effective foundation (in the form of the GCC steering committee), as anyone who has read the GCC FAQ or is familiar with gcc's history knows.
I do a lot of high performance computing with GNU C. It doesn't matter to me how fast the Pentium works with some oddball proprietary compiler--the performance I get with GNU C is the performance an Intel-based machine has for my purposes. If that's less than optimal, that just makes Intel's platform less attractive. If Intel wants to do something about that, they should invest in improving the GNU C backend.
Let me get this straight.
.. you'd think they'd have enough pride to work on a compiler until it was the best it could be.
... or just stare at.
Intel is happy that their compiler can beat another compiler?
I'd hope so... They designed the damn chips, had a head start, have cash money to buy a few smart compiler dudes
It is interesting to see Intel pick on GCC. They are in the CHIP BUSINESS... A compiler (any compiler) helps them.
You'd think THEY would be the ones to release a compiler into open source so they could get the rest of the world looking at how to do even more optimizations for their chips.
GCC has been out there for well over a decade. Open to anyone to improve
Intel could show us all how to make a better compiler. Open up their source code... but someone might improve on their techniques and that would make them sad. So, instead they berate a compiler that has done them only a service.
Just my thoughts. Yours may vary.
We use Kai (or KCC) at work, and it is truely a remarkable product. It's a two-stage compiler - it generates C code native to the platform your working on, then calls the compiler/linker for that platform to compile it. The idea here is that the native compilers for any given platform will be able to optimize for that platform. So Kai just optimizes what it can and dumps it out into C code, then calls the native compiler/linker with optimizations on to recompile that code into the executable. The Kai C++ compiler was ported to Windows, Solaris, Linux, IRIX, etc., so there was the added benefit that any code written with Kai in mind would compile easily across other machines.
Kai and GCC are very similar in concept, except that Kai was a bit of a "higher end" compiler. Think of GCC being the Toyota of compilers, and KCC being the Lexus of compilers. You may pay the extra bucks just for the optimization/cross-platform abilities that Kai has - but most normal folk don't need it.
Unfortunately, Kai got purchased by Intel, and (from what I see on their site) they seem to be dropping the other platforms to support only intel. Really, the Intel compiler is really the Kai compiler, but only for Intel. In fact, Kai (Kuck and Associates Inc.), is now part of Intel. Personally, I think this sucks, since Kai really is a superior product compared to any other C++ compiler out there, if you will to pay the extra $$$...
Me email iz skyewalkerluke at microsoft's free email service.
Fortunantly, GCC just about compiles on everything with a CPU
"Unfortunantly," last time I checked, GCC doesn't generate code for 8086 or 80286 processors, only i386 and up, so you can't build an OS that's backwards-compatible with legacy 16-bit apps with GCC.
Will I retire or break 10K?
The Intel compiler does not generate precise floating-point code by default!
From the compiler documentation:
Looks like we can't even have IEEE compliance, we can only favor it. More gory details can be found in the manual (warning, big PDF...), but the "optimizations" that shocked me most were:
These are all defaults. Trading precision for speed can be a lifesaver sometimes, but not in numerical analysis!
--
I like canned peaches.
Freedom is not the license to do what we like, it is the power to do what we ought.
The hobbyist licence is free.
But it prohibits selling copies of the compiler's output. Thus, if you make a CD of your software, you probably can't even sell it for $5 to cover duplication costs. Plus, such a restrictions is incompatible with the "no restrictions on selling" language in the GNU GPL.
Although aren't most Linux distros only compiled for the i386 anyway, ignoring what i686 optimizations exist in GCC?
AFAIK, the Linux distributions are compiled with something like -march=i486 -mcpu=i686 which means roughly "Use only those instructions available in i486 and up, but schedule for i686." (Source: GCC 2.95.3 docs, info gcc invoking submodel i386)
Will I retire or break 10K?
He actually makes an interesting point. I mean, they released a g++ 3.0 that would not correctly compile KDE. It appears that the associated ABI bugs are not going to be addressed until 3.1. And they've dropped the ball on it badly enough that it's been forked twice over the last few years. Up to and including 2.95.x, there were a lot of very obvious and annoying bugs with g++ (no namespace std, no stringstream class, no ios_base class, etc) I don't see any conspiracy theories, but it doesn't seem that gcc have historically given C++ a very high priority.