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
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.
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 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
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
...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)
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
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.
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
This isn't true: V8.0 works fine on Athlons.