Erlang has a pretty good runtime, is fast at IO and is excellent at concurrency and reliability[-2]. Erlang itself is a "fairly slow" language: for imperative, CPU-bound and non-distributable[-1] workload you'll probably be closer to Python than to C.
However, note that this does not make Erlang faster, it's "just" an LLVM-based backend for HiPE.
HiPE (High Performance Erlang) is a >15 years old native compiler for Erlang (integrated to the standard distribution), but with Erlang being what it is (a dynamically typed functional language) it's best used as a form of "manual JIT" by profiling, extracting and compiling small subsets of the application: indiscriminately used on everything it will just generate boatloads of slow and useless "native" code which is just a deoptimization over standard BEAM (it will likely run at the same speed but eat more memory).
Part of HiPE's pipeline is the generation of native code itself, and the goal of this project (ultimately) is to replace existing hand-rolled codegen with LLVM (and benefit from its optimizations), thus simplifying maintenance by moving codegen to a third-party project. Most of HiPE (integration with the VM and generation of HiPE's own IR before codegen) remains, and according to [0] ErLLVM is slightly slower than existing HiPE backends at the moment.
If you want more info on ErLLVM, [0] has a bunch. For HiPE, [1] is the easy mode and [2] is hard mode
[-2] reliability is the original goal of Erlang, and contrary to most languages Erlang reached concurrency and distribution with reliability — rather than performances — in mind: it comes from telcos, where things have to keep running and a single machine means your stuff is down when (not if) the machine dies or crashes
[-1] Erlang's VM is fully multithreaded, by default.
Erlang has a pretty good runtime, is fast at IO and is excellent at concurrency and reliability[-2]. Erlang itself is a "fairly slow" language: for imperative, CPU-bound and non-distributable[-1] workload you'll probably be closer to Python than to C.
However, note that this does not make Erlang faster, it's "just" an LLVM-based backend for HiPE.
HiPE (High Performance Erlang) is a >15 years old native compiler for Erlang (integrated to the standard distribution), but with Erlang being what it is (a dynamically typed functional language) it's best used as a form of "manual JIT" by profiling, extracting and compiling small subsets of the application: indiscriminately used on everything it will just generate boatloads of slow and useless "native" code which is just a deoptimization over standard BEAM (it will likely run at the same speed but eat more memory).
Part of HiPE's pipeline is the generation of native code itself, and the goal of this project (ultimately) is to replace existing hand-rolled codegen with LLVM (and benefit from its optimizations), thus simplifying maintenance by moving codegen to a third-party project. Most of HiPE (integration with the VM and generation of HiPE's own IR before codegen) remains, and according to [0] ErLLVM is slightly slower than existing HiPE backends at the moment.
If you want more info on ErLLVM, [0] has a bunch. For HiPE, [1] is the easy mode and [2] is hard mode
[-2] reliability is the original goal of Erlang, and contrary to most languages Erlang reached concurrency and distribution with reliability — rather than performances — in mind: it comes from telcos, where things have to keep running and a single machine means your stuff is down when (not if) the machine dies or crashes
[-1] Erlang's VM is fully multithreaded, by default.
[0] http://www.erlang-factory.com/upload/presentations/519/erllv...
[1] http://www.slideshare.net/didip/high-performance-erlang [Comic Sans warning]
[2] http://user.it.uu.se/~pergu/papers/erlang03.pdf "All you wanted to know about the HiPE compiler"