Linked by Thom Holwerda on Sat 29th Sep 2007 21:26 UTC, submitted by Chris Lattner
General Development The LLVM Project recently released a new version of their compiler, optimizer and code generators. LLVM includes a drop-in GCC-compatible C/C++ and ObjC compiler, mature optimization technology (including cross file/whole program optimization), and a highly optimizing code generator. For people who enjoy hacking on compilers and runtimes, LLVM provides libraries for implementing custom optimizers and code generators including JIT compiler support. This release is the first to provide beta GCC 4.2 compatibility as well as the new "clang" C/ObjC front-end, which provides capabilities to build source-to-source translators and many other tools.
Thread beginning with comment 275329
To read all comments associated with this story, please click here.
Why is it used so little in pratice?
by krausest on Sun 30th Sep 2007 09:10 UTC
Member since:

Does anyone have a clue why it is used so litte in practise?
Why doesn't Mono use it as its JIT or some Java or Ruby implementation? Somehow it would seem very natural and clever to use a good optimizing JIT instead of inventing and maintaining your own less optimizing one (this is IMO particularly true for mono). But I don't know any OS project (except PyPy) that uses it and the list on isn't too impressive.

Reply Score: 1

Philippe Mougin Member since:

The reason it is used so little in practice is that it is relatively new technology. I expect to see a growing number of usages in the future.

Reply Parent Score: 4

tyrione Member since:

Ask that question again, after XCode 3.0 and Leopard are released.

Reply Parent Score: 2

lupus Member since:

I don't know about other projects (I guess if a new project was started right now that needed an execution engine, they should consider llvm), but I can tell you why Mono doesn't use llvm.

First when Mono started writing its own JIT llvm was very immature (we're talking about 6 years ago): it is now mature as a compiler, but still very much unproven as a JIT.

Second, Mono supports more architectures than llvm and has done so for several years, so unless llvm catches on, we're not going to lose supported architectures.

Third, llvm is HUGE: just the x86 specific code (in an optimized build) is as large as the whole Mono runtime (which includes 500 KB of locale data). This makes it unsuitable for the environments where Mono is already used, like embedded devices. The bloat factor translates also to runtime memory usage and JIT compilation speed. While llvm is definitely faster than gcc, that doesn't say anything when you need to JIT code as fast as possible (and when you need to load 2 MB of code in the cache just to jit a single method it starts to drag everything down, not including the data structures needed by the JIT process itself).

Then there are various other reasons, like the tight control the Mono runtime needs on some generated code (the llvm exception handling mechanisms are inadequate for a full featured runtime like Mono), the integration with the GC (llvm has some embryonal support for this),
the need to control runtime behaviour precisely vs memory and stack usage (the amount of stack space the JIT can use is small and it needs to be deterministically fixed: using llvm here would need having a black box with not control on it), some low level details that I explained some time ago in a posting to lamba the ultimate that you might want to check.

Overall, for Mono to switch to llvm, a lot of work would be needed: implementing all the missing features in llvm, de-bloating it, writing the ports for the missing architectures and finally writing the backend to target llvm inside Mono. This is easily 2 years of work just to get something working correctly (and some things would be still suboptimal, it's hard to debloat the x86 support code from 1.5MB as it is in llvm to the 100KB it is in Mono). In the same amount of time we can add more architectures to the supported list or write more optimizations that are suitable for a JIT compiler.

Reply Parent Score: 4

SamuraiCrow Member since:

The reason that Python and Ruby don't use LLVM currently is that their runtime requires additional capabilities that LLVM doesn't supply as a low-level platform. See for details about its sister project High-Level Virtual Machine.

Reply Parent Score: 3