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."
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.
The article itself states the compiler itself is not open source. So how's this going to cause it to be chosen over GCC when it (probably) won't be distributed to the same degree as GCC?
Q: Why do people use MS-Office?
A: Because its there.
Q: Why will people use GCC?
A: Because its there!
Same concept, really. Most Free Software will continue to be built with GCC until Intel releases this compiler under the GPL, performance not withstanding.
"Insanity is doing the same thing over again expecting a different result."
As long as intel's compiler is not GPL and does not support as many architectures as gcc does, I don't think gcc will vanish any time soon.
Plus everytime benchmarks showed that a closed source product was faster/better than the free software counterpart, the open source community worked hard to improve its champion.
gcc is dead, long live gcc
!
^_^
I really hope Mozilla will soon compile with Intel to see how it compares with GCC as we cannot compare yet OS/compiler (Win32 builds uses Visual C++, Unix use GCC most of the time):
evaluate Intel's C Compiler
wolruf@gmail.com
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.
Intel compiler: it's highly optimized to generate
intel architecture specific code. GCC is
architecture independent. Surprise!
Intel would love for people to compile Intel
only.
CPUs are so fast these days most people don't
even bother to turn on optimization. Not
worth the 2 seconds it takes to type "-O34".
GCC support fortran and java too.
If unix vendors hadn't started seperately
charging for the "C" compiler, GCC would
still be a research project. Screw it, give
the free beer and free speech.
-
GCC isn't the worlds best compiler
-
Linux not only crashes and has bugs, but
some of them are caused by ego clashing and political tension... AND there are
zealots who will try and cover them up.
-
Mozilla (the shining jewel of Open
Source) is years late and many dollars short of beating IE.
-
Loki is dead and so goes the myht that
Linux is a market that is large and willing to buy. They listened to the Linux
zealots and got screwed.
-
Slashdot is squelching topics and
moderators are abusing their power - so there goes the myth of the open minds
of the Open Source community. The dream is gone and good riddance.
In the end, I like and support the Open Source world... I think amazing things have happened... But your much better off when you realize it is simply another dynamic - it is not the best one and it certainly isn't the only one. Fight tyranny and repression.... read--> Fight tyranny and repression.... read
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...
I am, however, surprised with one thing: Why doesn't Intel try to improve the GCC itself? They sell hardware, after all, and it would really benefit them, when they could say "Our 1GHz CPU is 40% faster than AMD 1GHz CPU using the standard GCC compiler." Intel should want every compiler on Earth to use their optimization (so should AMD and others), not only their compiler.
~shiny
WILL HACK FOR $$$
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 :)
GCC will still be in very wide use, since it comes with Linux and it does a quite decent job. But anyone who really cares about performance will seek out the better alternatives, like Intel's compilers. This is not news, and it's particularly not bad news--we all want freedom of choice, and the more genuine alternatives everyone has, the better, right?
Becasue they could inadvertently improve gcc's output on non-intel architectures, perhaps? - GCC compiles to an intermediate tree form called "RTL" first, and thus some of intel's higher-level optimisations could end up imporving gcc PPC code, say. And that would be a bad thing for Intel, in the same way as you don't see Microsoft coders adding completion ports to linux to improve linux server I/O.
(although, a lot of intel's optimizing is probably due to their knowledge of the arcane, baroque, and just plain stupid x86 architecture, and thus would not be applicable to saner CPUs archs like... virtually anything else currently available.)
Choice of masters is not freedom.
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
In essence, the Intel compiler attempts to maximally exploit the 128-bit Streaming Single-Instruction-Multiple-Data (SIMD) extensions on packed integers and floating point numbers, which enable fine-grained code parallelization, found in the Pentium III and Pentium 4 CPUs.
/.'d since assembly is now going to overtake C?
So the compiler produce code that only is optimized for Pentium III & Pentium IV CPUs. So it is not a production quality compiler because it can only produce code for specific processors of an architecture family.
I really don't see what the big deal is. If I wrote a program in assembly to take advantage of these extensions on a Pentium III does that mean I can get a story
int func(int a);
func((b += 3, b));
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.
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.
As someone who spent about twenty years of his life as a professional compiler writer, no, that's not the problem. My company marketed compilers for Pascal, Modula-2, C, C++ on the PDP-11, Vax, M68K, Sparc, N3200, MIPS and x86 (not all languages on all platforms). All based on a single technology.
We routinely beat the system vendor's offerings on benchmarks and (more importantly) real programs.
And we went broke a decade ago, oh well. Compilers became a commodity and we didn't figure out the consequences in time...
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.
Wow, everyone that I saw posting apparently believes that their home computer is the end all and be all of computing. You're an idiot.
./configure figures out which to use.
Look, we only use a handful of Linux machines, so we aren't likely to use this. However, if I was rolling out 1000 workstations in my enterprise, and we were tweaking/tuning the OS before rolling it out, recompiling with this would work.
Assuming Red Hat makes compiling under the Intel compiler a requirement for inclusion in their distribution, they're in a great situation.
Why not compile everything with an optimized compiler? You still have the freely redistributable GCC for compiling open source code, but for stuff that is being downloaded in binary format, wouldn't you want it to run faster?
Does it compile quicker? Who cares. When you are doing software development, you want something that compiles quickly. When you are rolling out a production environment, free speed is good.
Look, your precious GCC is terrific, it is a flexible, cross-platform compiler. It's always been week on the performance. The GCC team has always made it clear that the biggest problem ISN'T processor-specific tweaks, its general compiler improvements that are patented.
GCC is a baseline, things should compile with it. Things should also compile to the POSIX standard. That doesn't mean you don't add tweaks on the platforms that you support and set it up so that
Give me a break. I realize that many of you just use Linux to configure and tweak Linux to the point that you can post on Slashdot about how you can do anything with Linux. However, those of us that have included it as one of our tools to solve problems can use ANY tools that are made available to us.
If I can get a 47% performance improvement by recompiling some of my applications, terrific. Replacing the server may be cheap in terms of hardware (a few grand for a new server every 6-12 months isn't bad, its one of the few reasons to use x86 servers), but it takes time. Building and testing new hardware is easily 2-3 man-weeks before TESTING (expensive, look at your salaries and double it to estimate costs to the company), recompiling on your test machine and testing is just the testing time.
Alex
One of the biggest hurdles in getting GCC's optimization up to snuff with closed source compilers are patents. Optimization is a patent minefield. Compaq's got 'em for specific optimization techniques they use in their Alpha compiler, Intel's got 'em for their compiler, Microsoft has them as well. Kinda skews the playing field.
* You should say "open source," because saying it isn't free is ambiguous even in your mind, and downright wrong in an accountant's mind. This isn't the show-stopper you seem to imply it is. People have been using and will continue to use closed-source compilers for many, many years. Take a look at the popularity of VC++, Watcom, Borland, etc. in spite of the free (as in open source and $$$) availablility of GCC on Windows.
You're comparing apples and oranges when you try to argue that since Windows people use closed-source compilers, then Linux people will also. These are completely different groups of people, and I suspect that plenty of people in the Linux community will start using a closed-source compiler when they pry the gcc source from their cold, dead hands.
* No, they didn't compile kernels. They compiled (and tested) ON multiple kernels. Don't you feel silly now, contesting so loudly a point you misinterpreted?
Christopher wasn't the misinterpreter, Slashdot was. Did you read the text he quoted? "the new Intel C/C++ compiler's geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC." You cleverly omitted the bolded text.
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.
Chill. Chris wasn't being a zealot, he was simply offering counterarguments to the ridiculous claim that Intel's closed-source, x86-only, C/C++ only (I bet) compiler spells death for GCC.
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.
Intel is a business, and for them to succeed they need to sell their product. They're right in saying that they need to have people create applications which require more processing power. How does this harm you ? Unless all you need is to run Word, chanes are one of these apps may interest/benefit you. They've developed a compiler which is optimized for their product. How does this harm you ? They know their architecture better than anyone else, so I would expect them to release an optimized compiler. Nothing is stopping AMD or anyone else from doing the same for the Athlon. If it's free, nothings stopping you from using both.
Ultimately they succeed at their real goal: to make money. As a side effect, you get better apps, more powerful procesors and an optimized compiler. Damned capitalists
Don't forget that gcc can do SSE these days, as well.
Check out the gcc HEAD branch, and try something along the lines of
-O2 -march=athlon -mcpu=athlon -msse -m3dnow -mmmx
This message is provided under the terms outlined at http://www.bero.org/terms.html
The Intel compiler auto-vectorizes. This is not the best thing to do in all cases and there is no evidence the Intel compiler can tell when it is best. Using the SSE2 as a 64 bit FPU unit is better than using the built in FPU but not as good as properly vectorizing your code.
For example, suppose I am performing a converging FPU calculation. If I use 32bit floating point and vectorize it until the last few calculations that use 64 but I will destroy auto optimized 64 bit all the way through. Or, perhaps I have parallel threads running that I have vectorized myself. One thread is a vector and the other is straight FP. It is possible that the Intel compiler will actually reduce the performance of the code.
More seriously, these are vastly unfair benchmarks. Benchmarks like these typically involve calculating tight loops of code. In this case, "mathematically intense" code is almost all FP. Therefore, what we are being shown is the worst case scenario for a small piece of simple math code that likely could be hand vectorized for far better performance. If it wasn't a tight loop of FPU code the vectorizer would have 0 benefits. Take the typical application with massive amounts of integer code and FPU code that branches unpredictably and you will get absolutely no benefit from the Intel compiler.
As a side note, the VAST compiler on PPC does a similar kind of thing and hasn't supplanted or substantially influenced the use of other compilers. This is in light of the fact that it provides a much more dramatic performance boost in that domain.