Slashdot Mirror
Comparing Linux C and C++ Compilers
ChaoticCoyote writes "I've posted a comparison of recent GCC versions (3.3, 3.4, and the coming 4.0) with Intel C++ 8.1, including several benchmarks and "state-of-the-product" reviews. The new article replaces an older piece I published in late 2002. This
new comparison marks what I hope will be an ongoing series that tracks the quality of Linux compilers."
well, GCC has one thing going for it - it's open source - and that's why I'm sticking with it. XD
FP?
Moll.
What you hear in the ear, preach from the rooftop Matthew 10.27b
Interesting. Something I don't understand, though, is why the article talks about both gcc version 4.0 and "the upcoming-3.5"; will there be a 3.5 version before 4.0, or is that simply a typo?
quidquid latine dictum sit altum videtur.
by default, gcc (with a .c or lang-spec set to c)
let's you forget the #include, and the missing return value
That doesn't seem right; I know that Gentoo is able to adapt itself to your hardware, but this is a bit much for me to swallow.
my sig's at the bottom of the page.
Does the Intel compiler support any other chip architectures other than Intel architectures?
Hmm?
My other car is a slashdot UID.
At work we (well, I admin and made the call) reverted from the 8 series of intel to the 7 series because of some issues with fortran 90 compilation, but I hadn't noticed the 8.1 release. I'll have to give it a shot...
Interesting that ICC seems to create consistently quite large binaries in comparison to GCC.
Even if the Intel compiler is faster, it's best not to get in the habit of becoming locked into any proprietary platform. How likely is it that features on which one could come to depend will be kept available on free platforms, much less future processors not made or controlled by Intel?
CEE5210S The signal SIGHUP was received.
32 bit intel binaries will run on an Opteron and will probably give some gain as seen here at Aces.
Aces article
I hear people complain about gnu C++ alot because its not as good as commercial compilers.
However from what I see is the performance of the compiled code is the same with the exception that the resulting binaries are alot bigger.
Maybe gcc is good on x86 but sucks on other architectures? I know the Sun and SGI geeks have complained for years that gcc does not run well on their platforms compared to expensive alternatives by their vendors.
Has anyone run ICC and VC++.net on Windows? How does it compare to Borland and MS compilers under Windows2k?
http://saveie6.com/
I think the author had better mark the tests whose inner loops have been vectorized, since while some algorithms are easily vectorizable, some are not, so the performance of both are interesting. After all, we care most about the features (such as automatic vectorization) of the compiler, while benchmarks only very roughly reflect the existence of such features, the applicability of them, and their effects.
For the people here not getting his point:
AMD64 kernel
Intel P4 processor
Sure you can compile for AMD64 for if you like, but if your processor is an ordinary Intel Pentium 4 you probably won't be getting many benefits from doing so.
As some of the more insightful people have pointed out, there is a difference between mcpu=x86-64 which will make optimaztions assuming amd64 architecture (which is just silly, as you'll get no gains from it on a Pentium chip), and march=x86-64 which breaks binary compatability and just won't run on a Pentium.
So, either he's stupid and optimized for a CPU he doesn't have, or he is horribly incorrect about that configuration he specified, because it wouldn't be running. Take you pick.
I hope that clarifies things.
Jedidiah.
Craft Beer Programming T-shirts
One of the main reasons I was looking forward to the new GCC versions was faster compile times for C++. Yet it seems that for povray (the only c++ source in the benchmark), the compile times consistently get worse with newer versions of gcc. Does no-one care about people who actually compile kde?
Actually there are. LCC and TinyC come to mind. They're not used much in production [well LCC was reborn as LCC-Win32 for a while] but really GCC is the better choice.
:-)
The problem with the "good old days" was that as my friend Dave Dunfield said once "C compilers are a dime a dozen".
Just because you had a dozen C compilers for your 8086 doesn't mean you were better off. In fact most compilers for the 86 were crap [e.g. smallC, byteC, Zortech, paradise, etc...]. In fact the only half-way decent 86 compilers I recall are Turbo C [v3.01 was ok] and Micro-C [by Dave Dunfield so maybe I'm a bit biased there...].
Note I'm not saying more compilers is bad. The problem is like any field "new" doesn't imply better. You have to tackle problems and answer them.
For instance, GCC is rather large and can be slow/memhog on some files [C++ in particular]. A viable competitor for Linux would be one which optimizes decently while not being such a hog. It could pitch in when you can't build a file [say from VisualBoyAdvance which requires ~1GB of ram to build with GCC 3.4.2]...
For the most part though, contributing to GCC makes more sense than writing your own compiler. First off, GCC is a "standard". So you're likely to get a huge audience that way. Second, GCC is already well established. It's a very good suite of tools and frankly hard to compete with. Third, you'll save a lot of time.
For all intents and purposes you could change your argument to why do "linux" boxes only run the Linux kernel? I mean for all intents and purposes you could write your own kernel that was interoperable and use instead. For the same reason why contributing to GCC is a good idea so is contributing to the kernel [instead of writing your own] is a good idea.
One last caveat before I send this post. I do agree though that writing such said tools [kernels or compilers in this case] are a good idea for educational purposes. It means a lot to know how to write a functional [and ideally half-way decent] compiler even if it only targets one platform and covers only part of a language.
phew...
Tom
Someday, I'll have a real sig.
That's most likely because the market for compilers has become more mature. There are usually fewer players left in a mature market than in a new one. It doesn't necessarily have anything to do with open vs. closed source.
You can tell this guy is a nerd, but it goes far beyond the pizza and mountain dew... Is that really an empty tub of frosting sitting my his computer??
The hostility mystifies me. I'm a semi-active participant in the GCC mailing list, and the people who work on GCC are very helpful, open, and communicative. Some even thank me for my QA efforts.
I don't see that my article is negative about GCC; in fact, I'm very clear that Intel's compiler isn't a replacement for GCC, and that GCC is a fine product. Maybe the complainers can't read?
All about me
Billy Gates is asking why a comment insulting open source was modded -1?
This is a classic...
The article seems to be rather narrowly from a computer hobbyists' point of view.
It fails to point out that compile times are a fairly critical factor in programmer productivity. Yes, we should care that compile times with the Intel compilers look to be over 25% shorter than with gcc on average. (very rough eyeball estimate)
I am amused, also, at how perplexed the author seems that IBM would ship Eclipse 2.x (and CDT 1.x, its associated C/C++ plugins) with the compiler. The CDT plug-ins for Eclipse 3.x were only ready a couple of months ago, so this is plainly a matter of how much time and money the Intel team had to test them with ICC. Or maybe they weren't available yet at all: when WAS the Intel 8.1 compiler released, anyway?
Ah! A typo! I cut-and-pasted the OS test, and forgot to change "AMD64" to "x86" for the Pentium 4. I just made the trivial edit.
All about me
The OpenBSD team use it, and I think they know better than you or I.
Not by technical choice, they want to use plan9's C compiler but have licence quibbles.
Quoting Theo : "in particular we were interested in the c compiler"
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I find it interesting that there are only two C/C++ compilers available for Linux, as compared with seven Fortran 90/95 compilers (soon to be eight with the release of GCC 4.0). This not only dispels the myth that Fortran is a dead language, it also suggests that there is much more of a competitive market in compiling numerical code, than in producing other types of software.
Tubal-Cain smokes the white owl.
One thing that the article doesn't focus on, but is also an issue for developers is the effect of actually using the compilers in a realistic development environment, where you have to integrate code from several vendors.
I write code for a large enterprise software company, and was investigating using the Intel compiler. More specifically, I needed to use Xerces, Xalan, and ICU, and Xerces and Xalan come with pre-compiled binaries that are compiled using the Intel compiler.
I started investigating, and one of the major hurdles I ran into was that Intel's CRT, libcxa.so has issues when linking several shared libraries that themselves individually link to different versions of libcxa.so.
For example, DB2's client libraries are evidently compiled using Intel's C++ compiler, but our DB2 client libraries were using a relatively old version, I think version 3. The Xerces libs were compiled using an newer version of Intel's compiler, I think version 5 or 6. When I tried to link my entire binary, I ran into run-time issues where the expected libcxa.so's conflicted.
We ended up ditching the entire thing and compiled Xerces and Xalan ourselves using gcc.
The other issue, of course, is what is our rights to distribute libcxa.so? I figured the entire thing wasn't worth it.
However, the Intel compiler did generate much better warnings and errors and in general felt much more polished. It wasn't for us, but it's something that should definitely be investigated if you want something that is commercially supported.
TCC (tiny c compiler).
Compaq Alpha C compiler.
OpenWatcom C/C++ compiler
TenDra C/C++ compiler
egcs compiler (which merged into gcc- they saw that it had some advantages.)
ChEmbeddable
Cint c/c++ interpreter (not exactly a compiler)
CC65 Commodore C compiler
Absoft C/C++ Fortran compiler
lcc
These all run on linux. Some are open, some are not. GCC is used mainly because it is portable to just about anything-- so there goes your argument of GCC restricting choice. GCC exists to promote choice, and it does this.
Take your code written for Visual Studio and compile it on Sun. Can't do that with Visual Studio? No MFC on Sun? Your best bet will probably be good old GCC with WINE. So how are you restricted by gcc?
Now, if you want to make a cross compiler to compete with gcc- one with seperate front ends and back ends, so it can accept multiple languages, and can compile to just about every machine on earth-- then nothing is stopping you. Oh, what is that? Not interested. Neither is anyone else. Programers see no need to duplicate something that has been done well the first time. One good cross compiler is enough- GCC represents a NATURAL MONOPOLY.
...does not apply to GCC. Never has. And it will not in the future, unless we radically change the way we do development and releases.
3.4 follows 3.3 follows 3.2, and none of them were singled out as "developmental" or "experimentalal" or "extra stable". The experimental-vs-stable changes all take place before any release branch is made. There's more info on the website if you want.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I've been developing in C++ with gcc 3.3 for some time, and just moved to 3.4 for some testing. Thank god for unit tests. There's some bitop-heavy code that gets miscompiled with full optimization (-O2). In the process of trying to debug these (I'm not prepared to assume that they're the compiler's fault, it could certainly be my code invoking implementation-defined behavior,) I managed to get the compiler to choke with the -fschedule-insns flag with 'no free register' errors.
In short, I don't have much confidence in the optimizer in 3.4. I'm trying to condense the problem to a testcase right now to submit a bug report.
Both Coke and Pepsi. What's the benchmark on those?
Analogies don't equal equalities, they are merely somewhat analogous.
Seems to me, you don't test the speed of a compiler on number crunching programs -- they are likely to have hand optimizations in them, and can benefit from hand optimization a lot more, so the compiler isn't as important in these applications since if you want real speed you write a core in asm.
He should have tested code that contains a lot of tangled up complex loops switches and jumps. Like libperlre's parsing and execution speeds. That and some really horribly over-abstracted C++ code where 15 classes are used just to add two numbers together.
(Perhaps the best test would be to compile a second copy of one version of gcc, and see how fast that can compile itself afterwards.)
Someone had to do it.
Portland Compiler Group has a compiler that's fairly decent and optimizes for both AMD64 and Intel 32-bit (although they're pushing the AMD64/clustering angle right now).
It's nice, but much less free. 15-day free trial. Prices are not bad, but it's still a little steep, even for an academic license.
This is not a plug... just in case anyone was wondering if there was something besides ICC you could try in to benchmark GCC on something that ICC can't cope with.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Another thing to try--LLVM can use g++ as a front-end to compile C++, and can often do further optimizations to speed things up even more. LLVM also has a C back-end, so you can benchmark other C compilers against each other too!
:)
Of course, the real fun will begin when it has completed Java and C# front-ends.
pb Reply or e-mail; don't vaguely moderate.
I'm always perplexed by such comparisons. Specifically, everyone talks about how awesome ICC is for numerical stuff. Well, I have written a fair amount of C++ code for computational fluid dynamics, and, for my code, GCC has always beaten ICC by a fairly wide margin (typically, 50 percent or more). Perhaps it has something to do with the fact that my code makes heavy use of templates? I don't really know.
Also, in my experience, the C++ standard library that shipped with the previous versions of ICC just wasn't that good. Well, that may be a little harsh, but it was a source of considerable irritation to me that ICC's implementation of valarray did not even use expression templates (hello temporaries!). Yes, I know valarray isn't all that, but it is standard C++ (hence, in principle, code that uses it is portable). Once again, the GCC implementation was very much superior. This may be part of the reason why ICC now uses GCC headers.
(As an aside, I did roll my own implementation of valarray that uses expression templates. I tested it with both GCC and ICC, and GCC still won.)
I am now curious to test whether things are indeed better with ICC 8.1 (the last version I tested was 8.0). Maybe this time it will actually speed my code up rather than slow it down.
Or, more specifically, you didn't think to check the facts of the parent post before assuming the author of the article was either stupid or horribly incorrect.
If you had actually read the article, you would have seen:
Corwin (Homebrew)
Gentoo AMD64 GNU/Linux, kernel 2.6 SMP
Dual Opteron 240, Tyan K8W 2885
120GB Maxtor 7200 RPM ATA-133 HD
2GB PC2700 DRAM
Radeon 9200 Pro, 128MB, HP f1903 DFP
Tycho (Homebrew)
Dual Boot: Windows XP Professional
Gentoo x86 GNU/Linux, kernel 2.6 SMP
2.8GHz Pentium 4 w/HT, Intel D850EMV2, 533MHz FSB
2x80GB Maxtor D740X 7200 RPM ATA-100 HD
512MB PC800 RDRAM
Radeon 9200 Pro, 128MB, NEC FE990
The complainers can't read. I'm a member of the GCC steering committee, and I'm very happy with Scott's work (sorry, dude, I'm not going to call you "ChaoticCoyote"). It's not perfect, but it has helped to improve GCC.
Quoting the article:
Actually, the name of the license is the GNU General Public License. It is "General" because when the GNU project began there was no single license used throughout the project; .
GCC can be commercial too -- many firms distribute copies of GCC for a fee. I believe the author should have said "proprietary" meaning that what the Intel compiler program does, exactly, is secret. As RMS said when describing a proprietary web video streaming application he didn't want MIT to use to distribute a feed of his talk on copyright and globalization:
GCC, by contrast, is free software licensed under the GNU General Public License. Getting back to the article:
Here I don't think "open" was the best choice of words, I think "free" would have been more accurate. The GNU Compiler Collection was originally the GNU C Compiler and first written by RMS. I guarantee you that RMS did not and does not now do work for the open source movement. He makes effort to make that point clear (like when he corrected Mike Uretsky who made the same mistake). The FSF asks you not to lump their work in with the work of the open source movement. Eben Moglen spoke at Harvard some months ago and also made this distinction. Prof. Moglen makes it clear why they are so adamant on this point:
I don't think he's overstating the case.
Finally, there's a common misunderstood myth repeated in the end of the article:
Many people believe this, I've even heard a variant of this myth being repeated by a representative of the Mozilla Foundation. Choice is no substitute for software freedom, in fact they speak to different aims entirely and in computer software choice is not as important as software freedom. If all we have are three web browsers to choose from (say, Microsoft Internet Explorer, Netscape, and Opera) choice is satisfied. B
Digital Citizen
Regardless of benchmarks, I consider the nasty backwards compatibility issues of GCC a serious problem. Virtually all of my Linux tech support time over the last two years has been spent messing with libstdc++ or libgcc_s versions to get various software packages to run. The problem is exacerbated because these libraries in turn are coupled tightly to glibc and pthreads, leading to more versioning headaches. My #1 wish for GCC is to get these libraries set in stone and make them as independent of glibc/pthread versioning as possible. I really want to be able to install a random C++ binary and have it work the first time.
Also, the ability to compile a C++ DSO without requiring the exact same compiler version as the program that will load it, is a major need for commercial Linux software vendors.
I was empirically analyzing the gcc 3.3.3 optimizer a couple of days ago. Some interesting points:
[argh...lameness filter refuses to allow source code]
I'm providing a link to my journal entry so that I can post these examples.
May we never see th
I am especially interested in GCC because I want to write a new front end (my own programming language). I don't want to mess with back ends, since I am not interested in that stuff; the linguistic part of the programming languages is far more interesting. But I can't find decent documentation anywhere on the internet for a GCC newbie. I tried looking at the source code, but it is an ugly mess of macros. The article of course mentions C/C++ only, but GCC is something more than that...I think it deserves a well written piece of how to extend it with new front ends.
I always get confused about people claiming compile time is important for development. It seems to be people who make a habbit of compiling everything from scratch. Haven't they heard of make? To me, link time is the limiting factor. When I make a change, I have to compile just the file I changed, or maybe a handfull of files if I changed an interface. And then I have to link all 236 files, which is where the time is spend.
I can see it compile time being important to people who use the compiler as an install tool (like gentoo users), but not for any serious developers.
Does anyone know if it is possible to use one of the alternative compilers ICC , OpenWatcom or Corneau ? to build a linux system from scratch?
I would be truely intrigued at what overall performance might be like.
Electronic Music Made Using Linux http://soundcloud.com/polyp
1983 called and it wants its programming language back.....
All your base are belong to us!
Nowadays LCC-Win32 is a very different compiler from LCC. Jacob Navia bought a license for LCC3.6 (IIRC) and has developed it independently since then. His version has lots of features (eg. optimizers, C99) not in Fraser's and Hanson's LCC. And then there's the whole win32 thing too.. (There is also a "rival" LCC for Windows written by a Swede, called Pelles C.)
Obscure names like 'yylex()' and stuff don't really help.
And I don't need lessons on yacc and bison.
I think you probably do need lessons on yacc and bison, if you think "yylex()" is an obscure name. It's the totally standard name for the lexer callback used in yacc and most of its clones. And the relevant section of the Bison manual is the third hit when you google for it -- so much for "no decent documentation"!
Methinks you could have chosen a better example...
If you don't want to mess with back-ends etc, why not get your program to spit out C code? Then compile that with gcc. I think that SmallEiffel started out this way.
Reality is defined by the maddest person in the room