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 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.
Since it looks as if Borland is going to release their C++ compier for Windows, I'd like to see how it compares to Intel C++.
What about the OpenWatcom project? Are they going to be porting to Linux any time soon? I recall their compiler being quite good as optimizing under DOS and Windows, and it has run on UNIX-like OSes in the past (QNX).
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'.
The difference between Intel compiler and GCC is even more than 47% in number crunching.
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
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
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
Yeah not to mention a lot of the GCC developers are ALSO paid to work fulltime on it.
OK, let's stop the useless "open source sucks"-zealotism now.
Intel C++ is only faster because Intel is the creator of the Pentium.
They know everything about it, and thus know how to optimize code.
Even Microsoft's Visual C++, one of the most expensive compilers around, don't optimize code as well as Intel C++ does.
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.
Why in the hell would intel release a compiler that makes stuff run faster on their chips? I thought they wanted stuff to run slower so everyone had to buy faster processors.
Oh, right, that whole 'competition in the marketplace' thing. Funny, that.
By a 47% performace increase ove gcc does it mean the resulting binaries are faster or does it mean the compiler is faster?
I kinda have a soft spot for gcc tho!
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.
Damn it AC, if you're going to post intelligent things like that, log in as a real user so I can add you to my friends list!
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.
I don't get it - why is that important?
But that's a minor issue, the important part is convinced - I am throwing my gcc out the window and paying half a grand for Intel C/C++... (somebody needs to come up with a damn "roll eyes" smiley)
sic transit gloria mundi
-
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
Who cares.
It seems it doesn't run on AIX, Solaris, or in other locations either.
If they want to 'take on GCC', they have to run were GCC runs. Otherwise, what will keep happening is if people want/need more speed, they'll buy a new processor.
Non-event, nothing to see here, move along.
What about asking AMD to contribute and develop a blindingly fast GCC optimizer for AMD processors?!
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 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.
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'll be selling my G3 so I can buy an Intel machine and pay $500 for a compiler (or $1000 if I want it for windows, too) whose somewhat impressive numbers come against an old version of gcc and with limited types of testing done. Yep.
Points 2 and 4 are well taken, but --
This helps users of PPC, Alpha, and StrongARM exactly how?
Do we really need this sort of trolling on a story on the Intel compiler, Cap'n Obvious? Maybe you could tell us how the Compaq Alpha compiler helps Intel users?
Hey, according to the open-mag front page
the compiler article is for subscribers only (snicker).
I'm guessing they used 2.95.3 because that's what comes with SuSE 7.3. 3.x still has some major issues and isn't suitable for most systems, but it uses garbage collection so it's _much_ faster. I'd like to see the results then.
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.
Score -1, redundant
Umm, we already know all this.
Hail to the king, baby!
So I download the binaries, and the Intel version gets it's own dynamic libary...is that the part Intel hand crafted for speed, or did the compiler decide to create that all by itself?
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!
...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.
If you want to drive fast, you have to spend money, if you want fast optimized code, you have to spend money.
Free is good, but as KDE is demonstrating, the free software community is having severe performance isssues when developing large scale desktop apps. Same goes for Mozilla, Star Office etc. Hell my 8 mhz Atari ST loaded programs faster off a floppy than KDE loads programs on my old 333 Cyrix.
Hopefully this will wake up the open source community and urge them to focus on performance as well.
But they wont, they will simply toss a few flames, stick their head in the sand and deny it all exists while waiting for another microsoft bashing story to come out.
If someone needs hyper-optimized code for (intel)x86 only, sure this compiler rocks. It's a big world out there however, and Intel only comprises a small percentage of the microprocessors on this planet. The bottom line is that regardless of performance, gcc is still the most portable compiler anywhere and for a lot of people, this is more important. After all, Microsoft takes advantage of the fact that computers get faster and cheaper and so will gcc. For most situations, you don't need the fastest code because the human interacting with it can't tell the difference. Gcc isn't going away. Visual Studio isn't going away. Chances are, intel's compiler won't be used by anyone outside of very specialized number crunching applications because gcc and VC have long ago reached critical mass on their respective platforms.
In Soviet Russia, hot grits put YOU down THEIR pants.
This is just a nice weapon in our arsenal. If I were a competing CPU, I might want to develop an optimized compiler for my cpu on Linux/BSD. It is nice that commercial apps are coming to linux (and hopefully BSD).
But replace GCC?? not until this is truely free (source and $) and runs on any CPU. When it is open, then they will see real market penetration. But until then, I will keep my dependable, well understood, open gcc.
There are quite a few pages that claim exactly the same about performance (but not about gcc's demise.)
Gentlemen, you can't fight in here, this is the War Room!
Intel clearly states that this compiler CAN NOT compile the linux Kernel. As a matter of fact, the linux kernel contains a lot of inline assembler... Some versions of gcc also had problems with this, but this was mainly caused by incorrect kernel code. I never heard of somebody compiling the linux kernel with anything else but gcc, "the recommended compiler". I do not know about other kernels, but I would be very surprised if there was a *nix which did not use its native compiler for its kernel.
sig intentionally left blank
From the artilce:
"Along with the Linux executables, you'll need to distribute the Intel run-time library, which you are completely free to do under the Intel license."
So you code relies on some prorietary black box.
Sorry. No thanks.
Intel's new compiler does take advantage of the
esoteric ordering of instuctions in their new
architectures. This is a great thing, no doubt.
But give the GCC coders a chance to play with
it and they'll come up with the same tricks.
Hopefully it won't take as long as Mozilla/Netscape getting better than IE, which
took like 4 years.
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
Also, VS.Net is not a beta product: it went RTM last week.
GCC going away is about as likely as Microsoft going away.
Doesn't matter if they both suck. Market share is important...
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 :)
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.
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?
plan C: GCC, ???, Profit!
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.
Why are there so many posts saying either "this will kill gcc" or "gcc still wins - yadda yadda"?
Gcc works on almost any platform out there. It's pretty slow, though.
If you have a "native" compiler for your platform, use that - otherwise, gcc is there. SGI's MIPSPro, for my purposes, generates code that is usually 3 or 4 times faster than GCC's on a mips4 isa. Suns CC usually gives me about twice the performance. There's nothing ominous about using a "native" compiler when one is provided, but gcc doesn't "die" because of it. It's a reasonable compiler that you can always count on being there, regardless of platform.
As long as people remember to write their software in ANSI C/C++, there shouldn't be a problem, should there?
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.
You might find Alpha and StrongARM on the Intel list...
If you're not part of the solution, you're part of the precipitate.
GCC has been second in execution speed, features and quality of generated code to vendor-supplied compilers for as long as written history recalls.
That never stopped GCC adapation before. Apparently, other factors play a more important part. Some will be relevant - such as availability, portability, and freedom from arbitrary architectural chains - and others will be irrational.
Even if there were an entirely superior, freely available platform- and architecture-agnostic compiler, GCC would still dominate by the power of its dominant entrenchment in current technology. This shouldn't surprise anyone, in this world dominated by mediocrity at best.
Great! Someone is making a product that
will add value to computers. Most folks will
balk at the closed source and asking price;
but this can add value to open source and
closed commercial products. If you are doing
something like making the next "Shrek" and
running a server farm or something. You
can recompile a few key modules using this
compiler and speed things up 47% percent.
On some of these "2 week" jobs, this can
save 6 days. Hard core, long running, high
value programs will benfit mightly from this.
Sounds like a great compiler but the heavy handed
promotion of the product in the article is a little bombastic.
The code tested computed some kind of geometric mean... It is not surprising att all that performance can be improved significantly by optimising against parallell instructions (such as SSE/SSE2). There is no guarantee that any major improvements will be seen on an "ordinary application".
However, I will find use for this information and I will try Intels compiler and compare it to GCC.
Very minor changes in the code of this kind of high-performance applications can result in very big speed-ups, with any compiler. It would be interesting to see some real world problem (some PDE-model or something) based on for example BLAS (Basic Linear Algebra Solver, or something, www.netlib.org), being computed with gcc/icc and see the "real" difference.
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
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.
sic transit gloria mundi
Optimizations or more platforms? Or more people to the project?
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
By charging for their compiler, they acomplish two things:
1) They make money off people who can afford it
2) They make money off people who can't, and thus need to buy a faster PC.
autopr0n is like, down and stuff.
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));
1) gcc is the best compiler
2) linux may crash; but I've never witnessed it.
3) Mozilla is a jewel, true; but the crown
jewel of open source is Apache: 60% market share.
4) Loki? Oh yeah, Open source relys totally on Loki.
right.
5) uh, well, yeah moderators do suck.
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.
The best performance measure is running your code on a variety of systems. Because most people can't do that, it may make sense to look for standard benchmarks that look like your code, and then make analogies based on the similarities of those loads to what you want to do. It's critical to pick the right benchmarks to have a good analogy; if you're interested in 3d performance, it doesn't make sense to make performance comparisons based on the number of rc5 keys per second.
Unfortunately, the Open Magazine article doesn't give any information on what exactly their tests are doing. So it's not possible for you to figure out which, if any, of their tests will be analogous to your code. :-(
As I've mentioned before, I'm mostly interested in integer performance. From what I've read about the Intel C compiler, its strength is floating point. If I did a lot of FP work, I'd be sending Intel a credit card number about now, and I imagine many FP people will.
But for integer work, I think it's not so clear. Andreas Jaeger has a nice page benchmarking versions of GCC. On Athlon processors, SPEC CPU2000 CINT2000 base looks like it's around 10% faster when built with the Intel C compiler than with GCC 3.0.1. I think I can live with that.
It's a lot easier to modify gcc than icc too, and yes, I really do hack on gcc from time to time.
Open letter to the authors:
This is a very interesting article, and I'm sure that it will be food for thought for many people.
However, I think that some important benchmarks were accidentally omitted. Could you include your comparison of the Intel, Microsoft, and GNU compilers on powerpc, sparc, alpha, mips, arm, and hppa?
Thanks,
Daniel
Hurry up and jump on the individualist bandwagon!
Numerical computation code running on Intel
Windows and Intel Linux will run at exactly
the same speed. OS overhead is negligible
in this case. Linux may be faster or slower
but that's a seperate issue.
Are we surprise that Intel's compiler is better than GCC? We better not be -- they own the CPU after all.
However, *I* am surprise that Intel's compiler *is* in fact better than Microsoft's C++ compiler (which is if you used it). After all MS has a whole army of codders working on their compiler (not to mention for 15+ years). MS should know all too well by now how to write an optimized compiler -- and bug free, support for the latest standard, and on and on.
Now *THIS* should be the news of the day not Intel vs. GCC.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Soon they'll cry because we don't properly call it Intel/Linux as it obviously should be as it's based on an Intel compiler
Not meaning to be 'anti-GCC' for a moment, but on my Beowulf cluster, I get remarkably better performance with ifc/icc (The Intel Fortran/C/C++ Compilers) than I get with gcc/g77. Dont get me wrong, gcc is still my perfered compiler, and I use it for almost everything, but when it comes down to sheer performance so that my Intel/AMD hetrogenous Beowulf can make similar performance stats to thoes of all Alpha's or SGI's. The Alpha, and SGI have wonderful compilers that optimize the code very well, however, the drawback of this over optimization is that the code becomes very unportable. And that is where GCC is getting better, for alot of code is very portable, since its not optimized for a specific archatecture. But if GCC wants to make good solid inroads in the R&D world, they need to start building some good optimization routines. I know this defetes some of the GNU-ology behind it, but, the poor performance on gcc is what makes all the researchers use the commercial compilers. So say what you want, but the Fluid Dynamics, and Finite Data Analysis guys out there will tell you that they get better/faster results on PGI or Intel, or Compaq Alpha compilers than on GCC, and they spend hours/days/weeks/years optimizing the same code in order to get 1/2 ms faster compile times.
Just my 2 Cents.
"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."
If I read that correctly, it means that they did all the tests with gcc2. I think gcc3 version has not been optomized as much so it would probably be worse, but it would still be interesting to see how they compare.
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
Please, Intel's compiler has _always_ outperformed gcc on the Intel architecture. DEC's compiler has always outperformed gcc on the Alpha architecture. Sun's compiler has always outperformed gcc on the SPARC architecture (but not Intel). The bottom line is that NOBODY CARES. Gcc is the world's most portable compiler, over both architectures and operating systems; that is why it is the most popular. The people have spoken; they have demonstrated via usage patterns what truly makes a great C compiler. It is not speed.
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.
OK, it's interesting as an experiment in Intel-specific compilers. As a baseline when testing out any new x86-compatable processors, it's probably a critical tool. But otherwise?
Seriously: Why even bother?
As for proclaiming GCC dead...please. Speed benchmarks and compilers are notorious PR pieces. I can't think of a better example of pure sensationalism. Disagree? Prove me wrong.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
If they don't mod all those things down, Slashdot would become a chaos, the home of trolls and flamers (oh wait, it already is).
The moderators should mod up interesting discussions, not mod down those that don't fit their agenda.
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.
GCC is evolutionary not revolutionary :) And the Intel compiler article is too emotional, with big words. Sorry. I'd have to ses a running kernel compiled with icc perform 47% better than gcc.
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.
I've read once that most of code optimizations couldn't be implemented in GCC because they were patented by Intel or IBM or , does anyone as info about this ?
I completely agree. Other companies have produced optimized compilers which have had better performance that gcc, such as The Portland Group and Kai (which is now part of intel... go figure) and they have not shut down gcc. Gcc is a good, free compiler. The rest may be faster, but not worth the price for most of us.
Idol Star Astronomer
Compaq released Linux versions their C/C++ compiler suite for the Alpha chip a few years ago. A few adopted it for their internal applications. If I recall correctly, I think one of the digital visual effects firms compiled their renderer using it and got a 5% to 10% improvement.
However, GCC is universal. It runs everthing, targets anything and costs nothing. Nothing in terms of both Beer and Speech.
This is a boring sig
hey, you're a fattie arent ya. NICE PIC
:)
seriously though, the point is gcc is slower than the intel one on standard stuff. Noone is talking about your preacious linux kernel. I agree its a great free compiler, but if you're making something where you need speed.. it blows
I am very suspicious: Jack Fegreus (open-mag's editorial director) may hail from a biased background. A simple search on Google brought up tidbits from his past like:
Jack Fegreus, my former boss at Digital Review , is now the editor of the Windows NT-centric BackOffice Magazine .
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.
Changing the compiler to improve the speed of a program is braindead anyway. To me a compiler has to be -reliable- not just "fast", most optimizations that really make a difference are implemented at the algorythm level, or through hand-coded assembly.
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.
I'll stick with REAL computers running a REAL OS (UNIX) and not companies who are controlled by the MS MARKETING MONKEYS.
It's not free software.
/.. I am very thankfull for people like RMS who remind people that linux is as much a political or moral statement as a technical one. Luckily, or not, gnu software stands on its own technical merits. Where it doesn't it still stands on its own morally or politically.
Who cares?
I do, troll. I can't believe how many clueless people are making their way onto
If Intel really wants to help drive linux, why don't they look at the gcc compiler and submit patches. Or if they are too weak to do that, release their compiler under GNU.
You get what you pay for.
Very true. I pay with my time, conscience and code. What do you pay with. Oh, yeah $. I hope you are proud.
The benchmark is not right; someone could be running something will the gcc version was running, they used time instead of clock which gives better resolution and gives only time the program has been running.
If you see something in particular in GNU C that you don't like or that seems inefficient, fix it or at least report it. Don't just whine about it.
GCC is free Intel's compiler isn't AFAIK. A commercial compiler would "have to be better" in order to be viable.
Thats nice, but it doesn't mean the end of GCC. Besides the fact that GCC is the offical gnu compiler it also works great. A littl eextra speed is nice, but working across platforms with the same compiler is much nicer.
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...
Your signature rocks. I'm pissed that I wasn't that creative now heh.
I was just singing along to it to hehe. Maybe we should come up with a full version of that.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
I just gave away a couple of high karma accounts on Slashdot because of:
Haha! So, 'high-karma' accounts is a commodity. How stupid is it possible to get?
If your ISP is fuckwits, switch ISPs, don't complain here.
If that was to techincal for you, go bugger off.
"Rune Kristian Viken" - http://www.nwo.no - arca
Note that Intel's compilers are available free for non-commercial work. I've written reviews of the Intel compilers, and my experiences suggest that Intel does, indeed, produce faster code than does gcc -- although not to the extent claimed in the Open Magazine article.
I'm no fan of Intel per se; read my article and Intel's responses for a full story. However, I'm not going to ignore Intel's delivery of high-quality Linux compilers for C++ and Fortran.
I'm using the Intel compilers (C++ and Fortran) for development of multiprocessing application; Intel supports OpenMP and gcc does not. Overall, I'm very happy with the Intel compilers, and recommend them to any serious developer. It never hurts to have more than one compiler, no matter what platform you're working on.
All about me
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.
I was working in Quantum Chemistry (number crunching for those which do not know what's about). We had a linux Cluster for some short calculation. For everything like graphics visualiser, OS related, Install package etc... etc... we used GCC. Why ? Because we wanted a sure result, a safe install. But for the application we *knew* needed a boost in FLOAT performance, like compiling the quantum chemistry software, we used Portland group Compiler. So In effect when building the Linux Cluster, gcc was used, but only for an application we used a processor specific good optimised compiler. And mainly because we could afford it...
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
Intel's compiler make faster code than GCC?
And you guys call yourselves "Cygnites?"
Shame!
Yes, intel's compiler is faster. For intel chips. However, I have heard reliable sources say that Intel's compiler is guilty of the same problems that a lot of "vendor specific" compilers suffer from... It is great for compiling SPEC, but not much else. For starters, the front end is not GCC compatible, so you can not compile the linux kernel with it. Secondly, many times, it sacrifices precision for performance. Ask the creater of ScienceMark.
This isn't to say that GCC doesn't need help. One of the biggest areas GCC needs help in is prefetch analysis. This would benefit all platforms, especially RISC and x86... Other compilers have had this optimisation for a looong time, and I bet that the addition of it to GCC would easily make up 60-70% of the difference with intel's compiler.
Other reasons the intel compiler won't replace GCC:
1) Only optimised for intel X86 CPU's. What about all the PPC, MIPS, Sparc people? What about AMD?
2) Doesn't support "GCC-ism's" in the pre-processor (many codes won't compile without modification.)
3) Closed source, binary only.
4) If you really need it, you can get closed source compilers with better performance (for intel and AMD chips) from other sites. Do a google search for "OpenMP, Linux, C" and see what i mean.
just my 2 cents..
pm.
- --
"I Hate Quotes" -- Samuel L. Clemens
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.
To be fair to the reviewers, I'll refer to the 2.95 GCC manual, even though manuals for 3.0, 3.01, 3.02 and 3.03 are already online. The sections dealing with GCC's "technology" are primarily sections 14, 16, and 17. There are gobs of optimizations in GCC, and lots of them are specific to target architectures. The way to define new architecture-specific optimizations is mostly spelled out in section 16. The means for doing this appears to be very general.
A fair criticism of GCC's technology would be to say that optimizations have not yet been defined for recent Intel processors, and Intel's compiler already has them. To say GCC could never have them sounds like a lie. The nice thing about GCC's open-sourceness is that people contribute new optimizations. Intel-specific optimizations would be keenly interesting to a lot of GCC users, and the only reason they wouldn't happen would be that Intel hadn't released enough architecture information to make them possible.
Perhaps the hot new compiler technology about which the reviewers are so thrilled is the trade secret?
WWJD for a Klondike Bar?
I would just like to remind everyone that performance is great, but not at the expense of security. Does anyone remember that example of the compile that inserted its code into the login command?
Without this compiler being open source, how can anyone trust it? Who is to say that the FBI program is not in the code, and won't provide them a easy backdoor into our systems?
Hi, I did a quick test with bzip2 on linux-2.4.17.tar(.bz2). With gcc, I used the default optimisations ("-O2") that bzip2's Makefile has, and with icc I changed that "-O2" to "-O3 -tpp6 -xK". Not that much of a difference. This is on a dual Pentium III 750Mhz machine, although it's only using one processor.
gcc bzip2
real 2m15.671s
user 2m12.690s
sys 0m1.630s
gcc bunzip2
real 0m40.445s
user 0m35.390s
sys 0m2.910s
icc bzip2
real 2m6.991s
user 2m3.940s
sys 0m1.650s
icc bunzip2
real 0m36.950s
user 0m31.810s
sys 0m2.990s
1, 1, 2, 3, 5, 8, 13, 21 -- Mathematics is the Language of Nature.
I really don't get why anyone in their right mind use that GCC crap, there isn't much that good about it. On many platforms it even generates the wrong code sometimes.
The GNU Project was a technical project started by RMS. It is completed. The goal was to create a free unix-compatible operating system. That has been done. It's reached critical mass. Companies like IBM can now take over the maintenance because it's in their interest to do so. That was the point (see the GNU Manifesto) but most people said it would be impossible at the time the GNU Project started.
The goal of the FSM is socio-political --- promoting the idea of freedom for computer users. That is ongoing work.
There is still the overhead of the process scheduler and the virtual memory system.
Who said that gcc is obsolete? What a ridiculous notion! Intel's compilers may be fast, but they are Intel specific -- gcc is a amazingly portable, cross-platform tool. Why can't the two tools be complementary instead of antagonistic? I'm building code for clusters of multiprocessor, Intel-based computers; for such work, the Intel compiler is exceptional and provides tools (OpenMP) that gcc does not have. Yet gcc is my compiler of choice for other projects where portability is paramount.
Narrow minds are limited minds.
I'm all in favor of lots and lots of tools for various platforms; competition is good. It amazes me that Open/free software advocates complain incessantly about monopolies, but then take offense when someone treads in their sacred territory. Intel, Borland, and other vendors will provide impetus for the evolution of gcc -- and that's a good thing.
All about me
It's not free software.
So? Neither is anything by Microsoft and they have taken over. I'm not saying it's right, but it's true and it ain't free.
I heard it is GCC, am I right?
"It's not free software. "
And thats supposed to mean jack?
I tried it on a computationally intensive program I use in my work (PAML) - plain C (not C++), on my PIII 1GHz Linux it runs about 35% faster compiled with icc with all the optimizations turned on than the gcc code (-O3 -march=i686 -mcpu=i686). This is a significant gain when my typical run of the program takes ~2 days at 90% CPU usage.
How does this intel compiler compare to drs's agcc (as opposed to pcg's) optimized for pentium class and athlon chips. It can't handle the kernel but it can take just about anything else.
Once the rockets are up, who cares where they come down!
Biting at the troll ...
/opt and leaves things alone, thankfully. They did get it to work under SuSE.
It's not free software.
It's free as in beer for uncommercial uses - go ahead and download it yourself. The only problem seems to be that they say it's just for RedHat or TurboLinux. However, it seems like it just puts itself in
geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC.
The testing didn't involve compiling kernels at all
I believe this misunderstanding comes from the fact that they called their different benchmarks "kernels" for some reason.
Ian
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
If you think that free software is a political stance, fine. However your comment about Intel being weak makes you sound like a typical gimmie-gimmie free beer type, and very clueless yourself. Intel has dumped millions of dollars into RedHat, VA, Cygnus to improve your system.
Hello,
I tried Intel's C++ compiler on a pentium 4 running Linux. (Yes, they have an evaluation verson of their compiler for Linux.)
The results were disappointing on my own pet benchmark: the scientific simulation I use.
The Intel C++ compiler produced code 2x slower
than gcc. I used "naive" optimization flags
like -O3, etc.
PM
Who cares about performance?
Seriously.
Everything on my computer runs plenty fast at the instruction level except for:
mprime (distributed prime search, though I think this is written in hand-tuned x86 asm)
quake 3 (my video card is the bottleneck, and I also believe that speed-critical parts are written in hand-tuned x86 asm)
I suppose I should include multimedia encoding as well. (I am not sure how these were written. Maybe a faster compiler really would help here, if I had the source to recompile.)
Being faster is nice when it comes at no cost, but I say it is one of the least important goals of a compiler. Much more important is being reliable (doesn't make mistakes, doesn't crash, is compliant with the language definition if it exists), being available on many platforms, and in this case, being Free software. If GCC gets these optimizations, great for them, I will upgrade. But I consider a move to the Intel compiler a downgrade because (though it may have better performance) it fails at least at portability and freedom.
(By the way, I think that the way they summarize their numbers is quite misleading. The geometric mean really exaggerates those two benchmarks that Intel creams GCC on (probably because the Intel compiler recognizes some loop idiom that it knows how to compile efficiently). What I saw looked like an average 10%-20% better performance, with a few outliers.)
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.
For the majority of linux users this doesnt matter, because the majority of linux users dont do anything productive with their machines anyway. They are too busy downloading child porn. But for people who do numerical work, this is a huge win. For scientists and engineers these compilers are a must have. For you typical linux lusers this wont help you be any more lame than you already are.
How? That he's biased towards editing computer magazines?
Do you only accept your agitprop from central committee-approved sources?
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.
- GCC is a good compiler. It has some handy extra features (macro varargs), produces sensible warnings, and works "good enough" for most development. It also works nicely with gdb.
- The GNU tools are extremely robust. There have been several times when I've had to go in and change things due to bugs (limitations) with Solaris sed or cc. Like trying to get sed to work on the really long lines of text that the preprocessor generates sometimes.
- The GNU tools are there on all platforms. I can, without modifying the Makefile significantly, compile the same tool on my Windows box, or a Linux or Mac box that someone might have at home.
And, the most important reason why I, like most people, don't need Intel's CC on a regular basis:Sure, there are applications where speed is important, and for those having a platform-specific fast compiler can help. For most things, though, the advances in CPU performance has made the need for an ultra-optimized compiler somewhat useless for most applications that people use.
If your vim is slow, it's probably due to a slow disk or insufficient memory on your long file. If your galeon is slow, it's probably due to insufficient memory or low bandwith. A new compiler probably won't help you.
-- Erich
Slashdot reader since 1997
* 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.
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
This has been published long time ago...M,A LinuxMagasinet in Norway. GCC has about an third of the performance of comercial compilers
Assembling etherkillers for fun an profit
Some interesting "choices" seem to have been made in the analysis here. Let's look at a few.
Firstly, why are we comparing a brand new Intel compiler with a Visual C++ version that is several years old? The full VS.NET is now shipping to MSDN subscribers, and will be publicly available next month. They do mention VS.NET at one point, but it's still horribly biased. They admit that it's 25% faster than 6.0 in unspecified tests, based on a beta version, and we all know how much benchmarks of betas are worth. Try comparing the results with Microsoft's own showcases for their new optimisations in VS.NET, on a real version of VS.NET, and see how much the conclusions depend on your chosen benchmarks. They even have a go at the installation, because (quelle surprise) it takes longer to install VS.NET (a whole development suite) than it takes to install the Intel C++ compiler. Well, duh.
Next up, we seem to be judging the compilers based purely on geometric mean performance generating numerically intensive code. That's a very, very limited metric, and in fact totally irrelevant to many people.
Why geometric mean? That's an odd choice, for a start, and AFAICS is never justified in the article.
Why numerically intensive code? Most real code isn't, so where are the comparisons for the rest? The /. headline is grossly misleading.
Why is speed of generated code the only factor worth considering all of a sudden? A factor of 3/2 in the performance of generated code is relevant to the scientific community, but few others. The quality of the rest of the generated code, the level of support for the C++ standard, the quality of supplied libraries, etc., are all much more important to most real developments.
I don't know much about GCC, so can't really form an opinion on the conclusions there. But the MS-based conclusions of the article are grossly misleading.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Your statement "Speed doesn't matter" implies that you are fucking lame dumb-ass. Nearly all the code I have(radiative transfer stuff) runs much faster with ifc and icc. This means savings of hours per day for me. For you I guess it doesnt matter because the work you do must really suck dick, why don't you try to do work that doesn't suck dick? Probably you are to busy sucking dick to consider that.
Why was this modded down? It is 100% true.
I have testet serveral compilers on a heavy numerical code (simplex algorithm) and it's about 15% faster the gcc.
BUT icc has a long tradtion on generating incorrect code. Years ago on SCO UNIX it compile TeX somewhat inccorect with all optimization on, and it did the same with our code now. But even with the rest it is faster then gcc.
But the same goes for the Compaq Compiler on Alpha, the Sun Compiler on Sparc and the HP Compiler on HPPA. But only one Compiler of them is free and runs everywhere! GCC.
icc is obviously tunes towards SPEC benchmarks and will give best results there. So the effect it gives will allways overestimated.
Perhaps there's a bit of confusion here. In the scientific computing/benchmarking world, "kernel" refers to an inner loop of a compute-intensive program that has been extracted for benchmarking purposes. There's no dishonesty here; they're just using a definition of the word you haven't encountered before.
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.
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/
Some while ago, in fact (August 2000), based on the final commercial version, 11.0b. Take a look at http://openwatcom.org. And the people in charge are the cream of the Watcom community. They're being slow and careful (and remember this is a volunteer project by people with day job, so it's being done in their copious free time), but knowing this crew, they'll do it RIGHT.
~REZ~ #43301. Who'd fake being me anyway?
Well, not everyone is a "open source or nothing" zealot. I care greatly about performance - stability AND speed. So if a closed source compiler can provide a significant improvement in performance, I'm not going to rule it out because it's name isn't GNU.
No, I don't trust in god. He'll have to pay up front, like everybody else.
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.
Much of the optimization he discusses in the article are based on optimizing MMX and SSE scenarios. Does gcc even use these features of the x86 CPU's?
In a benchmark environment, it's very easy to come up with examples that shine with SSE. But, it's much harder for real world applications.
The Intel compiler may very well be more efficient than gcc. But, I highly doubt that it is ~40% faster in real applications.
However, GCC is universal. It runs everthing, targets anything and costs nothing. Nothing in terms of both Beer and Speech.
And sucks on all platforms.
Which is fine, because that's what it's for. Intel's compiler does one thing great - x86 C/C++/Fortran compilation. GCC does many things in mediocrity - Java, C, C++, Fortran, Objective C, on PPC, Alpha, MIPS, PaRISC, x86, blah blah.
GCC is omnipresent and will continue to be so, but people who want the big power will pay the big bucks.
Was Loki compiling with GCC? If so, how much faster would their games have been with this compiler? Hell, Myth II was actually playable on my Cyrix 133 in software mode, if they could get this kind of optimization, it could prove that, in a lot of cases, Linux is great for things that people think it isn't so good for.
--Dan
I pay with my time, conscience ...
Oh really, what kind of charity work do you do? Feed the poor? Teach people to read?
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.
My intuition is that if you design intermediate code as independent as possible from both source code and architecture, you lose the ability to perform some optimizations which are traditionally done on intermediate code generation stage. How did your company overcome this? Can gcc be fixed after all?
Gentlemen, you can't fight in here, this is the War Room!
From the article:
what really makes the Intel compiler so very interesting is the fact that it delivers the same instruction sequences on both Linux and Windows platforms.
Um... duh! GCC for Windows/x86 and GCC for Linux/x86 also produce the same instructions. This shows that the Open Magazine writers have no ability to use Google, as a simple search for Windows GCC turns up MinGW as the second result. (The first result is Cygwin, which by default uses a more heavyweight C library.)
Will I retire or break 10K?
If a commercial compiler did worse than gcc on a platform gcc supported well, it would rapidly cease to exist. So any surviving commercial compilers must have better performance.
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?
> GCC is the only compiler you can count on being present on every Linux (or BSD) system.
Is that a good thing? [IE example]
No. However, is there a compiler released as free software (or heck even only freely redistributable) that outperforms GCC? It's not like IE, where there exist multiple free web browsers (Mozilla and Konqueror).
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.
This is not a compiler issue as much a library issue. Most free apps written in C are written in either ANSI C89 or something that approximates C99 (that is, GNU C). A Mac Cocoa application ported to BSD links against GNUStep; a Windows app links against winelib.
If ... 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?
What about economic arguments? Most hobbyists do not have $500 to spend on an Intel compiler license, and distribution vendors surely can't charge that per copy. Nothing will get bundled with the standard free operating system distributions that is not at least free to redistribute and to use for any purpose.
Will I retire or break 10K?
[Watcom C++ has been released as open-source software] Some while ago, in fact (August 2000), based on the final commercial version, 11.0b. Take a look at http://openwatcom.org
I did, and they still don't have a release up. It's not open source until it has been licensed to at least one third party under an open-source license.
They're being slow and careful
Some would say "too slow." At this rate, x86 will be dead and we'll all be using Hammer and Itanium processors by the time Open Watcom comes out.
Will I retire or break 10K?
If you're a developer, working with the latest hardware, how long does it take to recompile your code?
Probably not very long. Chances are good, if you're smart, everytime you compile you're recompiling one or two objects at a time. Not the entire codebase. Does it matter if it takes 2 seconds rather than one second? Do you ever notice? Would you care?
All this means, is that on one architecture, gcc has room for improvement. Yet gcc works on damn near everything. Intel's does not. Its all give and take.
-Restil
Play with my webcams and lights here
So? $500 is almost the same thing as $0 for any company.
But $500 times 500,000 isn't. This is why GCC and not Intel CC comes with Linux distributions, because GCC is at least free to redistribute. Besides, not all developers work for a large firm.
Will I retire or break 10K?
If not, GCC is going nowhere.
Then you make the following analogy:
You just contradicted yourself. MS-Office is not Open Source and it appears to be doing just fine.
hence it sucks.
So if a closed source compiler can provide a significant improvement in performance, I'm not going to rule it out because it's name isn't GNU.
Few hobbyists and freelance developers have $500 to spend on a compiler. I'll use a proprietary compiler if I have to, but it at least has to be freely redistributable.
Will I retire or break 10K?
The power of gcc is not its raw speed. Raw speed, as we all know, is becoming less and less of an issue these days. What makes gcc valuable is its portability, its extensive warning facilities (try comparing them to Visual C++ to see how awful another compiler's warning facilities can be), and its Standards compliance (less so with C++ but improving). Pure number crunching is not the final word in any kind of software, and has not been for a while.
max
Point out the shortcomings of an open source product, and suddenly you're pretentious.
Be real guys, if the Intel compiler beats gcc, then instead of saying "gcc will live because it is open source", and "the article is a bit pretentious", you need to get off your butt and FIX GCC!
It's free as in beer for uncommercial uses
According to your link: "This compiler includes no support and cannot be used to produce products for resale or commercial use." This means that freelance consultants can't use it. Also, it cannot be used to compile binaries with the GNU General Public License, as the GPL prohibits such a restriction on resale of software licensed thereunder.
I believe this misunderstanding comes from the fact that they called their different benchmarks "kernels" for some reason.
Benchmarks are often called "kernels" because they consist of core inner loops representative of applications. Yes, this is confusing with the term "kernel" used to describe the core of a particular operating system (namely, the Linux® kernel), but the term persists. You can't compile Linux with the gratis version of Intel's compiler because of the restrictions on resale of its output.
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.
icc with -O0 works but -O1 fails terribly on compiling something complicated like "root" (http://root.cern.ch), which works on something like 30 different platforms. icc -O0 is much slower than g++ -O2 for that software. Here even gcc-2.96 works OK.
Well, that is a philosophical question weather the compiler should compensate for a programmers lack of talent or not.
In that case, why even have compilers? Why not require all programmers to be talented enough to write assembly language directly?
Will I retire or break 10K?
On the S/390 we have a monopoly.
Now try to beat *that* !
Toon Moene.
+ 5 insightful? its obvious that not only does
this user does not have a concept about how modern compiliers
work, but most slashdotters don't. the reason
gcc can support many languages and platforms is
not weakness, but is due to something every modern
compilier should be using. they're called intermediate
representation trees. in the end, there are a certain
level of things that all languages do (like
having functions or conditionals). also, there are
a certain level of things that all machines can do (like
move data to memory or add registers). a good compiler
will abstract out the language end into an intermediate
representation that can be used on a wide variety
of platform specific compiliers. one can optimize
on all three levels. the language end, the intermediate
rep, and finally on the machine specific level.
Reading over this I couldn't figure out what they were measuring with the OBLcpu benchmark. They don't talk about what flags they used, I couldn't find information in the article about what the 34 "kernels" were in the graph. Can anyone throw any further light on this?
Also, why are they looking at the geometric mean in the first and second graphs?
Also, they're still getting slightly less performance on linux, which --- since their benchmarks are completely OS-independent number-crunchers --- probably means that their methodology was faulty. Did they disable background tasks, for instance? Did they log in single-user?
I don't trust these numbers at all.
[
My screwdriver hammers nails better then your pipewrench does.....
gcc and the Intel ofering are two different tools for two different jobs, and comparing them is not worth the time or trouble. If I am doing in-house work for an all-Intel shop, I'll use the all-Intel compiler; if I'm writing something I want to run on *nix OR NT webservers, I'll use gcc. What's the problem here?
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?
> As long as intel's compiler is not GPL and does not support as many architectures as gcc does
Shush! You're not supposed to tell Intel that other architectures exist, man! Someone at Intel might be reading this.
Sheesh, evil *and* a jerk. -- Jade
At our work we do fairly numerically intensive :-)),
Finite Element-based engg. simulations. Code
is mix of mostly C and some fortran doing the
bulk of the number crunching.
For our larger runs (~ 1hr on Xeon 1.7Ghz
gcc/g77 -O3 with RH 7.1 is about
20% slower than the Portland group compilers.
Will be interesting to evaluate Intel compilers,
but then article says intel owns PG now.
Compile speed is also a big issue for me, and I'd guess anyone who compiles C++ code.
Cheers,
Apple contibutes to the GCC but they refuse some of the adds like RISC processor (altivec) support but I think with the new version coming out soon 3.0 GCC you will see a trend toward it being better than others. What I am saying is that the GCC now has the support of apple and that is bigger than you think.
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.
Go to the download page and see. If you click on the free compiler, that's the LGpled one. It doesnt expire.
Here is the copyright from the file.
Untar the file and read the lgpltext. Or just run install it shows the same.
Please undestand IBM is putting this compiler on several licneces, One being an evalutation (30 days licence) and one a free for non commerical use (I'm happy with this).
Already, mplayer is playing every movie I could throw at it on my HP 4150 (Neomagic - with no XV) without framedrop on fullscreen, it's taking less than 40% cpu now! (compared to max cpu usage earlier)
-- SilentTristero
ps: to compiler folks, "kernel" means a small bit of highly computational code, usually with no I/O; not an OS kernel. Kernels to them are things like FFT, convolution, and so on.
It does not help PPC/Alpha/MIPS/Sparc users, It`s not in Intel`s interest to do so, However Compaq produce an alpha optimized compiler for linux (ccc) which seems to produce noticeably faster code than gcc, but is incompatible with some source that requires various gcc quirks. There is also SUN Workshop compiler for Sparc, and SGI MipsPRO for mips, I`m not sure about PPC, since i don`t have any PPC based computers. But all of the above mentioned compilers produce faster code than gcc.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
It is true that I never got much past the dragon book. I wrote a transpiler (C++->C) and a few interpreters (none professionaly) and that's about it. But just how my comment contradicts with intermediate language usage, optimizing on all tranformations is a unclear to me, could you please clarify yourself? All I said is that the focus was not (and still is not) speed in gcc's design, it was not (and still is not) a priority. OTOH if you tie your compiler with a single platform (language and cpu), you can't even focus on anything else, there is nothing else (perhaps except for correctness)
Gentlemen, you can't fight in here, this is the War Room!
Also the article is trying to say, that the code optimized up to 40% over GCC using Intel's proprietary instructions gains the same improvements on AMD.
Yeah and I'm going to die to get my ass on dot NET.
"64 kB will be enough for everybody!"
"What is that Internet, indeed?"
"And sucks on all platforms."
My, what short memories we all have. I remember 1994 when I replaced the Sun compiler with gcc and got a nice speedup. The tables have certainly turned now.
"If so, how much faster would their games have been with this compiler?"
Not a whole lot faster. Games and codecs are the last few bits of software where people still write the 1000 or so lines of really performance critical code in assembly. The Myth II software rasterizer was not written in C, so icc can do nothing to it.
The MS compiler is very inexpensive compared with other commercial compilers.
The Sun C compiler is more than $1000, and it sucks. Of course, that is typical of commercial Unix offerings. The companies that live by offering and/or supporting commercial Unix believe in outrageous profit margins.
Now, OSS is the opposite extreme. OSS companies charge money for "free" apps, and pay the programmers nothing. So, while the price is low, the profit margin is "infinite". The OSS offerings also suck, by the way.
The only quality software produced these days is by commercial companies that appeal to mass markets (note that that leaves out high-end commercial Unix as well as Linux).
In other words, GCC sucks.
Not only that, it sucks hard and swallows.
Typical of OSS.
Get a clue, OSS advos!! Good software must be paid for because good devs must be paid.
Someone should save this story, so that whenever an OSS advo states that OSS is as good as commercial software, this story can be brought forth quickly to give the lie to that argument.
"This helps users of PPC, Alpha, and StrongARM exactly how?"
Hmm, let me think about this... Oh, I got it!!
1. GCC is irrelevant on PPC; CodeWarrior OWNZ this space.
2. Alpha is dead.
3. StrongARM - well, OK, I guess GCC can have that, but that does not help linux users very much.
What the upshot should be is that any x86 application which is released in binary and not compiled with the Intel compiler is cheating the user about 20% in performance. In other words, Linux distributions would look much more impressive if they were pre-compiled with this compiler, and the entire Linux community (who doesn't build their own kernel/apps--which is most Linux users) is being short-changed.
The sad fact is that until RPM/APT packagers switch to the new compiler, every task done on Linux will be slower that in Windows. Every "Linux is fine as it is, however that may be" apologist is just making the whole OS look stupid.
What we really need is a centralized gang of package-makers (perhaps at Sourceforge) who paid for the Intel compiler and have some nice machines, which are totally dedicated to compiling major releases of popular GPL apps. Failing that, we can only hope that Red Hat et. al. will use the Intel compiler to make all their future RPMs. They'd be stupid not to.
I know many people who have already switched from old school UNIX to Linux a long time ago. cough Fermi Lab cough Everyone I know in Los Alamos.
I know several people switching from Alphas to PPC/OSX but I sure as hell wouldn't extrapolate that out.
a) intel systems are extremly cheap (compared to architecures optimized for number crunching like RS6K)
Yes. That's exactly why everyone switched to Linux while you weren't looking.
b) compilers available for NT produced MUCH faster code, e.g. Digital fortran. (Yes, I know ... but still a lot of excellent scientific computing software is written in fortran77, e.g. LAPACK)
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.
Yes, performance is important. But stability is even more important. Programs that take weeks and months to run on a thousand node cluster just can't be run on an NT cluster. Do you think all the Linux clustering technology was invented to make the movie Titanic?
Smaller jobs can be done in NT, but it is difficult. You have to get everything running stable (which is possible, but it doesn't come out of the box that way) and running stuff remote stuff over multiple computers requires relearning and there aren't as many tools available.
Any way man, where have you been? Linux has taken over serious scientific computing. The price/performance ratio is just too good for P3 clusters running Linux.
These numbers shouldn't suprise anyone. If you want to learn more about gcc's performance weaknesses and how to improve it, read this report.
It wouldn't surprise me if the bulk of this 40% difference in performance has been achieved by proper data-prefetching.
Cheers,
Waldo
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.
Exactly correct. 14 replies and this is the only one that even understands the terminology used. Someone mod parent up.
The article itself explains that a lot of the optimization is agressive translation of loops into operations on vectors, usng the SIMD (MMX, SSE, SSE2, etc.) opcodes,
I don't think GCC ever uses SIMD instructions unless you explicitly inline them in assembly. I know there are some vector-aware versions of GCC available on PPCLinux that use special data types for vectors and will then use SIMD (AltiVect) instructions on those vector data types.
I'm not familiar with the RTL intermediate representation GCC uses, but I wouldn't be surprised if the intermediate representation in GCC needs to be reworked to be able to clearly express vector operations. Either that, or this relatively generic optimization (would work at least on x86 and PPC) would need to be recoded in each of the applicable platform-specific areas of GCC. It's a relatively simple task for the platform-specific sections to generate loops from vector operations where they don't exist, but very difficult to go the other way. Also, this sort of higher-level optimization could be used to reorder indexing of multi-dimensional arrays acessed in an innefient order (such as sloppy ports of FORTRAN to C. (The major advance in Sun's new compiler is speculated to be this sort of optimization, since it's major speed increase is on a SpecINT benchmark poarted from FORTRAN to C.)
In any case, a lot of work would need to be done on the compiler to get it to agressively convert loops into vector ops. Interpreting the intent of nested loops can be a very complex task, as evidenced by one poster's claim that the new Intel compiler taes about 4 times as long to compile things as the MS compiler.
Also, don't forget that a major rework to get performance gains on (perhapse) only x86 and PPC platforms would probably be met with lots of resisistance from the community.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
Perhaps Intel's C/C++ compiler produces faster code because, uh, Intel knows exactly how their processor works inside and out? I'm sure that their guides to optimization and whatnot are nothing nearly as effective as having the actual engineers around to answer your questions about what's faster under what circumstances.
Who knows, maybe the folks who wrote the compiler had the fscking schematics to the flipping processor?!??!?!?!
On the other hand, perhaps it's some sort of a coincidence that Intel's compiler happens to produce 47% faster code. For a real analysis, they should have tested against Borland's compiler, and WATCOM's compiler. I happen to have been using WATCOM for a number of years now, and I can tell you that, being a staid and steadfast compiler (likening it to Melville's fine description of Starbuck, in the first "Knights and Squires" chapter in Moby Dick), it produces DAMN good code. I cannot compare it to the compiler Intel has authored, because I have never used their compiler.
Astute readers may notice the author's prominent omission of Microsoft's compiler. The reasoning behind said omission centers around the fact that Microsoft is a giant squid, and therefore, their products will sell just fine whether they work correctly, efficiently, both, or neither. Oh well.
In any case, I believe that whether or not Intel's compiler is the best out there, they should release the entire product under some sort of open source license that allows its inclusion in GPL'd code, such as, hmmm... GCC perhaps. Please allow me to explain my reasoning behind this idea. Intel is in the business of making microprocessors. I believe that if they give the world access to the source code (and technical documentation) to one hell of a darn good compiler, and allow others to modify or copy it, will encourage people to make more and faster software for Intel platforms. Imagine if there is an "experimental" new branch of GCC, where the entire system has been completely overhauled on an algorithm basis. Perhaps the compiler can be made to execute more quickly, while still producing better code for whatever platforms... There are endless possibilities in the world of compilers, and I think that a truly good compiler could be produced with the help of engineers from the world's top microprocessor companies, which means not just Intel, but their competitors as well. I say this because I surmise that if Intel took this move, other processor vendors would find themselves in a position where they need to do the same or better for their clients, or some such bullshoot like that. Well, as the saying goes, "Oh well." Because I don't know what the hell I'm talking about, because I'm tired, because I've been working all freakin' day long, and that's tiring, and sh*t.
xxxxxxxxxx O xxxxxxxxxx H xxxxxxxxxx xxxxxxxxxx W xxxxxxxxxx E xxxxxxxxxx L xxxxxxxxxx L xxxxxxxxxx
Oh yeah, and I almost forgot to mention something that I consider pretty interesting. SLASHDOT'S LAMENESS FILTER IS A PEACE OF SHIT. I MEAN, YOU CAN'T EVEN INCLUDE A CODE SNIPPET IN YOUR COMMENT, FOR CRYING OUT LOUD. LIKE SOMEONE'S SIG SAYS, A LAMENESS FILTER ON SLASHDOT IS LIKE A SHIT FILTER ON YOUR ASS. It's anything but staid and steadfast! GET RID OF THAT DAMN THING!!! If you don't get rid of that stupid lameness filter thing, leave it in, but ALLOW THE USER TO POST THEIR COMMENT, but put an option in your preferences and stuff to GLOBALLY HIDE "LAME" comments, just like the OPTION to HIDE ANONYMOUS COWARDS' COMMENTS, d00dz. That way, the user can decide whether to look at that '1337 stuff or n0t. BUT DON'T MAKE THIS SYSTEM SO STUPID!
Now, finally, I'll put in my closing "OH WELL", and be on my way:
xxxxxxxxxx O xxxxxxxxxx H xxxxxxxxxx xxxxxxxxxx W xxxxxxxxxx E xxxxxxxxxx L xxxxxxxxxx L xxxxxxxxxx
From memory, and this may be totally wrong...
"As you can see, we've had our eye on you for some time now Mr. Anderson. It seems that you've been living two lives. In one, you're Thomas A. Anderson, program writer for a respectible software company. You have a social security number, you pay your taxes, and you help your landlady carry out her garbage. The other life is lived in computers, where you go by the hacker alias Neo and are guilty of virtually every computer crime we have a law for. One of these lives has a future, and one of them does not. Now, I'm going to be as forthcoming with you as I can, Mr. Anderson. You're here because we need your help. We know that you've been contacted by a certain individual, a man who calls himself Morpheus. Whatever you think you know about this man is irrelevant; he is considered by some authorities to be the most dangerous man alive. My partners think I'm wasting my time with you, but I think you wish to do the right thing. We're willing to wipe the slate clean; give you a fresh start; all we're asking is your cooperation in bringing a known terrorist to justice."
"That sounds like a really good deal, but I think I got a better one. How 'bout I give you the finger, and you give me my phone call."
"Hmmm... Mr. Anderson. You disappoint me."
"You can't scare me with this gestapo crap. I know my rights. I want my phone call."
"Tell me, Mr. Anderson, what good is a phone call, if you're unable to speak?"
Now, seriously, this is the end of my comment. Finis.
why was this modded flamebait??
...especially when some analyses take as much as 3 days of computation time...
:)
Oh. You work on small problems then, right?
:)
C//
Dude, that was quite an informative post *bravo*
- Penguin Kicka
There seems to be some confusion in a lot of the posts I see above. When someone says that a particular compiler is faster, the mean the binary executables porduced by the compiler (ie the program you have compiled) runs faster. -- They DO NOT mean that it nesecarily takes less time to compile the code!
/.er's
I would expect better from
''Anyway -- the next time I am writing code to take the square of a bunch of floating points, add them and then take the square root, I will consider paying $500 ''
The point that I am making here is that this does not even prove that intel compiler is overall faster. It only proves that intel is better at that one -- very specific task.
Besides, if floating point speed is important to you, you probably aren't going to run it on x86 anyway, an if you do use x86 for a lot of floating point, you'd be wise to use anthlon.
don't you think it's all a bit of mental masturbation? there are way more things acting in the background that can change figures, and this test really doesn't prove much.
By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software
Furthermore, the notion that open source software caught on because it was faster or higher quality is ridiculous to anybody who is familiar with its history. GNU C was accepted and widely used long before it became the high quality compiler it is today. Linux caught on long before its networking and stability were competitive. But the ability to get the source code and fix it more than makes up for any deficiencies and limitations to many users, and that's why open source software has been as successful as it has.
As for "redefinition", I don't see why we should let you, the Microsoft PR department, or a bunch of clueless journalists and VCs define what open source is all about. If open source isn't for you, just don't use it and go away.
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).
An earlier poster claimed that this was originally the KAI C/C++ compiler, and that Intel had bought them and killed off the versions for non-Intel platforms.
I would be quite surprised if they then turned around and opened the source, which might allow those cross-platform versions to be resurrected.
.
I think we've pushed this "anyone can grow up to be president" thing too far.
One feasible way would be with a quite intelligent post-processor. This would need to be architecture specific, since what it would be initializing would vary with the target.
.
I think we've pushed this "anyone can grow up to be president" thing too far.
Check the license to make sure that it's unencumbed enough for your purposes. I have seen warnings that it is incompatible with the GPL, and that it could be interpreted to prohibit the recovery of the cost of distribution.
OTOH, it should be fine for simple experimentation.
.
I think we've pushed this "anyone can grow up to be president" thing too far.
You mean if the enemy captures one of your systems, it gets its hands on a full-debug-info, easily understandable, non-optimized binary???
Why not include the entire source, with all the comments, the HW schematics, building instructions and maybe some examples for countermeasures? As a courtesy, you might even translate all the comments in the code into Russian, Chinese, Hebrew, Arabic, Hindi, English, German, Swahili, Singalese and whatnot.
I am extremely impressed with it and right away I was able to make my code much faster, faster even than getting a better compiler would have been able to do.
The 5.0 release version is windows only, but the VTune 6.0 Beta will profile code running on both Windows and Linux. You still need a Windows host to run the UI on, but you can profile on a Linux box across the network. I think they supply kernel patches to put some performance monitoring tools in the kernel.
If just a few key free software developer had this tool, it would make a tremendous difference. For the most part, the suggestions it gives you are applicable to any processor, not just x86. Yes, the code coach will tell you to put in SIMD instructions but you don't need to do that, you can pay attention to when it tells you there is a hidden temporary in C++, for example.
If the profiling were applied to libraries like the XLib, Gnome libraries, KDE libraries, glibc and so on it would benefit all platforms.
Also you can profile cross-platform code on Windows, like AbiWord, the Gimp or Mozilla and help out code on Linux.
I'm using an eval copy now but I'm planning on purchasing a licensed copy soon. I think it will make a huge difference to the results I can produce for my consulting business, and I plan to use the tool to contribute to free software products as well.
-- Could you use my software consulting serv
The testing didn't involve compiling kernels at all.
Compiling kernels is hardly a worthwhile benchmark for all but a selet few.
I'd loathe to disqualify a compiler for that reason.
I'd like to see its performance on various 3d and crypto apps. Anyone?
The IBM AT (286) came out in 1984, the XT (8088) in 81, and the 8086/88 itself back when disco was still very much the rage and I was in grade school. I cannot think of any reason we should give a rat's ass whether any compiler can create code for these chips anymore. They don't have enough power to run anything more than a text based dumb terminal anyway. My Ti-92 calculator has a more powerful CPU in it (68000) than an XT. We might as well worry about whether GCC can create code for a PDP-11 while we're at it.
Making an open source version of dos would have been a great idea 10 or 15 years ago, but today it just doesn't matter. Is anyone's aversion to MS stuff so strong that they would rather reinvent a version of DOS instead of just using 6.22? There is DRDOS/OpenDOS/whatever-they're-calling-it-now if you don't like MS-DOS.
The only area where 8 and 16 bit chips are of any importance is in embedded systems with low performance requirements. The good news is that for the 68HC11, the most popular microcontroller around, there is a GCC cross compiler available. I've downloaded it and played with it myself, it works.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Probably some other redundant replies that I missed while reading at threshold 2
Mind you, there were a number of actual interesting posts, such as the KCC (Kai compiler) post. Not to mention the various "I worked in this field, and we found..." etc. But the rest can be summed-up above.
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?
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.
OK, this may be incredibly off topic but I have often wondered about this. What does MS use to compile Windows? Do they use their Visual C++ compiler? Would they use the Intel compiler? Does anyone know?
Uhh, we were talking about a slim portion of life, that being computers. I should be flattered that you care to ask what I do outside of computers. I won't detail my life, but yes to all of your questions, plus others. I suppose that is what a liberal arts education will get you as opposed to some math/science/engineering degree. You people are making me so sad.
Why is no one commenting on the quite obvious
fact from the data that Linux is slower than
Windows XP on the same hardware using the same
compiler?
But when the HELL is Intel going to release their signal processing library for Linux?
I know for a fact (and I have the email correspondence with Intel engineers to prove it) that it's been ready for at least two years!! I'm still f*cking waiting, guys.
I have major projects in the pipeline that could be Linux/x86 projects if this library was available NOW. C'mon Intel, get off your g*dd*amn ass and RELEASE the Linux version of this damn thing!!! These projects could just as easily be PPC based. At least I can get optimized signal processing libraries for PPC processors.
In the course of every project, it will become necessary to shoot the scientists and begin production.
How about releasing an Intel-compiled Linux distro, and charging money for it? Intel would want a piece of the action, but just build that into the price. I'm sure people would pay for it. Even if it isn't that much faster, as long as people think it might be, they'll be lining up for it. Just like Mandrake being "Pentium optimized," not like that dumb, old, slow Redhat! ;-)
You should say "open source"
RMS has just dispatched a goon squad to your location.
Is it really news that one gets better performance if one optimizes for an available, extra instruction set (SSE - Streaming SIMD Extensions). Without knowing much about C/C++ (the JAVA VM rulez - hahaha), i gather from CPU reviews that if especially "multimedia" related apps take advantage of SSE they gain significant performance. If one looks at the performance chart it is only really "egypt" and "egyptd" that have OVERWHELMING performance increases. I'll eat my hat if they aren't some kind of "multimedia" app.
Also the overall performance is a GEOMETRIC mean. Why?? Probably because in a geometric mean the kind of large aberrations seen for egypt and egyptd weigh more heavily on the overall result.
Many of the comments in this discussion states that it's hard to write a portable and yet well-performing compiler, as an argument defending GCC.
There simply no substance to that argument. Any optimization you can do in a target-specific compiler can be done in a portable compiler, simply by only performing it when it's known to be valid.
It's not "harder" to optimize in a portable compiler, but there's a lot more targets to cover, and thus much more work to be done. And I think that's probably the actual problem that GCC has, compared to Intel.
BTW: I'm no GCC-fan, but I like it for it's (relative, compared to Borland, MSVC and Sun compilers) C++ standards confomance, and for the best error-messages (call/inclusion tracking for templates/headers).
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
Right now, whatever IE does already becomes a de facto standard, because of its ubiquity and dominance in the marketplace. That's my point. Its own "standards" are now rated by many as more important than the W3C's, which is not good for other browsers or consumers in general. This is exactly my point about GCC, for exactly the same reasons.
The W3C has been left with little choice but to accept a number of Microsoft's proposals, or risk becoming irrelevant. But the C++ standards groups aren't under the same pressure. They will quietly ignore GCC's eccentricities if they feel it appropriate, and GCC will be left as a compiler for "not quite C++" that no-one outside of the Linux/open source community gives a wotsit about. The level of porting to Linux that goes on at present will drop to almost nothing, and the popularity of Linux will remain forever at the enthusiastic hobbyist level. Personally, I think that would be a shame, and I'm sure many here would agree.
The question then becomes: what can we do about it? As I said before, if you accept the "GCC is the Linux C++ compiler" rule, based on religious or philosophical reasoning rather than technical merit, you bring it upon yourselves. Competition and alternatives are healthy in the open source/free software environment, just as they are anywhere else. In the meantime, it's in everyone's interests to move away from this perception that if you're writing C++ for Linux, you're actually writing for GCC. Move toward the standard as the baseline for your distribution; that's what it's there for. Then you can pick up alternative compilers if and when they come along.
GCC is not fully compliant with the C++ standard. As yet, no compiler is, though the leading edge is expected to be as near as makes no difference within weeks (including the elusive export support). As for extensions, why not go with the standard instead, since C99 now provides for fixed-size integers?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I don't know of any truly free alternatives just now, but that's really not the point. If you tie yourself into a specific compiler, even one as well-regarded as GCC, then you have "vendor lock-in" as surely as if you install MS everywhere, and all the same problems. In particular, if and when a better alternative comes along, you won't be able to take advantage of it. Aim for the standards instead, and you'll be in with a much better chance.
I've covered the standard vs. library issue under another reply to my last post. I invite you to follow that thread to see why your reasoning here doesn't affect my argument for standards compliance.
Finally, the economic issue is pretty irrelevant to companies. A compiler costs them nothing in real terms, and they are the ones writing the "killer apps" Linux so desperately needs if it's going to take off as a serious OS platform for the non-hobbyist world. If there's a good Linux C++ compiler available to them that lets them port their code, they will buy it if necessary. The question is whether GCC is, and will remain, up to the job. My reservation is that the original post implied it would continue to be used, whatever the answer to that question may be.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
One may dismiss the author's prediction of GCC's imminent death as mere hyperbole, but let us not be rash. With Watcom releasing the source of Watcom C++ 11.0 under an open-source licence, GCC faces some huge competition. Watcom is regarded as one of the better code generators. Even the core developers of GCC admit in the mailing-list that a lot of the code is crufty and in need of an overhaul. It just goes to show that just because a project starts out as open-source, it's not necessarily the best alternative.
Well, I only work with the GUI stuff and other tools, which is written in C/C++. It doesn't have any sensitive info anyway. The code running on the realtime computer does not have debug info.
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)
Even I beats GCC.
_________________
EBAY SAFETY TIPZ!
As we don't have software patents. Our patent system is horrible (alternatively one could say it is nonexistant for all practical purposes) but at least it doesn't allow patented algorithms (that would be equivalent to patenting an idea under our system.)
Gentlemen, you can't fight in here, this is the War Room!
Well, although the Linux kernel is not a GNU project, most of the userland programmes that make up the OS are. Without GNU, Linux would just be useless. (This is also why it should really be called GNU/Linux.)
Claus
Nobody seems to have noticed the underlying message of this article: MS Visual C++ was already producing faster code than GCC. The Intel compiler improves on both of them.
And to be quite honest, this isn't really surprising. Particularly on intel platforms, a lot of optimisation requires tricks that my guess is GCC just doesn't perform. It's a multiplatform compiler, and a multiplatform compiler cannot perform optimisations that only work on one platform! At a guess, it does not move floating point operations up the instruction stream in order to gain advantage from the parallelism provided by the intel's separate FPU (i.e. FPU instructions generally take longer than 1 cycle to execute, but the compiler may well expect them to be ready after 1 cycle, forcing the main CPU to stop and wait for the FPU to finish its operation). I understand that it keeps a reference to the ELF run time linking function dispatch table in a register at all times. On architectures with more than 6 general purpose registers this makes sense - on IA32 it does not! MSVC++ will not even consider doing this (it doesn't build ELF output), and I guess the Intel compiler will 'forget' this reference when it is not needed for a while. I'm sure there are more improvements that are possible...
The other thing to note: "CPU performance for Intel on Linux and MS Visual Studio.NET on Windows in a dead heat." -- That is, it only lets us catch up. And the Intel compiler on Windows gets better performance than the Intel compiler on Linux. Something for Linux to fix, that is... it's supposed to get better computationally intensive performance.
The article itself explains that a lot of the optimization is agressive translation of loops into operations on vectors, usng the SIMD (MMX, SSE, SSE2, etc.) opcodes
This sounds like scientific/engineering computations, and maybe 3D graphics computations in games. Anyone know if the Intel compiler does speed up graphics where you notice?
Yes I'd like a speed-up in Spice simulations of electronic circuits, but I don't spend as much time on that in a year as I spend just waiting for Windoze reboots... AFAIK, the only code in OS's or Office suites that could be vectorized to advantage is the graphics processing, and in most things I use at work the graphics processing is already fast enough to be imperceptible.
it may take 10 minutes to compile eggdrop src on my old 400mhz... but i honestly don't care i have 2 x86 machines and a sparc machine... i like standardisation (sp?) so GCC is what i'm going with ( damn the man... save the open source :P )
-Hackers are not my worst enemy.. but my best friends.. damn they're a mine of security info-
Don't forget that the GPL only requires that you distribute source with the binaries. It does not require that you distribute the compiler you used
What about Linux distribution publishers? Are they supposed to compile their RPMs with ICC but distribute GCC?
Will I retire or break 10K?
Is it possible to compile the Linux kernel on the Intel compiler?
Or, pray-be-not, is it too gcc specific?
Isnt it time the FS community realised that at the end of the day, its the results that matter not the emotional attachments that get you there.
GCC's biggest strength is is biggest weakness, its a jack of all architectures and as a result generates slow\poor\messy code for everything.
its time to start welcoming more powerful compilers, even if they may be closed source or platform dependant.
Sure you would hope Intel can produce a decent compiler for its own line of CPU's, but the lowest common denominator mentality is whats stuffing Linux.
I'm currently trying to get this compiler working on my system... the documentation is a bit lacking. I, for one, am extremely happy to have more choice in compilers for linux. Why is everyone else so upset about this? I'd much rather just re-compile my number-crunching software than buy new CPUs. As for it replacing GCC... no way. The intel compiler will never be distributed with linux because it's so much more expensive... not to mention it's extreme limitations in platform compatibility... hell, it won't even work on debian without major hacking.... that means future open-source software will compile under GCC or both, but not just intel. Some commercial software might require it for compilation, but who cares if you never even get to see the source? If it means faster number crunching, faster lame, and skip-free mplayer for me, I just can't see a downside. This is great!
It's hardly news that GCC is beat on benchmarks by this compiler or that. When has this not been the case?
When you see claims like that being made, try to think of factors that were not included in the analysis:
- architecture support. Does the benchmarked compiler have back ends for every architecture that GCC supports?
- diagnostics: does it diagnose code as well?
- conformance: how well does it comply to ISO C
and C++? Does it have a standard library, or at least integrate with one?
- correctness: can it be trusted to generate
correct code, even when aggressively optimizing?
Are some of the benchmark results depending on a fluke, such as unwarranted assumptions about object aliasing which just happen to be true?
- extensions: does it provide a consistent set of extensions across all the architectures it supports?
A project like the Linux kernel supports many architectures, and also needs certain extension from the compiler. Some of the extensions are darn useful, like the GCC inline assembly syntax which can allocate registers for you, and tightly weave your machine sequence into surrounding code. You wouldn't want the kernel to require a completely different compiler for each architecture.
- do any of the optimizations affect binary compatibility among modules (calling sequences, object layouts).
- how many language front ends does the competing compiler have? Is it C or C++ only, or are other languages supported?
- Is the source code open? Can anyone who is willing to invest the time and energly retarget the compiler?
- How well does its generated code run on older chip family members, like the Pentium, 486 or 386? That could be important for some embedded work.
- Can it sacrifice speed and optimize for size?
There is no way that another compiler can replace GCC all that easily. Think about what it takes to compile every component of a GNU/Linux system: the kernel, libraries, and tons of programs. Even with support for all of GCC's extensions, there is the matter of confidence.
I'm using icc now, and I must say its a great compiler. It performs really well, even for non-fpu intensive tasks. For example, in a test case I tried to find out the speed of page coalescing algorithm. Compiled with icc, the benchmark ran 30% faster under icc than under gcc. That's a significant difference. In addition to performance, the compiler has a lot of other great features. Its error messages still edge out gcc's in my opinion (which is the real reason I like it, not really the performance) and its got good C++ compatibility. It has gcc-style inline asm support, and is substantially compatible with gcc. There are a couple of problems with it, however. Not all the command-line options supported by gcc are supported in icc. Normally, this isn't an issue, but in some cases the additional control might be nice. I'm a little worried about its quality, however. While the compiler itself hasn't bugged out on me yet, the IPO support (intraprocedural optimization, basically optimization between multiple object files) sometimes fails in weird cases (in my toy OS kernel with C++ objects with destructors created on the stack). Also, the lack of documentation about its exception handling runtime (which has to be rewritten in order to use C++ exceptions in a kernel) is annoying.
A deep unwavering belief is a sure sign you're missing something...
(btw s/stip/strip/ of course)
here is another benchmark icc version 5.0.1 with gcc 3.0.1. Note the difference is a lot smaller, except for the whetstone, which show interesting results (read the accompanying text).
Now, openmag people, see this site and how it documents the compiler options used, and how it makes the benchmark _source_ available for download. Read it and learn.
These benchmarks are done by Scott Roberts, who recently posted this to a gcc mailing list.
--- Hindsight is 20/20, but walking backwards is not the answer.
Sheesh, the bean counters won't let us buy WinZip let alone some fancy schmancy compiler...
GCC still only generates mostly 8086 instructions from 20 years ago and only a small number of 386 instructions. Most of the optimization in the last 10 years was reordering for pipelined architectures, which doesn't matter anymore now that the hardware does most of the reordering. At least the Pentium III supports 100 instructions not generated by GCC.
Having a certain tool/software on almost every box is convenient, but it's the standards that get you there.
ANSI C code compiles on almost every C compiler. If the compiler fails on it then it should be avoided. Granted the C++ world gets a little more complicated, but again, write to the standards.
The IE is everywhere so we'll write to it argument is even worse. IE is a *BROWSER*. It's designed to view/render certain file types. So, the idea should be to write to the file type. Then, any browser that properly implements the types will display the file as well.
It's the VBScript, IE-only, Flash-plugin writing people of the world who are destroying the original idea of HTML and the Web.
Whew, I feel better now.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
I think you'll find that RMS does not follow the gcc list himself (too busy, I suspect), so feel free to mail suggestions! (PS I follow the gcc list).
MS added completion ports to NT because NT's scheduler sucked so badly they needed to explicitly tell it to wait for data. Probably not the best example ;-)
A problem with statistics -- not enough samples.
Although this information tells a true story, it falls short of the truth. If I am compiling binaries for distribution to large audiences I would try to limit the number of versions of this software I'd have to support. One way to do this is to produce a new architecture-based binary only when necessary.
According to the article, the compiler optimizes the code for Intel's SIMD instructions. It supposedly optimizes well for the Intel and AMD chips that support these instructions. Code that I write would hopefully work on other systems as well, and I would choose compatibility over performance any day. I might make an exception for speed-hungry tasks. Most tasks aren't.
For me to find any value in Intels performance measurements I would have to see this code work on Pentium Non-MMX processors and AMD K6's up to whatever is current. If the compiler relies on SIMD instructions to make it faster then it naturally would be slower on non-SIMD systems.
If I understand correctly the GNU compiler doesn't automatically take advantage of these instructions. The output would be more generic.
My guess is that the resulting binaries do not have the same features. The Intel binaries work with only a few processors(SIMD compatible). The GNU compiler takes advantage of a mainly more traditional set of instructions. It would be possible to make a 386-and-up that is nearly as fast as a processor optimized version.
These are apples and oranges. I can't distribute the Intel binaries to most users. I'd have to distribute a more compatible binary as well.
What would the performance of that one look like? 5-10% faster?
rhadc
P4 is very unlike the PPro architecture (the PII and PIII are very similar to the PPro with a bit better 16 bit app handling).
So I doubt the optimisations will work as well for the P4. Might even be worse.
>I`m not sure about PPC, since i don`t have any PPC based computers.
xlc/xlC runs on AIX/PowerPC.
I saw intel's compiler downloadable off their web site over a year ago, and they were making claims that early about it being able to compile code for intel processors that ran faster than code compiled by gcc. I say: whoop tee doo! If someone wants to recompile every program on is computer with intel's compiler so he can get a performance boost then good for them! And good for intel. More people may buy intel chips knowing that they can get better performance with a recompile. Will gcc die? no way! Would it hurt INtel to integrate their optimizations into gcc? No. Would the maintainers of gcc want Intel's processor specific optimizations integrated into gcc? Maybe, maybe not I am not an expert, though it might be ugly. Let intel create their faster compiler to eek more performance from the intel processor. If i need the extra use I'll use it if my programs will recompile with it.
GCC is the only compiler that haven't disagreed with me about how control structures of typedefinitions or "name your favourite compiler problem" should work.
With GCC you can compile just about anything that resebles C/C++ to on almost any platform TO almost any platform.
I mean, just as I would love a web browser that is 100% CSS and XHTML compliant, I also like to have a compiler that does what it's told to, even if the coder was creative.
Not tested that Intel thing.. but when writing a compiler from scratch isn't that easy to get it all right on first try.
Software should be free as in speech, but if we also get some free beer, all the better.
I've played a bit with GCC in my time, and what this benchmark demonstrates is the ineptitude of the reviewers to take into account several issues that aren't covered in their article.
1. They used as the marker for GCC performance a gcc 2.95.3 version compiling a 2.4 series kernel.
Obviously, this is like telling the cook that he has to prepare a twelve course meal with only a Bunsen burner. Linux 2.4 kernels are notorious for being extremely slow on anything below the (bastardized depending on your view) version 2.96 of gcc. I'm not at all surprised at their results, considering that the Intel compiler is optimized for the setup being used to run these tests. Personally, I'm surprised that GCC 2.95 even compiled the kernel...
2. They did not indicate if GCC was recompiled with any of the x86 optimizations.
The default GCC package usually comes compiled with no optimizations whatsoever. I'm not exactly familiar with SuSE 7.3, so I can't say for sure what optimizations they put into their compiler package. However, most distros still include the gcc compiler to emphasize compatability over speed. Let's see that Intel compiler work on SPARC or a PowerPC. I betcha it won't.
IMHO, this benchmark is like comparing a Ferrari to a bicycle and trying to determine which one can make the quarter-mile first. The answer is quite obvious...
But what I find ever more interesting is that an open source magazine is reviewing a closed source product, and making the glaring oversights that I've just begun to cover above...
test.
And my company cares about having a compiler that we can port to new platforms without buying expensive licenses to do so. There are many reasons to care about open source without being a zealot.
With this flag GCC code's floating-point performance gains by as much as 80~100% (by replacing divisions with multiplications, for example). Of course it breaks strict IEEE754 standards, but not many real programs. Probably it isn't used in the benchmark --- if it is used, it MUST be mentione
By contrast, the Intel compiler has a -mp switch that is similar to --NO-fast-math in gcc. This is not specified by default, so these standard-breaking optimizations are on by default.
Well, the gcc docs should explain --fast-math more thoroughly and put it in some easy-to-find place, although it should still not be on by default.
As for MSVC, I donno.
If you think about it, it's not that suprising that a compiler/assembler written by the chip manufacturer generates faster binaries. Having access to the chip specs and the engineers that designed the chip virtually ensures that this will indeed be the case.
Before people start to predict gcc's demise, I would like to ask the reviewers if they tried benchmarking the performance of the intel compiler's binaries on a Transmeta or AMD chip. I think that might lead to us seeing the Intel compiler in a slightly different light.