Hacker News Reader

Meanwhile, we haven't really seen anything truly compelling come out of GCC camp.

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...

"Awarded to an institution or individuals that have developed a software system with lasting influence".

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 never said that GCC hasn't been widely used, nor did I suggest that it isn't widely used today, or anything like that. Of course it has had a big impact.

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.

Well, they only instituted this particular award in 2010, which probably impacts the choices. The four winners have been LLVM (2010), GHC (2011), Jikes (2012), Coq (2013), and GCC (2014): http://www.sigplan.org/Awards/Software/Main

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.

While it has many advantages, clang still isn't as robust as gcc ( e.g. http://clang.debian.net/ ), and the code it produces can be slower ( e.g. http://openbenchmarking.org/result/1404144-KH-CLANG359076 ) I guess clang is still a few decades of testing and tuning behind gcc, though it's catching up fast.

I don't think those results really support the point that you're trying to make.

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.

I wouldn't use “robust” here. Just look at the errors types and the examples (below the table).

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.

Earth doesn't shatter that often either. Most of LLVM's blazing progress has been with things that it's catching up to GCC.

I've found LLVM/Clang's better performance when compiling C++ code, while still offering all of the functionality I need, to be a very significant win over GCC.

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.

> I've found LLVM/Clang's better performance when compiling C++ code,

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.

I'm talking about development time. I can use LLVM/Clang and develop significantly faster than I ever could using GCC. I'm not seeing there waiting as long for the C++ compiler to do its work.

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.

> I'm not seeing there waiting as long for the C++ compiler to do its work.

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)

Please actually read my earlier comment: https://news.ycombinator.com/item?id=8090097

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?

> Do you see it?

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.