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."
The difference between Intel compiler and GCC is even more than 47% in number crunching.
Architecture dedicated compilers may well be faster, but gcc's performance has already reached a 'good enough' stage.
What's more important is that gcc provides features that are absent from all the other compilers: gcc works virtually on any architecture, and offers a stable (in its functions) platform, and an unique interface to low-level features (such as building calls dynamically) as well as very good extensions. It demonstrates how free software can offer a standard, and not be affraid of 'innovating.'
so, intel/dell/sun's compilers may have their place, but they don't play in the same category
as gcc. They're useful for dedicated performance apps, or things like games.
. . . . . . .
may u!sh 2 sm!le at dz!z bad nn.!m!tat!ion
I'd agree with the gist of what you are saying, but some of your bullet items are just oversimplified, overstated bollocks.
sic transit gloria mundi
...the gcc isn't the most 31337 compiler out there. I've seen the gcc slowing down programs on a Atlon 800 MHz down to the performance of a 400 Pentium III (II ?) (scientific apps).
But isn't the main strength of the gcc it's crosscompiling abilities ? Never heard of any compiler supporting so much platforms.
Owner of a Mensa membership card.
~shiny
WILL HACK FOR $$$
While you're right that some of the optimizations are higher levels, alot of the stuff GCC doesn't currently optimize is instruction pairing, data prefetching, etc...
That is a lower-level backend issue and won't seriously improve the other backends at all.
The OP has a point though, by upgrading GCC instead of making their own compiler more people will have access to a compiler that makes code tuned for their processor better.
For instance, I have a PIII [I don't but lets say I do]. I write code and build it in GCC. I go out and buy a PIV [roughly same clock rate] I notice that my code is not significantly faster. I get pissed off...
However, I buy the PIV and tell GCC to use PIV specific optimizations, my code turns out faster and I am happy.
Tom
Someday, I'll have a real sig.
It is quite possible that a similar improvement could be achieved by GCC in floating-point intenisve code simply by supporting SSE2.
"The good die first." "Most of us are morally ambiguous, which explains our random dying patterns." --- MST3K
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
Really, that way you and everyone else could benefit.
~shiny
WILL HACK FOR $$$
"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."
I'd say since there has been alot of time invested in GCC [and its vastly more portable], if the Intel compiler was made open source the GCC dudes would just try to merge the intel optimizations in.
Keep in mind that GCC doesn't just compile for x86 processors [its only intel that does]. So even if Intel releases their compiler for free [open source style] that still won't kill GCC.
Tom
Someday, I'll have a real sig.
"No, what's great news is that Intel's compilers are available now on Linux."
... but still a lot of excellent scientific computing software is written in fortran77, e.g. LAPACK)
I totally agree. Unix has always been popular in scientific computing and egineering, but I know of several people switching to WindowsNT because
a) intel systems are extremly cheap (compared to architecures optimized for number crunching like RS6K)
b) compilers available for NT produced MUCH faster code, e.g. Digital fortran. (Yes, I know
When it comes to numerical simulation, run times in the order of weeks are not unusual, so a performance penalty of 50 percent is simply unacceptable.
So this may turn out to be a big win for linux in the scientific computing area.
sig intentionally left blank
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.
You have to understand benchmarking people. When they say kernels they mean benchmarking kernels. Small contained programs that extract key loops or algrothmns from larger programs.
They have a suite of keys loops where each is inportant to someone (fft, lloops, matrix mul, 3d geom, etc..) and determined that in general Proton (the internal codename) is much faster than GCC. Of course it is.
If only it was free. Unfortunatly, Intel built that compiler on several other companies IP and can't release the source.
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.
http://gcc.gnu.org/steering.html
I think you'll find GCC development currently to be some of the most transparent and open of any project out there. Period.
here. Only for non-commercial use. At least the cost factor will no longer be a problem for some users.
Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/
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?
Actually, GCC's speed sucks, at least in part, because software patents suck. See for example Compiler Patents, or register allocation patent, or graph-coloring algorithm a nonoption. Then complain to your congressperson (or non-US equivalent).
The only area where 8 and 16 bit chips are of any importance is in embedded systems with low performance requirements.
And a surprising number of those 16-bit embedded systems are based on the x86/DOS platform. The FreeDOS project is still relevant.
Will I retire or break 10K?
Actually, geometric means tend to reduce the impact of one "outstanding" result.
A quick example, 3 data points, values (2,2,16)
The arithmetic mean is (2+2+16)/3=20/3=6.66666
The geometric mean is (2*2*16)^(1/3)=64^(1/3)=4
They've used the geometric mean precicely because it doesn't skew the entire result if one test improves greatly.
Quidquid Latine dictum sit, altum videtur (anything said in Latin sounds important)
Actually Linux distributors can put anything on their CD's they want, provided that they have the permission of whomever owns the code. Debian does refuse to put anything in their distribution that isn't free as in speech, but that is their choice.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.