sutton037

Many people, including the developers of Haskell (see here ) and OCaml (see here ) compilers, have been quick to dismiss the shadow stack algorithm for performance reasons. Despite these concerns, we chose to use a shadow stack in HLVM for several reasons: GC performance is low on the list of priorities for HLVM. Shadow stacks are easy to implement entirely from within HLVM whereas conventional strategies entail injecting stack maps into stack frames on the normal stack and that requires low-level hacking with LLVM's experimental GC API in C++. Shadow stacks are easy to debug because they are just another data structure in the heap. HLVM provides typed nulls and the ability to read array lengths or type constructor tags without an indirection. This requires the use of an unconventional struct-based reference type that is incompatible with LLVM's current GC API that can only handle individual pointers. Consequently, it is interesting to use HLVM to measure just how expensive it...

Donald Bruce Stewart recently published an in-depth analysis of Hackage's download statistics that shows many interesting characteristics: All of the 1,200 Haskell softwares on Hackage combined have been downloaded as many times in total as a single OCaml program, MLDonkey , from Sourceforge (let alone OCaml's other popular software like FFTW and Unison ). Over half of the packages on Hackage have been downloaded under 300 times. Dependencies are multiply counted so these figures are a substantial over estimate. This confirms our suspicions that the few lines of real-world Haskell software ever written have been tested by only a handful of people . Perhaps Haskell will become more mainstream in the future but it seems to be quite a long way off today.

Alp Mestan has begun work on the first front-end for HLVM. This project has many important goals: Provide a high-level language that HLVM developers can write test code, benchmarks and garbage collectors in. Serve as a tutorial for the people porting existing compilers such as Moscow ML, NekoML and PolyML to HLVM. Track new features as they are added to HLVM, such as closures, parametric polymorphism, parallelism and so on. Alp intends to apply to Jane St. Capital to fund a summer project that will port the entire OCaml compiler to HLVM.

A quick update due to a surprise performance result for HLVM ! We knew that manipulating the shadow stack was a major slowdown in HLVM from the change in our benchmark results when the GC was first introduced a few weeks ago but we did not expect that a simple local optimization, unrolling, could go so far towards recovering performance. Moreover, this optimization was implemented in only a few lines of OCaml code. The following results prove that HLVM now produces substantially faster programs than ocamlopt for numerical tasks on x86: Interestingly, now that HLVM supports standalone compilation using LLVM's IR optimization passes as well as unoptimized JIT compilation, we see that LLVM's optimization passes only give small performance improvements in many cases and even substantially degrade performance on our 10-queens benchmark. This is a direct result of HLVM producing near optimal code directly (which greatly reduces compile times) and has eliminated our desire to add sup...

Someone recently published a blog article about the sizes of values in the Ruby and OCaml programming languages. This is also interesting in the context of HLVM because our high performance goals also require an efficient memory representation but our solution is quite different to OCaml's because HLVM is designed for numerical performance whereas OCaml was designed for symbolic performance. The following table lists the sizes of values of several different types in OCaml and HLVM on 32-bit architectures: Type OCaml HLVM unit 32 bits 32 bits bool 32 bits 8 bits int31 32 bits None int32 96 bits 32 bits int64 128 bits 64 bits float32 None 32 bits float64 128 bits 64 bits float * float 320 bits 128 bits Enumeration 32 bits 96 bits float64 array 64+64n bits 96+64n bits Note how HLVM uses the most memory efficient representations possible for ints, floating point numbers and tuples but uses less efficient representations for reference types such as arrays and variant types. A side-eff...

Our HLVM project is evolving rapidly and recently saw its first release with a working garbage collector. This has allowed us to make some performance measurements and, as we had hoped, the results are extremely compelling. The following graph illustrates the time taken to perform each of the benchmarks in the HLVM test suite on one of the 2.1GHz Opteron 2352 cores in an 8-core Dell PowerEdge: The individual benchmarks are: fib : The usual Fibonacci function. ffib : A floating-point version of the Fibonacci function. sieve : Sieve of Eratosthenes to find all of the primes under 10^8 and print the last one using a byte array. mandel : Mandelbrot rendering with float arithmetic. mandel2 : Mandelbrot rendering with abstracted complex arithmetic where complex numbers are pairs of floating point numbers. Array.fold : Initialize a 10^8-element float array and fold of a float * float pair over it. List.init/fold : Initialize a 10^6-element int list and fold over it (allocation intensive). 1...

We have made the first public release of our much anticipated High-Level Virtual Machine (HLVM) project. The complete source code is now available from the HLVM project page on the OCaml Forge via the subversion repository. HLVM makes extensive use of some features only recently added to LLVM and, consequently, requires a patched version of LLVM 2.4 or later. Even at this early stage, our performance results are extremely compelling. HLVM is already several times faster on a variety of benchmarks than some notably high-performance functional programming languages such as OCaml . HLVM is specifically designed for technical computing and we believe it will offer the best performance for numerical computing of any high-level language including easy-to-use support for parallelism. We also intend to provide extensive support for visualization using OpenGL and make HLVM a viable platform for both free and commercial software in the future. This open source project has been solely funded by ...