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.
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.
...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
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.
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.
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.