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
Not going to be returning an int with that first post then?
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
Not bad. Not bad at all. Hopefully this will indeed spur development and add some competition to the otherwise small compiler market. :)
US businesses that currently accept chip and PIN/signature
see above secondary post...
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.
I don't have much to add but wanted to say thanks for an interesting read.
Learn something every day--thanks :).
CEE5210S The signal SIGHUP was received.
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 don't get what you don't get.
...
I mean Linux was running on AMD64 natively since the very first day they started selling it. Suse specificly, but Gentoo soon followed.
And you can compile 32bit on it if you realy want to
Is it just because Windows XP-64 is overdue for a year now you don't think anybody else can do it or something?
AMD needed a server OS to push the opteron platform and to take advantage of it's 65bit-ness. That was it's major advantage over Xeons...
MS's OS design is monolythic, highly optimized for x86 platform and rigid, it makes for slow ports. However on the other hand Linux has run natively for years on various 64bit platforms and is very modular in design. Making porting a snap.
Oh, and in case you guys go "Windows has run on 64bit platforms too!!", I know I know.
NT ran on 64bit alpha, but in 32bit mode. W2k had a advanced beta that ran in 64bit native mode, basicly it compiled and booted, but that was about that. It has very little to do with the win32 stuff you use today in XP. Lately there are Windows servers versions for Intanium, but still nothing for the Opteron.
Im sorry, but in my mind anything this guy puts out is invalid. He is using a 64bit distrobution on a 32 bit chip? He is using something designed for an AMD64 chip on an Intel chip?
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/
really only very few people truely believe it makes a difference.
The OpenBSD team use it, and I think they know better than you or I.
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.
Still doesn't make it correct. You should #include for everything you use and always declare main() an int and return a value...
Sure, I'm being picky, but meh, sue me.
The title of the piece is "Linux C and C++ Compilers", yet the only ones benchmarked are GCC (various versions) and Intel's 8.1 ICC. Aren't there any others out there???
You know, it seems there were far more compilers available for DOS and OS/2 than are available for Linux. To me, this says that Open Source removes software choices from the consumer in the long run, which means that open source is not a good thing for the general software-consuming public. The ones that benefit from open source are those who don't want to pay for software...
Future generations will look back on open source, curse us and wonder how we could have been so naive and self-centered as to actually promote it...
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?
The basic point, simplified, is that the 533MHz FSB Pentium 4 chips don't have EM64T (a.k.a. AMD64, x86-64). Some of the latest Prescott-based chips do have EMT64T, but not the tested equipment.
I dont understand why the parent was modified to a -1??
http://saveie6.com/
Why all the comments that are vehemently pro-gcc? It reeks of a defensive posture when none is necessary. The man is trying to conduct a semi-scientific test. Isn't /. about science and truth and news for nerds that transcends the tripe in the mainstream media? If so, why the instant hostility?
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 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?
Brilliant! Mister Coward, your troll is truly creative and deserves our applause.
Well, world consists not only of users but some people also develop stuff that you run. And for them compile times are also very important.
Oops, Intel's name for x86-64 is EM64T, not EMT64T.
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.
Good points.
I've had problems using Intel to integrate existing libraries. As of version 8.1, the binary compatibility is supposed to be better, but I haven't had a chance to apply it to a really big project. In all fairness, GCC has had some similar problems with the C++ ABI at times.
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)
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.
Okay, it's nice to have optimizations to generate fast code and all, but the best thing the gcc folks could do for free software is improving compilation speed. While the c compiler isn't too bad (still slow in comparison to other compilers I've seen), the c++ compiler is just plain awful (it appears that 4.0 is even *worse*). I once saw a 40 line c++ program that used template meta-programming techniques take 120 seconds to compile w/o any optimizations turned on. . .with -O2 optimizations turned on, it took 28 minutes to compile.
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.
- Maturity
- Speed
- Correctness
- Standards
Compliance
- Inexpensive and affordable
- for Linux and other platforms
Anyone doing a survey of C++ compilers for Linux better damn sure include Comeau C++. It was the first standards compliant C++ available for Linux, and it can trace its roots directly to Bell Labs.So folks, please recompile everything to take full advantage of the improved binary compatibility !
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.
Spurred by the article, I decided to give the Intel compiler a go. However, one stumbling block I've come across is that it doesn't seem to have a visual debugger. That is, idb is akin to gdb. I'm interested in something like gvd or ddd.
Does anyone know of a way to do visual debugging on the Intel compiler's code? (thoughts which come to mind: maybe the Eclipse environment? Maybe a gcc debugger, like gvd, would work on icc's code? Maybe there's another Intel product for visual debugging?)
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.
Apathy is under-rated. Ignorant mouth-breathers should remain apathetic.
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
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.
obviously someone needs glasses.
RTFA.
I quote:
Corwin (Homebrew)
Gentoo AMD64 GNU/Linux, kernel 2.6 SMP
Dual Opteron 240, Tyan K8W 2885
there you go, a dual opteron. duh?
all I saw was some hot anime chick...
i've seen increases of over 50% running the same 32bit code on an opteron in 32bit mode. there have been some fundamental architectural changes that make running 32bit code a lot faster than the equivalent p4 or athlon - changes that aren't due to l1 or l2 or on-die memory controller either - but rather fundamental changes with the way instructions are dispatched and processed.
Indeed. The standard mandates this behavior; it dates from the K&R days.
We run several Intel P4 Xeon (HT) machines at work for our databases, until recently we were either compiling with GCC or using the MySQL official binaries.
I saw binaries on the MySQL site compiled with the Intel Compiler so I gave it a shot. We've seen much better performance, queries probably run from 15-20% faster. I don't have the exact numbers with me now but the mysql benchmark suite really showed improvement.
I highly recommend you at least check these binaries out if you're running Intel database servers.
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
You'll note that amongst the replies to the original post was a post from the author of the article, noting the error (apparently a typo) and saying he had now corrected it. I suspect you saw the corrected version (and I agree, it now is).
As for the amount of mod points my post got - who knows, mods on crack. I was just trying to write something useful for all the people who failed to note the original posters point. Check the immediate parent of my post if you're curious - there was some misunderstanding initially.
Sorry for any confusion.
Jedidiah.
Craft Beer Programming T-shirts
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.
Those are GNU's compilers, not linux's. Why do you take all the credits from GNU which was the oríginal developer of the system? By calling the whole OS Linux, people who hear it first time think that Linus started it all with his kernel and there wasn't anything before that. Please, GNU/Linux and GNU's compilers.
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20040911/
Actually, there is not GCC-3.5 snapshot in this ftp.
open4free ©
Depends.
For mission critical applications, compiling on BOTH is a huge advantage - namely getting, or seeing different errors and warnings.
No matter which side of the fence you sit on, trying something different can be a real eye opener. Familiarity breeds contempt.
In Testing, you should try to break things, expose weaknesses. Contractors often switch compilers, switch off checks, and the client says geeez those guys are good - all their stuff compiles clean. Lucky the client never bothers to scratch, or think terribly hard.
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
What is exactly the point of comparing gcc and g++?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Politics is holding GCC back once again ... FSF better pray LLVM doesnt get critical mass, or it will be EGCS all over again.
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.
IBM VisualAge C++ is also supported on Linux.
You might ask "why?" -- and the answer is the same as if you asked "Why are companies still selling Fortran compilers?": a whackload of existing, working code and a build environment that would cost mega-bucks to port to a new set of tools.
It would be interesting to see how VisualAge compares on ChaoticCoyote's benchmark. I hope IBM contacts him to get into the next edition of his benchmarks.
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.
he does mentiont that the SciMark benchmark is only in C. Should I then assume that all the other tests are C++? Otherwise great article and I'd love to see more on the topic.
No, the point of Gentoo is not optimization, although it is certainly possible to use the distribution in this fashion. The main point is that Gentoo is a meta-distribution that lets you customize the setup every which way. Other distributions make package configuration decisions for you, whereas Gentoo allows you to make them yourself.
:)
Want ALSA support in everything? No problem. Want to disable KDE or Gnome for every package? No problem. Want to add IMAP and LDAP support to everything? No problem. All that is necessary is to set the USE flags.
Since Gentoo is more or less a bleeding-edge distribution, packages get updated frequently. Under these circumstances, compiler speed is far more important than every last bit of optimization, unless you are one of those power-user-masochists.
What happens to GCC's compile times when it's been compiled with ICC?
:-)
Honest question - and one I think could be quite useful to know the answer to
Does anybody knows if icce 8.1 produces optimized
code for Opteron processors? How close is Intel's
extended memory 64 technology to AMD x86_64?
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!
Then turn it on for final testing and deployment.
Jeez.
I am currently working on neural simulations of the motor cortex. The machines I have for development are dual pentium IIIs - the production environment is 128 processor linux cluster. I have compiled my programs both with gcc and intel and have to say the pentium III sse compiler directives and loop optimizations appear to produce faster code (approx. 10% faster) using the Intel compiler. This means a lot on a real simulation (approx 30 hours).
So if your goal is to get code to run fast on Intel platform the Intel compiler may have it's advantages.
C++ has an implicit return EXIT_SUCCESS from main. The lack of a declaration for printf, however, makes this first post highly suspect.
XML causes global warming.
There's been an effort from the GCC developers and the Intel icc people to converge, with gcc-3.4.0, on to a C++ ABI that is more correct than had existed previously (ie gcc-3.2.x, gcc-3.3.x, icc-pre-8.1x)
/ msg00375 .html
Some of this is compiler-side: g++ bugs were fixed and implementation errors in the IA64 C++ ABI were ironed out.
Some of this is library-side, where libstdc++ can now be compiled with non-g++ front ends.
See:
http://gcc.gnu.org/ml/gcc-patches/2004-04
I've not had any problems using gcc-3.4.0 and libstdc++.so.6.0.x mixed in with object files created with icc-8.1.
It's actually quite cool that this can be done now. I was surprised to not see this hyped more, actually.
it's happened already - some of the main C++ benchmark programs run faster under LLVM than with GCC. Competition is a very good thing. Let's see if GCC's SSA will turn the tide.
She INSISTS on Diet Coke... Only "full fat" Coke does it for me.... Rum is probably one of my favourite hobbies! ;-)
Time flies like an arrow. Fruit flies like a banana.
Jesus. It's two clicks from the GCC front page: hit 'front ends' on the link list to the left, then the second link down, 'other links and readings'.
If you can't make it to the first line of the third paragraph in the front ends front page, you're probably not cut out to write a new front end, and it's a hell of a lot harder to write a GCC front end than it is to write a whole new compiler. Truth is, you really should be looking at YACC and BISON, not GCC at all. Go read Aho before you attempt anything further.
StoneCypher is Full of BS
What behaviour? You mean perhaps undefined behaviour? The prototype of printf isn't "int printf(char *)". All bets are off once you call it with that prototype.
Besides, implicit function declarations have been deprecated since 1999 anyway.
Worked pretty well when i used it for class projects.
http://bloodshed.net/
I've read most of the material supplied in the links you have posted...it's inadequate. Sooner or later the frond end maker will be confronted with requirements from parts of GCC that are simply not documented anywhere and it is only the GCC developers that know. Most material is very superficial, and the most frequent comment is 'look at the source code files x, y, and z for more information'. The source code file is a mess of macros that one has to go deep in order to understand the outter layers. Instructions are not analytical (most of them say 'just place X and Y file in there' or provide functions a, b and c) without saying why. Obscure names 'like 'yylex()' and stuff don't really help.
And I don't need lessons on yacc and bison. I know very well how to write a compiler (scanner->parser->AST->intermediate language->assembly). My problem is how to apply that knowledge to GCC, because I don't want to re-invent the wheel.
When I say it is inadequate, I mean about myself. I don't have the time nor the appetite to read, decode and analyse line per line the work done by others, just because the is no decent documentation.
While we're picking appart semantics...
You can't really measure "quality" with a benchmark. This is really a performance comparison of compilers, rather than a quality one.
Quality is usually defined as the number of delivered defects in a product, in this case the compiler. The only "quality" measurement comes from the fact that one of the produced executables generated a segfault. We have identified a single fault in one of the compilers. This is hardly an adequate sample size to determine the relative quality of either.
Just out of curiosity: Which language where you actualy planning for?
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
Hey. I'm going to be real honest here. We're all techies right? You would last 5 us or less (and yes that is microseconds) if GCC was a crap compiler. RMS wouldn't forgive you. Your mother wouldn't forgive you. Shit. Don't even think of what Eric (the raymond) would do. He packs serious firepower (cowers under pine tree - hey at 2000+ miles even he can't hit me unless he really did get that tactical nuke). But, we know that the demons we love don't work this way. Honest. (checks the tactical nuke indicator ). Foo. Get a life. Or even an interest in something like Python. GCC is about the most seriously good compiler out there. It may not always make the most pretty code. It may not be friendly. But damn it. You know that if it breaks you can talk to the guy who (god help him or her) broke it. You'll never get that luxury with (cough) that compiler that is called CL. If you need to understand what OSS is. I just told you. Is it the best? Hey if you need to shave that extra something out then you ought to consider the quaint old fashioned roll up my sleeves assembly approach. Coughs and splutters (should really give up smoking) ---- I don't understand children that are scared off this stuff. It wasn't bad for my (oh serious pain in my chest here) H E A L
But when RMS started his idea for the GNU project none of us believed he was anything except a hippy wacko. Honest. Without *his* input there would be no Linux, No GCC , No EMACS (some might like this) and lord knows how many businesses couldn't have existed. Before Richard , software could cost so much you'd have to sell your grandmother. Don't ask the price of a Fortran or C compiler. Yes. This was the world of 1990. Not 1890. We owe a great debt to Richard. I for one have a fund specifically aimed at Beer for said people. One day, I hope to buy RMS a brewery....Hey, it's going to take some time but I figure that with a few helpful souls we could imagine doing this... A very long time ago a guy called P.J.Brown wrote a delightful book about software development that suggested that if you offered your customers a beer when they discovered a bug then they'd be motivated to find bugs. Don Knuth has a similar view with Latex (sorry about the absent subscript) I like such people. Hey I'm a techie. Gosh I'm running (or is that ruining) a company. Ouch. Honestly, there is no reason to get emotional about compilers. I used to have a friend who spat this stuff in his sleep (and yes, he came back from meeting Nicky in Zurich with a very big smile on his face). I have to say that in the real big wild west out we live in it doesn't matter. GCC is a good compiler. Period. It was a damn good C compiler even when it was 2.x.something. C++ (sigh). You want to play with that shit? Sorry, at CMU, who should know doesn't really like using it. Above all, (and since it's been a long time and most of you perhaps don't know) *DON"T PANIC*. Yes, the hitchhikers guide is back *tomorrow* on our very much beloved BBC. Have fun /.ers.
(don't slashdot them or I send my Greek friends
Italian friend who may or may not work for those
nice italian business people around to rearrange
your furniture).
I have to make this really stupid comment.
If I don't nobody else will. I once had the honour
and priviledge of working with someone who lived
and breathed compiler technology. It was a long time
ago. It was Modula-2. So what? It was TDI (yes, those
people in the old Atari ST days).
Now, my friend was a serious deep thinking man. When
he came back from meeting Professor Wirth (yes that
guy at ETHZ) he smiled a lot. You see, my old friend
Mr. P.C. (not joking those *are* his initials) managed to do some very very pretty things for the code generation of the compiler we had from those
splendid swiss people. John Coltrane would love
that name though...
Foo. You people are mere virgins. GCC is a good
compiler. Period. But that's like saying that
my light is a good illumination source. Doesn't help. If you're so desperate are you in fact asking the wrong question?
I know 'yylex' is a standard name of yacc. I just said that it is not descriptive enough of its function. It takes time to get used to it...that's a case with a lot of things regarding GCC. It feels like a hack; it's not a hack, but it makes the life of a newbie more difficult than it should be.