
ErLLVM: LLVM backend for high performance Erlang - mseri
http://erllvm.softlab.ntua.gr
======
asb
This backend has been merged in to the Erlang/OTP master branch:
[https://github.com/erlang/otp/commit/9d46875b53ffb21bc55aec4...](https://github.com/erlang/otp/commit/9d46875b53ffb21bc55aec4a2c76472133ea5d1c)

If you're interested in LLVM you might want to subscribe to LLVM Weekly (which
I author). [http://llvmweekly.org/issue/12](http://llvmweekly.org/issue/12)

~~~
dochtman
LLVM Weekly is awesome, thanks for doing that!

------
delinka
I think I need some guidance in understanding this project. The typical LLVM-
base compiler 'stack' looks like this:

    
    
      [Front-end] -> [LLVM AST] -> [Back-end]
    

Where the front end compiles your language of choice to LLVM's AST format, and
a back-end translates AST to machine code. All the really awesome code
optimization stuff happens at the AST level before the back-end gets involved.

So is ErLLVM a back-end that emits Erlang (such that any front-end language
can be translated to Erlang)? Or is it an LLVM _front-end_ that compiles
Erlang to LLVM AST? An in the latter case, if LLVM already targets ARM, why
does ErLLVM need to do work related to ARM?

~~~
masklinn
> Or is it an LLVM front-end that compiles Erlang to LLVM AST?

This, kind-of. It's a new HiPE[0] backend. See [1] for how LLVM integrates
into the existing Erlang pipeline.

[0]
[http://www.it.uu.se/research/group/hipe/](http://www.it.uu.se/research/group/hipe/)

[1]
[http://erllvm.softlab.ntua.gr/documentation/design/pipeline/](http://erllvm.softlab.ntua.gr/documentation/design/pipeline/)

------
chrisfarms
Can't remember which talk it was from but I remember enjoying Joe Armstrong
speaking about the importance of a language being "correct" rather than fast:

    
    
        The performance problem is solved. You just wait 20 years.

~~~
alexchamberlain
Doesn't work any more... Now, we need people to invent decent compilers and
languages.

~~~
duaneb
Nonsense, it still works. Hardware prices are still falling. People aren't
writing web apps without garbage collection. Performance/$ is still going to
rise.

~~~
kalleboo
> Performance/$ is still going to rise

But is performance/core also going to keep rising? Or do we need smart
compilers/languages to make use of all the cheap cores?

~~~
duaneb
I mean, this conversation has been around for easily 10 years. We live in a
world where we already have to do this—look at all the progress in the last
decade on the prevalence of futures, async i/o, and channels/queues/whatever.
Memory bandwidth and latency has proven to be far more of a performance drag
that has improved far slower—the likely areas that will lead to performance
problems will be in areas other than single-core clock speed.

~~~
eternalban
Well, that -- the Memory bottleneck -- is precisely why we need a rethink of
platforms and tool chains.

Languages will provide the semantics (in context of memory hierarchy) of data
locality, and compilers that optimize for that.

[nop edit]

~~~
drkrab
As it turns out, Erlang is already providing much better memory locality than
your average language. Each process runs in a contiguous memory area
(heap+stack) which fits perfectly with a many-core world.

------
thinkpad20
"Currently, ErLLVM supports the AMD64 and x86 architectures. There is also
some ongoing work for ARM."

Isn't the whole idea of LLVM that you don't need to support individual
architectures, because LLVM can be separately compiled into whatever
architecture you need?

~~~
masklinn
Here, LLVM is not used to output an independent and self-contained binary
(that would hardly make sense). It's used as a backend for HiPE's native code
generation[0], and it's possible that the rest of HiPE (or part of the
integration itself[1]) is not quite ARM compatible (especially ARM64)

[0]
[http://erllvm.softlab.ntua.gr/documentation/design/pipeline/](http://erllvm.softlab.ntua.gr/documentation/design/pipeline/)

[1] "The linearized RTL code is translated to LLVM Assembly. […] After the
translation is completed, the LLVM code is printed to a file and the LLVM
toolchain is invoked in order to produce an object file. […] The
lib/hipe/llvm/elf64_format.erl module is responsible for extracting the binary
code and all other necessary information from the object file."

------
cryptolect
I thought Erlang was already fast? Are there any before/after benchmarks
available post-LLVM?

~~~
netcraft
The only exposure I have had with erlang was with rabbitmq and it was blazing
fast - I wonder if this would affect it much?

~~~
jlouis
There are some parts of rabbitmq which is highly CPU-bound. This will probably
help RabbitMQ in those areas.

------
jasonlotito
Hopefully someone with more knowledge of all the moving parts can answer this:
would this benefit Elixir in any way, considering it also compiles down to
Beam or is it specifically for Erlang? I ask this because the documentation
makes reference to first compiling to beam, and then compiling modules using
LLVM.

~~~
rdtsc
I believe this will benefit Elixir as well. LLVM code would work on the BEAM
bytecode (via the HiPE backend). You can already use a HiPE enabled erl
interpreter with Elixir today to this won't change.

~~~
jlouis
You would be correct, sir :)

