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
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.
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.
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?
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.
Unless you are targeting for binary compatibility among different architectures, the question is somewhat meningless. If you need to compile from the source, you may very well use a faster tool for the job; it can be Intel for Pentiums, and GCC for the rest.
Granted, if you want to deliver a binary that runs on other platforms (by means of emulation or whatever) you better stick to GCC. Now, how many times do you need this?
I believe the author of the article himself is stating that in the end you should be using the best tool for the job. So there.
Wolfram has some interesting points, but I think his ego has gotten in the way of good science. With his "New Kind of Science", Wolfram hasn't really "invented" anything; he's mostly implying meaning where it may or may not exist.
On the other hand, I do believe that higher order derives from basic, simple, underlying processes that combine in great complexity. Turning that supposition into real science is something I hope to see happen in the next century.
All about me
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.
Who cares about memory when hard drives are so slow? Reading from laptop HDs is especially painful and binary size does come into play.
Time makes more converts than reason
Maybe, or by expanding the loop you just induce a bunch of cache misses which hurt performance more than the couple extra instructions to check a loop variable. In today's world memory is an order of magnitude slower than today's processors. By not unwinding the loop you get the benefit of the temporal locality. Of course the n copies of the loop may be fetched in one memory access. It all comes down to how many blocks are fetched by the cache for a miss, vs size of the unwound loop. If all n copies are fetched in a miss you win. If it takes n memory accesses instead of 1, you lose.
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.
Politics is holding GCC back once again ... FSF better pray LLVM doesnt get critical mass, or it will be EGCS all over again.
So let me get this straight. You are attacking the writer for saying that that is a typo instead of a mistake? You, sir, are pedantic.
But let me for a second play your game.
Technically, by dictionary, a typo is "An error while inputting text via keyboard, made despite the fact that the user knows exactly what to type in. This usually results from the operator's inexperience at keyboarding, rushing, not paying attention, or carelessness."
This means that should you accidentely type something totally different by habit or just thinking of something else, this will also classify as a typo under the definition of the world, for example typing "Gentoo AMD64" instead of "Gentoo x86" because he was copying the same format as above.
Unfortunately you have just assumed that he made a mistake, that he literally thought that he had the AMD64 version installed on his computer, and thought "I knew there was something wrong with that", or he thought that Pentiums were a special class of Athalon 64. That would be classed as a mistake.
Don't you know what they say about assuming: "don't assume or you'll make an arsehole out of yourself", or something like that. I say similar things about being pedantic as well.
Sounds like jealousy to me... ;)
All about me
In particular small code can make apps start faster, and the whole computer feel more responsive. The day computers never swap and disk I/O isn't a bottleneck will be the day we can ignore code size in compiler benchmarks.
GCC only sucks under Windows for x86, at least in my experience.
This is going to be an unpopular comment. But the problem isn't that GCC sucks, it's that MSVC is very good. GCC produces similar results on all x86 platforms. MSVC produces faster code on Windows. That is, the Microsoft product is simply better than the GNU product.
Posted anonymously for reasons that should be obvious...
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