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."
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
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.
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.
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.
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??
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 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
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.
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.
Tree-SSA is not new, it's new to GCC but the concept of Single Static Assignment itself is ancient and using it for optimizing trees in not new.
The problem is the GCC codebase is so badly designed it takes major changes to many parts to introduce a very old concept of SSA into it. So you can't take advantage of a generic SSA but have to introduce different patches for the system.
Back in my university days we did SSA in our own compilers, for a 5 week course! GCC needs a complete rewrite or a switch to something like TenDRA, which right now produces good solid code, but not extremely optimized machinecode. On the other hand TenDRA is really well designed so it would catch up really fast if more people worked on it.
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
Erm. If you look at the current top500 you'll see that there's a Xeon machine in the top 5.
Have you actually tried other platforms? The best compiler on a given architecture is usually the chip vendor compiler -- IBM's compiler beats GNU on PPC 970, HP's beats GNU on Alpha, etc.
Sure you can find the odd piece of code where Gnu will beat vendor compilers but overall, and particularly for large scientific workloads, vendor compilers win for raw speed.