4 ms·

I really wish someone like Mike Pall (of LuaJIT fame) would work on BEAM to make it computationally as fast as Go on raw performance.

siscia 8y ago
The architecture of the BEAM is quite complex. I don't believe you could reach the same raw performance that you have with go. However it is an unfair comparison, BEAM processes do much more than coroutines.
macintux 8y ago
Erlang, I think, is crippled out of the box wrt performance by its emphasis on immutable data, live troubleshooting, small processes with lots of messaging, etc. These are the things that make it a brilliant language for use cases where it's well-suited. Not every language has to be a kitchen sink language like Java, thankfully. I like opinionated languages with well-defined strengths and weaknesses.
jlouis 8y ago
The recent Erlang release (21) changed a lot of the internal interpreter structure with a nod in Mike Pall's direction. Just by shortening the typical opcode size down, they gained 20% speed boost. And the BEAM is a pretty good interpreter anyway. JITing the beast has been a want for a while, but there are also other paths taken right now which can provide speed boosts, among other a translation of the compiler to use SSA-representations.
notriddle 8y ago
The BEAM is already much more performant than, for example, the Ruby reference implementation. And look at what people have managed to build with Ruby!
- jashmatthews 8y ago
  Erlang 19 is only 10% faster than CRuby 2.3 on a simple factorial bench. Web throughput is even closer as lots of it is C extensions. I haven't made the comparison myself for a while but I suspect it's still very close.
rozap 8y ago
I don't think it's going to happen, due to the stack+heap per process and lack of shared memory (ok yea ETS sure) which you need for fault tolerance, necessarily requiring more copying than conventional languages. I think there are different tradeoffs that make good CPU bound performance (like Java or Go) on BEAM pretty much impossible.

siscia 8y ago

The architecture of the BEAM is quite complex. I don't believe you could reach the same raw performance that you have with go. However it is an unfair comparison, BEAM processes do much more than coroutines.

macintux 8y ago

Erlang, I think, is crippled out of the box wrt performance by its emphasis on immutable data, live troubleshooting, small processes with lots of messaging, etc. These are the things that make it a brilliant language for use cases where it's well-suited. Not every language has to be a kitchen sink language like Java, thankfully. I like opinionated languages with well-defined strengths and weaknesses.

jlouis 8y ago

The recent Erlang release (21) changed a lot of the internal interpreter structure with a nod in Mike Pall's direction. Just by shortening the typical opcode size down, they gained 20% speed boost. And the BEAM is a pretty good interpreter anyway. JITing the beast has been a want for a while, but there are also other paths taken right now which can provide speed boosts, among other a translation of the compiler to use SSA-representations.

notriddle 8y ago

The BEAM is already much more performant than, for example, the Ruby reference implementation. And look at what people have managed to build with Ruby!

jashmatthews 8y ago
Erlang 19 is only 10% faster than CRuby 2.3 on a simple factorial bench. Web throughput is even closer as lots of it is C extensions. I haven't made the comparison myself for a while but I suspect it's still very close.

rozap 8y ago

I don't think it's going to happen, due to the stack+heap per process and lack of shared memory (ok yea ETS sure) which you need for fault tolerance, necessarily requiring more copying than conventional languages. I think there are different tradeoffs that make good CPU bound performance (like Java or Go) on BEAM pretty much impossible.