GCC Receives ACM’s 2014 Programming Languages Software Award
rhelblog.redhat.com
rhelblog.redhat.com
I think the past several years have been a rather low point for GCC. It hasn't been as bad as the 1996-1999 period of stagnation and strife, mind you, but it hasn't been particularly good, either.
LLVM and Clang have offered the first real competition that GCC has had to face in a long time. We've actually seen Clang be the leader in some cases, offering improvements that have then been implemented in GCC sometime later (like better diagnostics, colored diagnostic messages, the use of C++, etc., etc.).
Meanwhile, we haven't really seen anything truly compelling come out of GCC camp. Recent versions of have offered some optimization improvements, but nothing earth-shattering (in a good way). Its C++11 and C++14 support is quite good, but so is Clang's. The Go front end might be the most interesting development, but Go isn't a particularly interesting language, and GCC's version lags that of the main Go implementation.
I could see an award perhaps being deserved after successfully coming back from a period of stagnation like we've seen, after delivering several positive and revolutionary changes in a short period of time. But small, incremental improvements, or merely catching up with competitors, doesn't seem all that remarkable.
With optimizations disabled, I tend to see a 30% to 40% reduction in compilation time when using LLVM/Clang instead of recent releases of GCC. That has a noticeable impact on the time it takes to develop code, especially when dealing with large systems with lots of C++ code.
So at least how I use it, I haven't really seen LLVM/Clang "catch up" in a long time. They've been delivering me better compiler performance than GCC, better diagnostic messages than GCC, suitable optimization, and very good C++11 and C++14 features, without depriving me of functionality that I find useful.
For C code mostly found that LLVM/Clang at compiles faster than GCC at O2 but while producing code which is considerably slower. Setting GCC to O1 usually ends up producing code which is competitive with LLVM/Clang in performance but compiles faster.
When talking about compile speed, it's easy to ignore runtime performance and let a compiler have an unfair advantage just from some difference in optimization to O level.
If I need better optimization of binaries that I'm preparing for release, then I can always use GCC or ICC instead, for a single compilation.
That way, LLVM/Clang save me a huge amount of time on a daily basis. Then on the relatively rare occasion when I need better optimization, I'm only subjected to GCC's noticeably worse performance for a short period of time.
Then turn down optimization in GCC. The point I was trying to make is that you're likely making an apples/oranges comparison. With defaults, yes, GCC compiles slower but also produces faster binaries, you can turn the optimization level down and the results are more comparable in both dimensions. (YMMV depending on the project)
Here, let me quote it for you: "With optimizations disabled, I tend to see a 30% to 40% reduction in compilation time when using LLVM/Clang instead of recent releases of GCC."
Do you see the first part? You know, the part that goes "With optimizations disabled"? Do you see it?
I'm talking about running both LLVM/Clang and GCC with optimizations disabled. -O0. Even with optimizations disabled, GCC is still significantly slower than LLVM/Clang on all of the various C++ code bases that I have tried it with, and especially those that I work with on a daily basis.
How are we supposed to have a discussion if you aren't actually reading what was written earlier?
Apparently not. I missed it in part because it's completely at odds with my experience. Interesting, may be some codebase difference. On a codebase I work on daily -O0 gcc 4.8.2 is about 5x faster than -O0 clang (3.5-198803), 6.078 seconds vs 33.069 seconds, no cacche or anything obviously in the way.
That can certainly be said about gcc. It's used and shipped by hundreds of vendors as the main toolchain for their SDKs, processors, SoCs and operating systems (Not just Linux, but BSDs, numerous embedded operating systems including vxWorks and QNX). Has been one of the underlying pillars of the open source ecosystem. Certainly has had a lasting global use and importance.
I just see its impact as diminishing these days. An award like this would have been more deserved in the mid-2000s, after it had successfully recovered from the struggles of the late 1990s, and when we did see significant improvements with the releases of GCC 3.x and 4.x.
It's hard to tell from that list if the SIGPLAN award will end up being more retrospectively oriented, but a lot of ACM awards are. For example the Software Systems award does sometimes go to contemporary systems (LLVM won in 2012), but also some that are hard to justify except based on retrospective impact (Make won in 2003, Eiffel in 2006): http://awards.acm.org/software_system/year.cfm
I think in practice the decision process often ends up being: did anything come up in the past year or two that's really great? If so, give them the award. If not, look back for something older and influential that hasn't won yet.
Ehm, auto-vectorization?
https://gcc.gnu.org/projects/tree-ssa/vectorization.html
Very compelling if you are working in numerical computing. LLVM has only added auto-vectorization recently:
http://blog.llvm.org/2013/05/llvm-33-vectorization-improveme...
Yes, there are some features that Clang doesn't implement at the moment or never will (GCC has some really bizarre extensions and is sometimes less strict), but there is also a great amount caused by bad code.
I can't come up with a better alternative, though.
The top result, which is the most significant, is pretty much irrelevant, for example. It's limited to Haskell-related packages. Most Debian users have absolutely no reason to use those packages.
After that, we start running into rather obscure options that only GCC supports, or bad code that GCC accepts, or code that's just bad in general, or extremely obscure packages that very few people would ever consider using. These don't indicate a problem with LLVM or Clang.
The fact that FreeBSD managed to very successfully switch to Clang for compiling the kernel and base system, and the fact that it's very widely used on OS X, suggests to me that LLVM and Clang are more than robust enough for everyday use.