GCC & LLVM Clang Performance On The Intel Atom

[phoronix]

Phoronix: GCC & LLVM Clang Performance On The Intel Atom

A few weeks ago there were benchmarks of GCC, LLVM-GCC, DragonEgg, and Clang. In this compiler performance comparison the releases of GCC 4.2, 4.3, 4.4, 4.5, and a 4.6 development snapshot were benchmarked. On the LLVM side there was LLVM-GCC 4.2, DragonEgg with GCC 4.5 and LLVM 2.8, and then Clang with LLVM 2.8. This combination of eight open-source compilers were tested on three distinct Intel and AMD systems (even a 12-thread Core i7 Gulftown), but all of which were 64-bit capable and contained relatively high-end processors from their respective series. To complement this earlier article, available now are some new GCC/LLVM benchmarks but this time an older Intel Atom CPU was used to look at the 32-bit compiler performance on a slower, low-power netbook.

http://www.phoronix.com/vr.php?view=15517

[DavidNielsen]

Clang continues to impress me, I can't wait for it to be capable of compiling a full standard distribution. In fact I have been eagerly eying FreeBSD again after years away from the platform because of their investment in making GCC history.

[XorEaxEax]

In fact I have been eagerly eying FreeBSD again after years away from the platform because of their investment in making GCC history.

Why would you want GCC to be history? I am very happy to have competition (finally) on the open compiler front and the last thing I would want is a lack of competition again. Is this some BSD licence zelot/anti-GPL thing?

[DavidNielsen]

Why would you want GCC to be history? I am very happy to have competition (finally) on the open compiler front and the last thing I would want is a lack of competition again. Is this some BSD licence zelot/anti-GPL thing?

Several reasons, firstly it is blindingly obvious that the horse to back is LLVM + Clang not GCC. The sooner we can switch the better for all involved. It is progressing extremely rapidly as a technology and is finding uses in places where GCC cannot.

Secondly, looking at how the FSF has run GCC e.g. you will see that they directly prohibited things like plugins for reason not of technology but to protect their ideological bend. Thus disallowing, in practice, the use of GCC for things such as static analysis which LLVM offers us today. Static code analysis is just one of many technologies we could and should deploy to ensure secure and performant code. The FSF playing politics with the compiler and their licensing has actively prevented that, in effect putting Open Source software in a worse place than it had to be (so much so that Coverity has made a small fortune running such tests on select codebases for us - using of course proprietary software which I hardly would call a win for ideology overall).

Thirdly, I prefer a BSD/X11 style license (specifically I am personally rather fond of the MS-PL license but that is besides the point).

GCC is holding us back, the few areas where it currently leads such as proactive security I expect Clang will catch up shortly - as the tests show performance of the resulting code isn't holding for long. In the mean time your average distro will be moving to ship LLVM for the Gallium drivers, likely also for Mono and Python (if Google's work will ever get mrged) and many other aspects. Making GCC effectively redundant code, and who wants to maintain two separate code paths which both have to be supported.

I believe the sooner we start moving towards a goal of compiling our distros with Clang and obsoleting GCC, the sooner we will start reaping the benefits that are inherent to such a move. FreeBSD have realized it's potential and have started this move, I believe we are behind technologically and the time to start this work is now.

[XorEaxEax]

Secondly, looking at how the FSF has run GCC e.g. you will see that they directly prohibited things like plugins for reason not of technology but to protect their ideological bend.

No I don't buy that at all, just like the reason GPL is the most widely used open source licence because programmers see it as a _practical_ way to get a 'quid pro quo' mechanism for their code, the same thing underlines the reluctance of plugins for the GCC project. It was so that GCC would not end up being a frontend/backend for closed source proprietary solutions and instead having all improvements made available to all. While you may see this as something ideological, I see it as practical. I also think it's alot easier getting corporations to contribute in a 'quid pro quo' environment than getting them to contribute when there's no need, and worse your competition may use your contributed enhancements together with their own (kept) enhancements to compete against you. This especially holds true with plugins where it's easy to maintain your proprietary code against an external project since the only changes you need to worry about are those of the plugin interface. But that's just my opinion, and I won't try to hold it as fact.

GCC is holding us back, the few areas where it currently leads such as proactive security I expect Clang will catch up shortly - as the tests show performance of the resulting code isn't holding for long.

Ahh, trying to portray GCC as a project that is standing still. But please explain how it is 'holding us back'? LLVM is there if you want to use it, and although it seems very popular again to use as backend for proprietary solutions there seems to be a shortage of corporate contribution aside from Apple. Meanwhile GCC has strong corporate support and even Intel hiring CodeSourcery to enhance optimizations for the Core Ix line.

I really see no facts supporting your claims but rather a whole lot of wishful thinking. And finally the one thing I think WILL be holding us back in this field is the lack of competition, thankfully now we have competition and I really don't want to lose it, unlike you.

[smitty3268]

Secondly, looking at how the FSF has run GCC e.g. you will see that they directly prohibited things like plugins for reason not of technology but to protect their ideological bend. Thus disallowing, in practice, the use of GCC for things such as static analysis which LLVM offers us today. Static code analysis is just one of many technologies we could and should deploy to ensure secure and performant code. The FSF playing politics with the compiler and their licensing has actively prevented that, in effect putting Open Source software in a worse place than it had to be (so much so that Coverity has made a small fortune running such tests on select codebases for us - using of course proprietary software which I hardly would call a win for ideology overall).

Thirdly, I prefer a BSD/X11 style license (specifically I am personally rather fond of the MS-PL license but that is besides the point).

So yeah, it's mostly about politics.

Making GCC effectively redundant code, and who wants to maintain two separate code paths which both have to be supported.

This is your other point, and I agree that there is something to be said about focusing developer resources on 1 compiler rather than 2. Clearly LLVM is using a much cleaner design and codebase, and it is much better suited to being used as a service inside other software, while GCC was designed to just compile applications more traditionally. Don't forget, though, that there are still lots of languages and architectures that GCC supports and LLVM doesn't, so it's not like LLVM is the only one that has any advantages over the other.

Anyway, I think there is actually a benefit to keeping some competition in the compiler arena, rather than just having everyone use the same thing. At the very least it should help keep software a little more friendly to being ported to other compilers.

FreeBSD have realized it's potential and have started this move

Let's not pretend that decision had anything to do with potential. FreeBSD doesn't like the GPL license and that's the reason they are switching.

[Thuglife]

Let's not pretend that decision had anything to do with potential. FreeBSD doesn't like the GPL license and that's the reason they are switching.

whoa!

http://news.ycombinator.com/item?id=1570090

The GCC situation is a bit more complicated than that. Importing new versions of GCC is a major PITA due to changes needed in FreeBSD not being accepted into the main GCC tree. We've been saying "gee, it would be great if we could get rid of GCC" since long before GPLv3 came out.

GPLv3 caused Apple to support LLVM development, which caused LLVM to be production-ready; and that combined with the general crappiness of gcc is causing FreeBSD to switch to LLVM. The licensing issue is a slight irritant, and without it we might have ended at 4.3 or 4.4 instead of 4.2.1; but it's certainly not the biggest issue.

[XorEaxEax]

Keep these benchmarks coming, really looking forward to the ARM tests. Also great that you've opted for the latest point releases in your tests, makes the result much more relevant.

[mirza]

Add Intel icc to the mix, so that we have some perspective. I am sure Intel will readily provide you with a copy, unless they are afraid of comparison. :-)

[BlackStar]

Add Intel icc to the mix, so that we have some perspective. I am sure Intel will readily provide you with a copy, unless they are afraid of comparison. :-)

That would be awesome!