Code
You are probably correct that LLVM is generic as to front-end language. But LLVM is a hammer, where I need a screwdriver. --Rhys Weatherley, author of design of libjit
"How does Libjit compare to LLVM or GNU lightning?"
GNU lightning uses primitive code templates to generate machine code. It has been started in 2001. It does not provide register allocation, data-flow, and control-flow analysis based optimization, and has only one level of supported optimization. GNU lightning is less portable than libjit, and is more difficult in usage for software engineers. However, we think GNU lightning is a great project and both GNU lightning and libjit use the same philosophy.
LLVM seems to have been started as a "glorified" static compiler, which aims to replace the GNU Compiler Collection, focusing on generating, consuming, linking, and executing LLVM bytecode form. It has been started in 2000, and as of today it is technologically outdated. In 2003 LLVM has been released under a non-restrictive open source license.
Libjit has a large .NET and Java background and real world experience. Libjit is only a tool which aims to be the best free tool for just-in-time compilation. Libjit also contains its own Intermediate Representation (IR). Both LLVM IR and libjit IR are very close to each other. But libjit is in our opinion more general as a tool, and its intermediate representation and API include real world experience, which cutting edge researchers and best software engineers have had during development of ECMA-335 standard. And thereof indirectly it includes experience of those people who have developed ECMA-335 standard itself.
You may consider that libjit assumes another level of abstraction comparing to LLVM. For instance, instead of using LLVM intermediate representation to store programs, and reinventing the wheel - researchers and software engineers may introduce just-in-time compilation with libjit in any Virtual Machine implementation, domain specific programming language, or scripting language. For example, they may decide that they wish to use Common Intermediate Language and .NET to store programs. Thereof in this example it is assumed that rather any compiler of C#, C, C++, Java, Ruby, Python, Perl or any other compiler of source code produces middle level intermediate representation code into Common Intermediate Language. And only then a Common Intermediate Language Runtime implementation may utilize libjit and produce libjit intermediate representation (IR) and later produce from this IR machine code of the best quality for target hardware architecture. In other words, we think that computer scientists, researchers, software engineers when they use libjit have more choice and freedom for research than if they chose LLVM.
You may also be interested to read this mailing list discussion for more information. It is also available on this wiki page.
Experiments suggest that compilation time with LLVM is not suitable for a CLI VM such as Mono or GNU Portable.NET. The execution time for LLVM is high and not suitable for a JIT VM such as Mono or GNU Portable.NET. For instance, real world software and virtual machine implementations of CLI with libjit are known to have from x9 times to more than an x46 (forty-six times) faster dynamic compilation and execution time than software with LLVM such as VMKit. For instance, in our simple experiment, a simple C# program prints "Hello World!" with LLVM VMKit on our Debian GNU/Linux machine takes longer time than 3 seconds to print this small text string. We think compilation and thereof execution time within LLVM in complex real world VM applications probably has exponential function from size of dynamically compiled bytecode. Moreover, we think many algorithms used with LLVM have nondeterministic polynomial time complexity. On the other hand, compilation time with libjit with our project aims to have deterministic polynomial and even linear time complexity
Below are listed just a couple of all the features libjit supports for an implementation of just-in-time compilation in CLR:
The whole spectrum of ECMA 335 for CLR types and operations
Exception handling
Precise stack marking
Multiple custom call conventions
Fast just-in-time compilation
All these features are supported in libjit. Moreover, they have been well tested in GNU Portable.NET just-in-time compiler and used in industrial lasers by TRUMPF-Laser running GNU Portable.NET just-in-time compiler on Linux based soft real-time embedded system.
"So why everyone is so interested in LLVM? Shouldn't I do the same thing as everyone, should I?"
Core of LLVA design, which has nothing exceptional, but it has been advertised as super-sophisticated, is summarized in:
LLVA: A Low-level Virtual Instruction Set Architecture. Authors of this paper are Vikram Adve, Chris Lattner, Michael Brukman, Anand Shukla, Brian Gaeke, Computer Science Department University of Illinois at Urbana-Champaign.
It has been suggested that the new LLVM virtual machine instruction set is more general than Microsoft Common Intermediate Language, while in fact for a long time it is LLVM, which cannot easily support .NET. We think that LLVM developers did not want to admit mistakes of LLVM design and they applied and continue to apply more and more "patches" to the LLVM original instruction set and general theoretical core. Thereof, LLVM has become today a large collection of source code, virtually useless for many applications.
Firstly, it is because LLVM attracted software engineers into LLVM development with advertising. This advertising was used to interest people that they spend their own efforts into a specific thing that the company, which have used this capital wanted. To keep this thing simple for you, LLVM simply makes many of the best software engineers to work in their own free time, during weekends and evenings on LLVM source code, with paying as little money as possible. Secondly, LLVM "back-patch" its original design, with features which are really needed by the best software engineers. This means LLVM is not going anymore on a way of inventing new ideas, concepts, or building new inventions but it is most frequently copying these things, which are invented by other less known free software teams. For instance, this is what probably has happened before when features of libjit for just-in-time compilation have been loosely copied into LLVM. Thirdly, today LLVM design and instruction set continues to be "patched" this way.
You might be interested to ask questions and help developers of libjit and DotGNU Portable.NET just-in-time compiler on dotgnu-pnet@gnu.org mailing list.
Disclaimer: opinion presented on this article, is only a personal opinion of authors of this article.
This article has been written in May 2009
Last edition in August 2009
Below are a couple of screenshots from web site http://www.dotgnu.org:
