Slashdot Mirror
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."
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.
While software firms and organizations developing mission-critical programs may decide to switch to icc, the fact that gcc is free will help it to remain popular among hackers and other budget-constrained users. Moreover, most of the source code programs one downloads for Linux are designed to be compiled with gcc.
Sig (appended to the end of comments you post, 120 chars)
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'.
It seems that they've been testing performace of
some code blocks they've called 'kernels' for some
obscure reasons.
That makes the test useless - if they've compiled
some linux kernel by both, say GCC and MSVC and their own compiler - that's where the real results
are to be derived from. Needless to say that they
couldn't do that.
And their (surely optimized) "kernel"s run faster compiled by their own compiler. Bah! No surprise.
Conclusion : this is unfair comparison, and the results of the test say nothing.
./lxnt
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.
It's not terribly suprising that Intel can make a more efficient compiler than gcc. They've got a performance group who's sole job is to understand the architecture and how to best exploit it. I can't read the article (its not coming up presently), but its hard to compete against a free product for most users, especially in the linux community. For some users the increased performance will be very important, especially people who write applications that crunch numbers. I'm not talking about gimp filters or spread sheets, sure, they crunch numbers but most of their CPU time is spent either idle or on user input. Remember, on linux gcc is both free and everywhere, and it does a good enough job for most people. Most people run systems that just use precompiled packages, and these packages are often just target at generic i386 processors. If people don't even bother exploiting features that gcc already has, I don't see how you can predict that enough people are going to switch to another compiler to even measure on the radar.
Chris Kuivenhoven is a thief, beware
In fact GCC3 was out some time back and it seems typically (to me) to perform around 20% more slowly than Intel's thing (compared to 40% for older gcc, as the article says). It's not so bad, imo.
Compilers like this will be used mainly by performance freaks, like AutoDESK (it still exists?), Adobe and folks that do intensive-cpu apps and have the cash to pay for an improved compiler to have and edge over competition (see? photoshop xxx rotates a picture 11 degrees faster than paintshop yyy...).
;-).
Being an user of a special compiler myself (SDS's cc68000), I think that this kind of compiler has a niche market, and the good old GCC is still the most widely used, and probably will be for ages.
Altough, If this new intel compiler does ELF, I can see MandrakeSoft or RedHat building their RPMs (glibc too - yay!) with it and claiming they are faster than the competition
``If a program can't rewrite its own code, what good is it?'' - Mel
I once worked in a company making compilers for embedded systems, and debuggers. At one point we were outperformed by a 3-400% compared to a competitor. 6 months later we were twice as fast as they were for that specific benchmark. I wonder how many customers actually used that for something useful? The hard part is actually debugging and portability. And for speed I would say that a profiler can make miracles finding the hotspots needing optimizations. Just hand optimize those spots and you are doing fine with your favourite tools.
Also with optimizations follows compiler bugs (i.e. the compiler generates faulty code) that are very hard to find especially if you don't have the source to your compiler.
Finally I think Intel just want to capture customers as thet did with their compilers in the early 90:s (ie PLM and Intel C) It's just not in their interest to be portable. With all this in mind such compilers could be good for a specific project but I'd be careful to build anything on highly optimizing compilers in general and not on a sound design.
...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!
What are they targeting with this release? What new big (and important) features are in it? And, in view of the article, can we expect speed increases, or is it mostly about new features?
In any case, I am not stopping using gcc just because some closed, expensive thing is much faster (even if it is ten times faster), and I expect a lot of people here feel the same way. Ok, I might consider if it was ten times faster :)
Apart from the whole OS "cult" theres also another reason (and I am sure many will disagree with me here), but there is such a thing as "fast enough" and for the vast majority of things I use my computer for, that has been more than achieved. Don't get me wrong, I love tweaking, optimizing, overclocking and generally pushing the hardware as far as it will go, by any means handily available (including keeping a voodoo doll of my PC in the freezer), but I've found that I do this more for the process than the end result. Buying and installing a new compiler (which you know nothing about, in terms of how it works) just doesn't seem to be all that much fun. (Besides, I am sure my Athlon would never speak to me again)
sic transit gloria mundi
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
Sure Intels compiler might be super good at optimizing, but are they forgetting any 12 yr old trying to learn C can pick up GCC for **free**?
Tom
Someday, I'll have a real sig.
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.
I'm surprised that nobody has commented on what might be the most interesting result on these tests - that the same code produced by the same compiler runs 10% faster on Windows XP than on Linux (2.4.10, according to SuSE's description of 7.3). Sure, the "kernels"[1] used by the benchmark might not be as representative of real life as we'd like, but this should still be cause for concern. Kernel developers have flamed each other endlessly over smaller differences on less comprehensive benchmarks between the Arcangeli and van Riel VM systems. Do we have to go through a Mindcraft-like period of denial before anyone starts taking such a result seriously?
[1]The objections about the "kernels" used in the benchmarks not being the same as the "kernel" with which we're all familiar only demonstrate the ignorance of people who don't know that the scientific programming and benchmark communities have been using the term just as long as the OS community. Their usage may be different, but it's just as valid.
Slashdot - News for Herds. Stuff that Splatters.
It seems to me that GNU and the FSF has become a bunch of bureaucrats and politicians who forgot what free software is all about.
Today, the real dynamic and successful projects are mostly non-GNU: KDE, Apache, Linux, Wine, etc.
Today, GNOME is the only GNU-project that can be called a bit dynamic, and I think this is because of a lot of 3rd party involvement via the GNOME-foundation and the fact that RMS is not the final authority in the GNOME-project.
What breakthroughs has there been in RMS-led projects in the last - say - 5 years? I can't think of any.
Of course, gcc is still the best open-source compiler we have, and no alternative is in sight (unless Intel open-sources theirs which is highly unlikely), but I see it as a weak spot in the free software-world. How long have we been waiting for a decsent c++ compiler? Maybe I'm paranoid, but maybe RMS is not very enthusiastic about C++ support because GNOME would look even worse in comparison to KDE, once a good C++ compiler is available?
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.
But of course, that's just my opinion, so flame me.
The intel compiler and it's library quality has to be able to handle ANSI C++ at least as good as GCC 3 or it's not much of an option for me. Is this not an issue for anyone else? Another factor is compilation speed. You wouldn't want to dump gcc for development builds if icc is signicantly slower as I hear it is.
What good is a fast running kernel, when it has more bugs than something from Microsoft?
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
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.
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.
There's another Linux-only comparison between Intel 5.0.1 and GCC 3.0.1:
http://coyotegulch.com/hpc/intel_gcc_bench1.html
wolruf@gmail.com
Is that a good thing? Internet Explorer dominates the web browser market for much the same reasons, whether or not there are better alternatives available. Now we have a proliferation of web sites that only work with IE instead of standard HTML, and all the other well-documented problems.
It would be an advantage for the Linux world if it was easier to port code from other platforms. Most of that code isn't written with GCC, it's written with VC++, C++ Builder, CodeWarrior, etc. If you're going to do this, standards compliance and ease of portability are very important.
I don't know how good GCC is these days; it used to have quite a good reputation for standard compliance and quality of generated code, but that was a couple of years back. If it hasn't kept up -- I said "if", because I don't think this article demonstrates that either way -- and the Linux community religiously stick with it based on philosophical arguments rather than technical merit, surely they'll just be shooting themselves in the foot?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The Pentium Compiler Group (look here) has a compiler patch to optimize GCC for the Pentium family. It's been out for years -- my company uses it and we notice great improvement -- and claims about the same performance gain as this "new" intel compiler. Interesting thing is, it was based on patches from INTEL!
From the PCG FAQ:
1.18 Where did PGCC come from?
When Intel released the Pentium some of their team produced a version of gcc with enhancements which gave 30% speed improvements on some benchmarks. Having demonstrated the improvements possible, they stopped development and released the code.
PGCC came from this work and further enhancements of the Intel code that had been produced. It aims to improve the stability of the compiler and to carry on improving the quality of the generated code.
1.19 How much speed improvement can I expect?
The 30% achieved by the Intel engineers is rare in the real world. Typically, the improvement will be about 5% using an intermediate optimization level like -O3 and no fine-tuning. Sometimes the 30% can be achieved - gzip-1.24 unzips about 20%-35% faster - but don't bank on it.
---
The interesting thing here is the note that the Intel engineers supposedly stopped work on the code. Apparently, they didn't.
Anyway, I recommend checking this out if you want to stick with GCC. The optimizations that work the best:
gcc -O6 -march=pentiumpro
The pentiumpro switch will also optimize for PII and PIII (and presumably PIV).
As with the intel compiler, don't try to build the Linux kernel with this.
I, for one, welcome our new Antichrist overlord.
So I downloaded the Linux_cpu.zip
/lib/libm.so.6 (0x4002b000)
/lib/libc.so.6 (0x4004d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/lib/libm.so.6 (0x4002b000)
/lib/libc.so.6 (0x4004d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
It contains a shared and a static library, and two binaries. Full of symbols, so I stip them
61124 bytes in libcxa.a
49356 bytes in libcxa.so.1
90380 bytes oblcpu_gcc
131736 bytes oblcpu_icc
$ ldd oblcpu_*
oblcpu_gcc:
libm.so.6 =>
libc.so.6 =>
oblcpu_icc:
libm.so.6 =>
libcxa.so.1 => not found
libc.so.6 =>
Ok, so the icc version needs the shared library to be loaded as well.
$ size libcxa.so.1 oblcpu_*
text data bss dec hex filename
22839 3008 124 25971 6573 libcxa.so.1
70563 15860 1923912 2010335 1eacdf oblcpu_gcc
93858 24236 1923768 2041862 1f2806 oblcpu_icc
Codesize for gcc: 70563 bytes
Codesize for icc: 93858 + 22839 = 116697
Hmm, that is a 65% increase in code size! Not to mention the increase in data size (can anybody say 'lookup table' or 'buffering'?)
Hmm... I wonder if they tried gcc optimizations such as '-funroll-all-loops'. Too bad they didn't provide the source so we could verify the results.
I got a free evaluation CD from Intel with the February issue of "Linux Magazine", so I'll be doing my own comparisons thank you.
--- Hindsight is 20/20, but walking backwards is not the answer.
The gain is obviously highly dependant on the application.
I tested the Intel compiler against GCC using Robert Hyatt's excellent crafty chess engine and the speedup was only 7%. (Athlon 1.2Ghz)
On a PIII-500Mhz the speedup was only 2.5%
Of course for other application results with vary, but I for me the Intel compiler isn't worth the money or the effort.
Hats off to the GCC team for building one of the greatest tools of all time. You can't beat GCC for sheer usefulness and ubiquity.
One other possibility is to use the free-for-use but not open-source Linux version (mentioned earlier, so I'm basing this on hearsay) to compile your own system.
Distros like Sorcery and Gentoo, which are geard to allow you to have the most optimized OS possible for your system could greatly benefit by this.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
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.
Everyone seems to have their heads so immersed in "computers == x86" they can't see the obvious:
A point I'm suprised no-one has made yet - GCC is a great compiler, and it's optimiser kicks ass, on sensible (read: orthogonal etc.) CPU architectures (Sparc, PA-RISC) and even semi sensible ones (Motorola 68k).
HP compiles the HP-UX kernel for PA-RISC with gcc, and not their own compiler, because it produces the tightest code there is for their platform.
The 80386 is definitely non-sensible; an ungodly mess nothing short of Byzantine - 16 different registers, with no two with instruction sets alike. 80 bit data formats. 8 and 16-bit legacy modes. It shares the unqiue distinction of being even uglier than VAX. Intel would have scrapped the whole steaming turd many moons ago instead of reinventing the 1970's and microcode, were it not for the Wintel monopoly fuelling the fire for faster 80x86 compatibles.
This has chicken-and-egged its way into the open soruce world - the ultimate reason I'm running Linux on P3 and not a Sparc, PA-RISC, 88100, MIPS, RS6k or whatever is because of Microsoft; yes really - the Wintel (or DOStel) hegemony made x86 the best bang for buck architecture through economies of mass production, even though it ***sucks***, which is why Linus Torvalds had one as an impecunious student in 1986.
Now, I'm trapped in the Wintel sheep model on a smaller scale - I have a P3 for the same reason that most people have Windows; I'd have a Sparc or Merced based Linux box in a heartbeat, but all the Linux software I like to use comes ready-rolled for x86, and no I don't enjoy typing "make" 15 times just to install intant messaging.
It's hardly surprising that Intel's code optimiser does better on their archtecture (including 3rd party implementations thereof). It's very goofy to try to optimise for x86. I think you'll find the Intel / GCC gap to be a lot smaller on Merced (IA-64), which is a more sensible setup.