Slashdot Mirror
Intel C/C++ Compiler Beats GCC
jfonseca writes: "An article from Open Magazine claims the new Intel C/C++ compiler's geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC. They also predict the end to the ubiquitous GNU compiler due to low performance. Many other compiler/platform combinations also compared. A bit pretentious, yet an interesting read."
GCC is the only compiler you can count on being present on every Linux (or BSD) system. Thus most code released is going to continue being compilable by gcc, and it's going to remain the baseline for source distribution.
/Janne
Trust the Computer. The Computer is your friend.
The article itself states the compiler itself is not open source. So how's this going to cause it to be chosen over GCC when it (probably) won't be distributed to the same degree as GCC?
Q: Why do people use MS-Office?
A: Because its there.
Q: Why will people use GCC?
A: Because its there!
Same concept, really. Most Free Software will continue to be built with GCC until Intel releases this compiler under the GPL, performance not withstanding.
"Insanity is doing the same thing over again expecting a different result."
As long as intel's compiler is not GPL and does not support as many architectures as gcc does, I don't think gcc will vanish any time soon.
Plus everytime benchmarks showed that a closed source product was faster/better than the free software counterpart, the open source community worked hard to improve its champion.
gcc is dead, long live gcc
!
^_^
I guess I'm not that surprised that the corporation that designed the CPU would produce a more optimized compiler.
The interesting thing is that the Intel compiler's code ran at 'virtually identical' speeds on an Athlon.
While software firms and organizations developing mission-critical programs may decide to switch to icc, the fact that gcc is free will help it to remain popular among hackers and other budget-constrained users. Moreover, most of the source code programs one downloads for Linux are designed to be compiled with gcc.
Sig (appended to the end of comments you post, 120 chars)
I was always under the impression that a vendor supplied compiler would almost always out-perform a generic cross-compiler, which is available on much more other platforms. GCC is all fine and dandy, but it's it shines in other aspects than pure optimization and fast code (they may be faster on some architectures than the vendor supplied compiler, but that's not my point). The produced code x86 was always sub-optimal. Because of that, projects like pgcc exist(ed).
-- The plural of 'anecdote' is not 'data'.
It seems that they've been testing performace of
some code blocks they've called 'kernels' for some
obscure reasons.
That makes the test useless - if they've compiled
some linux kernel by both, say GCC and MSVC and their own compiler - that's where the real results
are to be derived from. Needless to say that they
couldn't do that.
And their (surely optimized) "kernel"s run faster compiled by their own compiler. Bah! No surprise.
Conclusion : this is unfair comparison, and the results of the test say nothing.
./lxnt
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
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.
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.
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
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 am sure that Intel's compiler is better than gcc at crunching numbers, in fact, it's probably signficantly better. But my guess is that for most folks gcc is "good enough" at a much lower price.
The commercial compiler companies have been trying to rid the world of gcc for quite some time now, and yet, come the close of the day it's the commercial companies that are getting closed down or bought out, and it's gcc that continues to gain users.
Now, if Intel were to allow you to use their compiler for free (even without source code) for commercial purposes, then perhaps I would start to worry about the future of gcc. But that isn't going to happen, and gcc will continue to chug right along.
This sound somewhat like a bit biased comparison - even though I think that Intel's compiler is indeed better in x86 optimization - most of gcc developers would confirm this...
...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 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.
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
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?
Compaq's (formerly DEC) C compiler for alpha's have always been excellent and far ahead of GCC. The problem is that a lot of compilers (we haven't tested the intel yet) won't compile all the code that you may want or need. In the *NIX env. GCC seems to provide the highest level of compatibility over a wide variety of platforms n(SUN, AXI, BSD, Linux, Tru-64, Windows, et al).
Until there is only one chip left to support (Intel is fast working on it, with the support of turncoats Compaq, HP and others) GCC will be a viable option. GCC is a great "cross platform" compiler that works for much of the current written open soruce code base. You can get that compiler to work for many different OSs and archs.
In the end, remember apache wasn't the fastest web server, but it was the "most correct" and it was free! It really doesn't matter how well your C compiler works if it won't compile your code or run on your system.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
I'm surprised that nobody has commented on what might be the most interesting result on these tests - that the same code produced by the same compiler runs 10% faster on Windows XP than on Linux (2.4.10, according to SuSE's description of 7.3). Sure, the "kernels"[1] used by the benchmark might not be as representative of real life as we'd like, but this should still be cause for concern. Kernel developers have flamed each other endlessly over smaller differences on less comprehensive benchmarks between the Arcangeli and van Riel VM systems. Do we have to go through a Mindcraft-like period of denial before anyone starts taking such a result seriously?
[1]The objections about the "kernels" used in the benchmarks not being the same as the "kernel" with which we're all familiar only demonstrate the ignorance of people who don't know that the scientific programming and benchmark communities have been using the term just as long as the OS community. Their usage may be different, but it's just as valid.
Slashdot - News for Herds. Stuff that Splatters.
You might find Alpha and StrongARM on the Intel list...
If you're not part of the solution, you're part of the precipitate.
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
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));
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.
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
"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
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.
...except that they didn't, in this case, and the article - which you obviously didn't read - even suggests some reasons why that might not always be the case.
Slashdot - News for Herds. Stuff that Splatters.
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.
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 ?
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
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.
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.
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.
A more likely reason for not turning on optimization would be not wanting to wait for the optimizer to run. Another good reason is that it is often harder to debug optimized code.
At one time though the most frequent reason to avoid the optimizer was that many were buggy as heck and would introduce all kinds of bugs based on an imperfect understanding of how the program work. This was particularly the so with Fortran compilers where the derranged semantics of the language often bit the optimizer hard. It would also bite the programers on many occasions who would make use of common blocks that was outlawed under the Geneva convention.
Intel has sold its compiler expertise for years. There is Intel code in most of the commercial compilers in use. I don't see why Intel should give code away to Microsoft to sell in Visual Studio.
Equally, there is little point in having an internal optimization team that can't beat an external team with no advance knowledge of the processor architecture.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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...
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.
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?
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.
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
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.
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
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.
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?
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
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.
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?
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
Then you make the following analogy:
You just contradicted yourself. MS-Office is not Open Source and it appears to be doing just fine.
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.
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.
[
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?
Compile speed is also a big issue for me, and I'd guess anyone who compiles C++ code.
Cheers,
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.
-- 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.
What if I compile a GPL'ed app and don't distribute the binary? Certainly the GPL doesn't restrict me in that case, because the GPL only restricts redistribution.
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.
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.
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.
...especially when some analyses take as much as 3 days of computation time...
:)
Oh. You work on small problems then, right?
:)
C//
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.
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.
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 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.
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.
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.
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)
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
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.
As far as I'm aware, Linux Kernel isn't portable outside of GCC.
It uses too many gcc-spesific extentions.
--
Two witches watched two watches.
Which witch watched which watch?
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...
The reason you can't compile Linux with icc isn't licensing, but actual compatibility. icc doesn't support many non-standard gcc extensions that the Linux kernel uses.
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.
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.
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.
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.