If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Apple's LLVM 3.1 Clanging On Intel Sandy Bridge

04-02-2012, 10:50 AM

Phoronix: Apple's LLVM 3.1 Clanging On Intel Sandy Bridge

After delivering benchmarks in March showing the performance gains of GCC 4.7 on Intel's Sandy Bridge processors, here's a look at how the latest LLVM/Clang 3.1 compiler from Apple is shaping up for these latest Intel CPUs.

Oh, Apple's llvm. I wonder why some people from Debian do even bother to play with this? It's so slow. Btw. congratulations to freebsd devs for having enough courage to switch. You're no longer dependent on GPL licensed compiler and you must be really happy now.

Comment

That's what I keep hearing, and it's getting old. We know that it's a toy, that's why Michael and others like to play with it. Being a toy now does not preclude it from being a serious tool in the future.

Comment

Most of those benchmarks are only a little slower on LLVM. The OpenMP ones make GCC look way more impressive than it is, especially given that only a very few fringe packages even use OpenMP. When Clang supports that, those spectacular-looking gaps will close up. Future revisions of LLVM's optimizers will also close up the other smaller gaps.

The advantage of LLVM/Clang -- and the reason why Apple, Google, Facebook, and various other big companies all pay engineers to work on it -- goes far, far beyond a few percentage points of optimization.

Even as a game developer, I couldn't care less about GCC's tiny lead. Hell, most of us put up with Visual C++, which is hardly competitive with GCC anymore in terms of raw optimization. At the end of the day, the tools we use to develop the software vastly outweigh the compiler itself. The tools that Clang facilitates lets development go that much faster, with vastly superior static analysis, IDE support, reflection support, code refactoring, scripting binding, etc., not to mention the LLDB tool. The tools that Microsoft built for Visual C++, especially its debugging tools and IDE, are still best in class on Windows, especially when paired with Visual Assist X -- but a Clang-based IDE can still do far better. The tools that exist for GCC are Vim and ctags, and a debugger that is awkward to use because it's near impossible to integrate nicely with a graphical editor. The sooner GCC stops being the official compiler for half the console systems, the happier I'll be.

Comment

Most of those benchmarks are only a little slower on LLVM. The OpenMP ones make GCC look way more impressive than it is, especially given that only a very few fringe packages even use OpenMP. When Clang supports that, those spectacular-looking gaps will close up. Future revisions of LLVM's optimizers will also close up the other smaller gaps.

When llvm will catch up in this case GCC will be far ahead of it.

The advantage of LLVM/Clang -- and the reason why Apple, Google, Facebook, and various other big companies all pay engineers to work on it -- goes far, far beyond a few percentage points of optimization.

Close minded trolling as usual. How is this advantage while there are many more people and companies paying its engineers to work on GCC? Red Hat, AMD, Intel, Google, IBM. The reason why apple support its crappy llvm is just because they cannot ship the latest and greatest GCC. We're not talking about few percentage points of optimization if you didn't notice, but even about hundred points.

Even as a game developer, I couldn't care less about GCC's tiny lead.

Troll alert. GCC is not only far more popular, but much faster - even few times. How to speak with trolls?

The sooner GCC stops being the official compiler for half the console systems, the happier I'll be.

Comment

Future revisions of LLVM's optimizers will also close up the other smaller gaps.

LLVM/Clang will improve but so will GCC (as can be shown here in the difference between GCC 4.6 and 4.7), there's no certainty that LLVM will ever 'catch up'. On the other hand it could end up passing GCC in optimization, we simply don't know. What we do know is that GCC currently generates faster code than Clang/LLVM, and it has been the case for as long as I've been benchmarking them and I've seen no indication of Clang/LLVM closing the gap.

The advantage of LLVM/Clang -- and the reason why Apple, Google, Facebook, and various other big companies all pay engineers to work on it -- goes far, far beyond a few percentage points of optimization.

The company name dropping doesn't really work in LLVM/Clang's favour as there's certainly more corporate paid developers for GCC with Red Hat, IBM, Google, CodeSourcery, Suse amongst others. LLVM/Clang is primarily a one man (corporation) show. Also when it comes to GCC, the code enhancements makes it back to the project due to the licence which is not necessarily the case with LLVM. Given how 'intellectual property!' is the new corporate battlecry I see an increasing chance of companies not contributing back 'unless they have to'. Also I have little to no trust in Apple when it comes to not keeping certain LLVM/Clang enhancements proprietary as we go along. Also, given that Apple stands for the vast majority of Clang/LLVM development it very much mirrors Apple's particular needs (ObjC, C, C++) which may turn out to be quite limiting.

Well the 'tiny' lead isn't that 'tiny' actually, particularly when using advanced optimizations like PGO where I can get around 20% increased performance compared to Clang/LLVM.

As for tools and integration, LLVM offers much better possibilities here obviously given how modular it is (although GCC is improving in this area aswell), still the only solution I know of which integrates Clang/LLVM is XCode which is proprietary as per Apple's lock-in strategy and thus only available on OSX.

I think LLVM/Clang is a great asset to the foss ecosystem and in particular it offers great competition to GCC. Still, even though you wish it wasn't so, GCC remains the de facto open source compiler toolchain and I don't see that changing anytime soon. It supports more architectures, more languages, has a higher level of compability and it generates faster code. Personally I will never return to the proprietary toolchains and therefore GCC remains my primary compiler since I know it and all it's enhancements will remain free open source. LLVM/Clang is really promising and it's JIT framework is a great gift to the open source ecosystem but I can't shake the fear that LLVM could turn into a base for a proprietary plugin/frontend/backend jungle with little code being contributed back to the main project. I hope I'm wrong though.

Either way I look forward to using both these compilers interchangeably in the future as I am now while taking advantage of the enhancements made to each.

Comment

I guess I fall somewhere between kraftman and XorEaxEax:
Some of the debugging/... stuff is far better with Clang/LLVM; that alone makes it useful.
Also, GCC gets some of its speed by doing optimzations that never should happen (for example, one time there was a "security bug" in the kernel: GCC optimized out a null pointer check)
On the other hand, it's Objective C (IIRC), it's Apple, it's slower, it can't build a working kernel...
Leave it for debugging stuff; I don't want that on my system (though you'd better set CFLAGS right for GCC).
And I don't want a toolchain depending on anything Apple.

Comment

I guess I fall somewhere between kraftman and XorEaxEax:
Some of the debugging/... stuff is far better with Clang/LLVM; that alone makes it useful.
Also, GCC gets some of its speed by doing optimzations that never should happen (for example, one time there was a "security bug" in the kernel: GCC optimized out a null pointer check)
On the other hand, it's Objective C (IIRC), it's Apple, it's slower, it can't build a working kernel...
Leave it for debugging stuff; I don't want that on my system (though you'd better set CFLAGS right for GCC).
And I don't want a toolchain depending on anything Apple.

I have similar opinion like you. I can understand Clang/llvm is useful in some cases, but overall GCC is far ahead of it. When comes to Linux kernel you will be much safer with GCC than Clang/llvm, because GCC is much more widely tested.