LLVM 2.8 is available
LLVM 2.8 is available
Posted Oct 10, 2010 15:05 UTC (Sun) by mlopezibanez (guest, #66088)In reply to: LLVM 2.8 is available by bjacob
Parent article: LLVM 2.8 is available
However, the progress in LLVM seems much faster in comparison.
The focus of GCC is fast code, not fast compilation, modularity, extensibility or modernisation. There is some of this lately, but it is not the main focus. The focus of LLVM/Clang has been usability, fast compilation, extensibility and modularity, and replacing GCC.
One may argue that LLVM has seen such fast progress because they have so far implemented the "easy parts", but reaching the fast code and feature-parity of GCC will be much harder and imply a regression in the current qualities of LLVM (fast compilation, modularity, etc.).
The argument from the other side is that it will be much easier/faster to match GCC's performance and features from the current LLVM modular and extensible base, than for GCC to match LLVM's usability, fast compilation, extensibility and modularity from the current GCC's base and speed of progress. Moreover, GCC performance improvements become harder and harder to achieve because of the law of diminishing returns.
Which argument is right remains to be seen, but the answer will be determined by which contributors can each project attract and what those contributors work on.
It also depends on how you define success:
* Which compiler most free software developers decide to use?
This remains to be seen, but the tide initially can only be in favour of LLVM/Clang (because it is the only alternative to the status-quo). There is a lot of dissatisfaction with GCC, and LLVM/Clang marketing is cleverly tapping on it.
* Which compiler is used by distributions to compile their code?
GNU packages will be compiled with GCC, not matter what, as long as GCC supports the source language.
GNU/Linux distributions won't switch to LLVM/Clang until they can compile their whole archives of packages without a problem *and* obtain a significant advantage in compilation speed without compromising execution speed. However, it is likely that they will support LLVM/Clang as soon as their customers start using software derived from it.
However, some *BSD distros are actively contributing to LLVM in order to ditch GCC, and to do that, they have to implement GCC's features, so they are working on facilitating the potential switch of GNU/Linux distros.
* Which compiler has the stronger developer base?
This is probably the most interesting measure of success. Currently, both projects have strong developer bases and big companies supporting them (in some cases, the same company is providing developers for both, such as Google). GCC will remain strongly supported by GNU/Linux distros and some smaller compiler companies. Whereas LLVM/Clang is very strongly supported by Apple. But both projects will need to attract other contributors to survive. I think this will be a decisive factor.
The great risk for LLVM/Clang is that Apple loses interest and reduces its contribution (or limits it to its own platform and interests) before LLVM/Clang can attract a sufficiently diverse developer base.
On the other hand, the risk for GCC is that Google, Novell or RedHat decide to increase the support to LLVM/Clang. Given the current "crisis", this will mean an effective reallocation of resources, and hence, hurt GCC's development.
I hope LWN wasn't planning to write an article about this, otherwise, hum, sorry...
Posted Oct 10, 2010 15:36 UTC (Sun)
by corbet (editor, #1)
[Link]
Seriously, though, I sure hope people never hold back on comments because they think we might be writing something similar.
Posted Oct 10, 2010 23:16 UTC (Sun)
by daglwn (guest, #65432)
[Link] (9 responses)
Dragonegg could become an important player if distributions start picking it up. It would allow some of the best parts of LLVM to be integrated into gcc in a straightforward manner.
What's unfortunate is all of the license silliness going on. libc++ would have been better implemented as part of libstdc++ but Apple wasn't going to let that happen. A *BSD switch to LLVM is an unnecessary disruption if done primarily for licensing reasons.
A strong motivation for LLVM is its modularity. LLDB promises to be a tremendous step forward for free software if people can get past the GPL-only blinders. LLVM's MC project could do the same, though that's less clear to me. I certainly can imagine cool applications of it.
As for development community, LLVM has enough people behind it to ensure progress if Apple decides to drop out. But that's not going to happen any time soon. We will probably see more closed development from Apple going forward, however. I think there's a big decision coming for LLVM about how to structure governance. It works "ok" as is but even now some cracks are showing. If/when Apple does move to more closed development I think we're going see some tension and hopefully resolution of various questions and concerns.
Posted Oct 11, 2010 1:57 UTC (Mon)
by mlopezibanez (guest, #66088)
[Link] (8 responses)
* The GCC FE maintainers won't accept Clang and won't work on integrating it in GCC. See http://gcc.gnu.org/ml/gcc/2010-09/msg00326.html.
* Some GCC middle-end maintainers have expressed interest in Clang but they didn't accept LLVM when it was offered to the FSF (did you know that?). They won't accept Dragonegg either because it effectively means replacing the middle-end of GCC.
* And why the LLVM people will care about GCC at all if they consider it inferior? Now that Clang supports C++, dragonegg's only purpose is to give LLVM access to the other GCC FEs.
* LLVM is effectively replacing the whole GNU toolchain. The time for integration is well past.
So the projects won't integrate. Can they co-exist?
Probably yes. The license may not be an issue for you, but it is certainly an issue for many, many people that won't contribute (or even use) LLVM because of it. It is not clear at all that GNU/Linux distros will switch to LLVM, even if LLVM reached feature parity with GCC, was able to compile the kernel, produced faster coder, and was ported to more architectures. The main reason will be the license.
On the other hand, both projects rely on corporate support (almost all devs are paid), and they will suffer without it. Despite the size of these projects, the number of devs is relatively low. If Apple decided that LLVM is good enough for them and they don't care about compiling the Linux kernel, and put the devs to work on something else, LLVM will never catch with GCC, and will never be a real alternative. Similarly, if, let's say, Novell and Google decided to reallocate some devs to support LLVM, this will rapidly reduce the current advantage of GCC over LLVM and further slow down GCC's development.
I am really curious how this will evolve, since we are just at the beginning. LLVM is not yet complete enough to be a viable alternative, but the potential and the progress are amazing and we know that a full-blown switch may happen overnight a la XFree86. On the other hand, GCC is not going to disappear any time soon, it is still much superior in some aspects, and it is slowly addressing some of its shortcomings.
But at the end, it will be an either-or choice.
Posted Oct 11, 2010 4:07 UTC (Mon)
by daglwn (guest, #65432)
[Link] (6 responses)
Dragonegg is a no-brainer. The gcc plugin infrastructure means they can't stop it. Much compiler research is rapidly shifting to the LLVM world. Dragonegg is the perfect tool for this, meaning that at least in some areas, gcc will be playing catch-up in a few years. gcc has a big advantage in the number of targets it supports. Dragonegg leverages that.
The frontend is trickier but if the gcc devs refuse to allow it to be integrated (alongside the existing frontend initially) then I think we may see a mass shift toward Clang/LLVM. User experience is very important and Joseph Myers is missing something big. With the advent of many-core and massive threading via GPUs and the like, the compiler landscape is rapidly shifting. We need much smarter, friendlier compilers. The smarts are the relatively easy part. User friendliness is a big deal and the harder problem to solve. Clang has a head start there.
One can't incrementally improve the existing gcc frontend to be as good about error-reporting as Clang. That capability is designed in from the ground up. Incremental change there is going to take years at best and by that point it will be too late.
Right now, Clang is ahead in the user experience department but that will change quickly if the project can't figure out how to integrate support for OpenMP, UPC and the like. And not just integrate it, but DRIVE it.
Posted Oct 11, 2010 8:25 UTC (Mon)
by nix (subscriber, #2304)
[Link] (5 responses)
LLVM is a really nifty project, granted, but you haven't addressed *any* of the points Manuel just made. It might be a 'distribution-led thing', but do you really want *compiler* fragmentation between distros? I doubt the distros do either, and it'll be a long time before RH in particular switches away from GCC, because of the deep pool of GCC expertise at RH (originally thanks to the Cygnus acquisition, but they've kept it alive since then).
Oh, and one *can* incremnetally improve the existing GCC frontend to be as good at error-reporting as clang. Major incremental error-reporting improvements have happened in GCC already (e.g. column-number reporting, only turned off to avoid confusing interface tools IIRC).
And, uh, sorry to burst your bubble but user friendliness is not by *any* stretch of the imagination the hardest problem in compiler development. Really, really not.
Posted Oct 11, 2010 13:15 UTC (Mon)
by daglwn (guest, #65432)
[Link] (4 responses)
I don't claim to know what gcc developers think. I'm simply going on the basis of the links posted and various threads I've read.
Column-number reporting is a really simple change. Much harder is knowing what to report, when to keep going and when to stop. AFAIK gcc has never really improved that for C++. Minor error formatting changes don't really improve the situation.
As far as the "hardest" problem goes, it depends on how one defines "hard." Certainly the aliasing/dependence analysis problem is one of the hardest to tackle in terms of analyzing program semantics. But the problem is well understood and various solutions of various complexity and cost are known. Diagnostics and error-reporting is a much less formalized thing. There's much less general understanding of how to do it well. That's what I meant by "hard." It's harder to come up with creative new solutions than to implement well-known ones. The fact that no compiler I know of really does it well (though QOI varies tremendously) is testament to its difficulty.
I'm not trying to knock gcc, just expressing my own observations over years of compiler development. Clang/LLVM has its own deficiencies which should be addressed and I've touched on some of them. But I believe the Clang/LLVM development path is clearer and much more accessible, meaning that it has a better chance (for now) of rapid improvement.
Posted Oct 11, 2010 14:19 UTC (Mon)
by mlopezibanez (guest, #66088)
[Link] (2 responses)
But you are missing some important points:
* Licenses are important to many.
* LLVM is not near ready to be used as the compiler of choice of any Linux distro. It is a matter of time you say, yes, probably, but who will be working on this? Apple?
* Diagnostics are important for users and for Apple, but not for the employers of GCC maintainers, not for the customers of the employers, and not enough for any critical mass of volunteer developers to step up and improve the situation in GCC during the last two decades.
You are right on a few things:
* The potential of the LLVM project is immense and the pace of development incredible, so my understanding is that the competition has not really even started yet.
* The competition from LLVM is *very* good for GCC. and the achievements of LLVM have been already used as arguments by GCC maintainers when dealing with the FSF.
I wish LLVM lowered the level of fanaticism, FSF/GPL/GNU-hating, and hype to be able to convince GCC maintainers that there are ways to improve GCC. This is a useful comparison: http://people.redhat.com/bkoz/diagnostics/diagnostics.html
This is just a well-dressed lie: "LLVM is fast. It compiles code twice as quickly as GCC, yet produces final applications that also run faster." http://developer.apple.com/technologies/tools/whats-new.h...
My hope is that a fair and healthy competition will convince GCC maintainers that change is needed, that a different GCC is possible, and it will attract new GCC devs pushing for such changes. The main threat to GCC's future is not LLVM, it is its own inertia.
Posted Oct 11, 2010 14:57 UTC (Mon)
by daglwn (guest, #65432)
[Link]
My argument is that we're at a technological inflection point. The rules have changed. So past history is not a predictor of future results. Once people start compiling programs that use thousands or millions of threads, they will want good diagnostics. Not just about syntax errors but about why this or that piece of code won't parallelize. It's not just the compiler that will have to change. We're going to need an entirely new programming ecosystem, one able to analyze runtime behavior and feed it back to the user to improve the program. I agree with you on this. It's one of the blind spots that needs to be corrected. Also agreed. I think there's parity right now. LLVM's focus really isn't code quality and that's ok for now. Exactly right. LLVM is the agent exposing that problem, which is why it doesn't have to be either-or. Neither project need incorporate code from the other (and indeed the code can only flow one way currently) but I think there's something to be gained from cooperation, much more than from "healthy competition."
Posted Oct 11, 2010 15:04 UTC (Mon)
by daglwn (guest, #65432)
[Link]
For time time being, yes, along with plenty of non-Apple people. There's a bug tracking it. I believe that LLVM has an Apple problem. There's a widespread perception out there that Apple controls everything that happens with LLVM. There are lots of non-Apple people working on LLVM and their work is not in any way dictated by Apple. However, there are certain problems with the way Apple controls things. Foremost among them is keeping some bugs in an internal Apple bug database, with only cryptic references to rdar//this-or-that in commit messages. This opaqueness is a big problem and it's not just limited to the bug database In order to grow more quickly, LLVM is going to have to shed this perception. I don't know how that will happen but I think it will involve some kind of reorganization/formalization of decision-making bodies. LLVM is approaching the point where the project will need more formal processes than it has now. I believe that's the big hurdle for LLVM and it's a difficult one.
Posted Oct 11, 2010 22:47 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Oct 11, 2010 14:28 UTC (Mon)
by andrel (guest, #5166)
[Link]
There goes our entire editorial schedule, sheesh. Now we'll have to toss that beautiful compiler article and do another feature on Twitter.
LLVM 2.8 is available
LLVM 2.8 is available
LLVM 2.8 is available
LLVM 2.8 is available
LLVM 2.8 is available
LLVM 2.8 is available
LLVM 2.8 is available
LLVM 2.8 is available
Diagnostics are important for users and for Apple, but not for the employers of GCC maintainers, not for the customers of the employers, and not enough for any critical mass of volunteer developers to step up and improve the situation in GCC during the last two decades.
I wish LLVM lowered the level of fanaticism, FSF/GPL/GNU-hating
This is just a well-dressed lie: "LLVM is fast. It compiles code twice as quickly as GCC, yet produces final applications that also run faster
The main threat to GCC's future is not LLVM, it is its own inertia.
LLVM 2.8 is available
LLVM is not near ready to be used as the compiler of choice of any Linux distro. It is a matter of time you say, yes, probably, but who will be working on this? Apple?
LLVM 2.8 is available
LLVM 2.8 is available