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."
by default, gcc (with a .c or lang-spec set to c)
let's you forget the #include, and the missing return value
GCC has other things going for it, too.
ProPolice stack smashing protection patches for one. (and many others besides.)
And cross-platform compatability. I can compile for targets. Like working on embedded products.
Oh, and Distcc for realy big projects to get compiled quickly using easy to setup clusters.
It's "correctness" is pretty high up their, too.
Remember, for Unix:
compatability, portability, flexibility > speed.
If all you ever have to worry about is x86, then it's not that big of a problem, but for anything else there is no comparision to GCC that I am aware of.
That it having it free software rocks.
The current version of GCC is 3.4.2, and the next planned version will be called 4.0.0
More info on the GCC site
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...
32 bit intel binaries will run on an Opteron and will probably give some gain as seen here at Aces.
Aces article
This mostly comes from specializing loops and jumps. ICC does aggressive loop versioning (even including runtime CPUID checks) and, especially with profile feedback (not tested in this benchmark, unfortunately) ICC will try aggressively to try cheap alternatives before trying the generic approach. Think about expensive instructions such as divides and indirect jumpes here. GCC doesn't do that.
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
And how likely is GCC to continue supporting the features you love? In case you haven't been checking, gcc-3.4 has removed some of its extensions to C grammar (the old joke used to go that gcc can accept a perl script as valid input). I use Gentoo, and after gcc-3.4 was released, I frequently encountered programs that refused to compile with 3.4. If anything, proprietary software (especially Microsoft's) tends to emphasize backwards compatibility over all other considerations.
If gcc-4.0 makes your source unusable, will you patch the compiler? How long do you think it will take you to familiarize yourself with the source enough to figure out where the undesirable changes were made?
Maybe, maybe not. But while my chances of being able to fix gcc-4.0 may be infintessimal, they're infinitely higher than the (zero) chance of my being able to fix icc (legally).
CEE5210S The signal SIGHUP was received.
ICC7 would compile to MMX/SSE that works on Athlon XP's just fine, but they changed that in v8 so it'll die on any non-Intel cpus.
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
Nope, no troll.
Icecream is created by SUSE and is based on ideas and code by distcc. Like distcc it takes compile jobs from your (KDE) build and distributes it to remote machines allowing a parallel build on several machines you've got. But unlike distcc Icecream uses a central server that schedules the compile jobs to the fastest free server and is as this dynamic. This advantage pays off mostly for shared computers, if you're the only user on x machines, you have full control over them anyway.
I'm not sure, but I'd guess that 4.0 is the place where major development is happening, where major changes/improvements are made, whereas 3.5 is where minor/incremental stuff is being done.
I'm afraid you're wrong. 3.5 is the current development version of GCC. Amongst other things (which include a new Fortran 95 frontend -- hurrah!), it uses a wholly-new optimization architecture known as 'Tree-SSA'. This change is so radical that it was recently decided that 3.5 should actually be released as new major revision -- i.e., 4.0 -- rather than as 3.6 (recall that many open source projects use odd minor version numbers for development branches, and even ones for stable releases). Therefore, 4.0 is what 3.5 will be once it is released as stable.
You may recall that a similar version renaming was mooted for the latest Linux kernel, but it was decided to leave it as 2.6 rather than 'upgrading' it to 3.0.
Tubal-Cain smokes the white owl.
Well unless the benchmark is not good, the icc was not faster than gcc and was slightly slower and had much larger binaries.
I was supprised to see that.
Maybe on a risc platform I could see buying a proprietary compiler.
http://saveie6.com/
I don't know what's up with distcc, but every time I try it, it ends failing at some point. For example a few days I was installing Gentoo, with CFLAGS having -fstack-protector, and distcc crashed somewhere in the bootstrap due to the stack protection. I didn't figure out if it's some kind of conflict, or the stack protector kicked in due to a bug.
I also heard reports from people about Gentoo not completing the basic installation when trying to do with with distcc even without the stack protector.
The idea itself is really nice, but at least for me doesn't seem to work nearly as well as it should.
GCC 4.0 (which is, of course, "in development") has recently included automatic vectorization -- another of the "good things" that will be coming with the new architecture.
My next article will compare automatic vectorization and profiled optimizations.
All about me
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?
It's called a "typo". Fixed.
All about me
The GCC Steering Committee changed the next version of GCC from 3.5 to 4.0 while I was in the midst of writing the article. I missed changing a reference; the typo is now fixed.
All about me
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.
...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.
I thought in the docs it says not to use distcc for the bootstrap process. Perhaps I am wrong but I thought I remember seeing that. Then again, it's been quite a while since I've installed Gentoo. Distcc works fine for me after installation though.
Time makes more converts than reason
Who said there are only 2 compilers? He only tested 2, that's all. Here's a bit of a list - and notice that some of these are targeted specifically to scientific computing:
1. GCC
2. Intel compiler (Intel only)
3. Comeau
4. PathScale (Opteron only)
5. Portland Group (PGI)
6. Borland
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.
Not true at all. Every compiler has specific extensions that are not implemented in other compilers, and they are support different parts of the standard with different levels of compliance. Template support for C++, for example, is different on every compiler, so there is a lot of cost in switching compilers if you have a large codebase.
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
Contrary to popular opinion, x86 only make up less than half of Linux machines. Most Linux devices are embedded systems running on ARM, MIPS, PowerPC etc which, I'm sure, the Intel compiler does not support.
Engineering is the art of compromise.
The gcc is not a linux compiler. The g stands for Gnu. The linux kernel and the systems built around it are most often compiled with the gcc. The gcc existed long before Linus's first kernel release.
--
ken_i_m
Founder, Bozeman Linux User Group
I would certainly hope there will not be a GCC 3.5 created by someone else. Can't think of any reason to, really.
From GCC 3.3 onward, almost all development of GCC was centered around the tree-ssa project (the new optimization framework for GCC 4.0) and even though bits were in GCC 3.4 (unit-at-a-time for example), there really isn't any major new functionality in GCC 4.0 that is easily backported to GCC 3.4 that would suddenly make it different enough to call it GCC 3.5
And even new major functionality doesn't mean one has to give a new GCC its own version number. If you look at the SUSE compilers from SUSE 9.0 and later (based on the hammer branch), they claim to be GC 3.3 based, but they're more like GCC 3.4 without the new C++ front end.
RedHat had to do gcc-2.96 because GCC 3.0 was so awfully overdue and they had customer contracts to satisfy. They gave it a new version number because the C++ ABI it implemented had changed from 2.95. The problem was that the ABI was also not the same as the one implemented for GCC 3.0. That basically caused all other linux distribition to be binary incompatible with RedHat. That caused some hard feelings...
This isn't true: V8.0 works fine on Athlons.
It will let code through if there isn't too much of it.
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.)
That's funny: my templates, which are written to the C++ standard, work just fine under GCC, SCC, ICC, Comeau/EDG-based compilers like MSVC and BCC, and so on. Rather than make claims that things vary from compiler to compiler, why not show us some examples?
StoneCypher is Full of BS
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...