5 ms·

Will Erlang/Elixir ever be able to attain the raw performance speed of Go? I'm not talking about concurrency, etc. Just raw computational speed.

qaq 10y ago
No, same as Go will never be able to match the unique characteristics of Erlang/OTP.
brightball 10y ago
The trade off is that a runaway process can't compromise everything else. The inherent performance difference comes from prescheduling vs cooperative scheduling. Prescheduling is slightly slower in exchange for consistency in the face of bad behavior. Add in the supervision tree structure and you end up trading "super fast" for "very fast, consistent and runs forever"
- tiffanyh 10y ago
  Is there any updates on the JIT work from 2014 to help speed up raw performance of Erlang? [1] http://www.erlang-factory.com/static/upload/media/1402914329562325jiteuc2014.pdf http://www.erlang-factory.com/static/upload/media/1402914329... [2] http://www.erlang-factory.com/euc2014/frej-drejhammar http://www.erlang-factory.com/euc2014/frej-drejhammar
  - di4na 10y ago
    Yes. The news is basically "still in the roadmap, we got a bit more of time budget from it" from the OTP team. It is not something you will see tomorrow, but it is a long standing thing in the roadmap for the team. Of course, if you want to sponsorise the work...
napsterbr 10y ago
If you need raw computational speed you shouldn't be dealing with erlang / elixir anyway. Rust and go would be a proper comparison here
- fooyc 10y ago
  Anything that's good at handling a lot of I/O or a lot of concurrent processes tends to become CPU bound as more load is given to it. It's not only about raw computational speed. Being good at concurrency means that you can handle more work, unless you consume too much CPU.
querulous 10y ago
probably not. on mostly io bound workloads they should perform similarly but a beam instruction is inherently more costly than a go instruction so on cpu bound workloads go should dominate however, if you're using elixir/erlang for something cpu bound you're probably doing something very wrong so this isn't a real world concern for most users
the_duke 10y ago
Go is statically typed and compiled, while Elixir/Erlang is dynamically typed and interpreted, so beating Go is unlikely. A plus for BEAM is that each process (aka Goroutine) has it's own, independent garbage collector that doesn't interfere with anything else. The point is, though, you don't use the BEAM for it's raw speed, but for it's great concurrency and fault tolerance. Go has decent concurrency, but it's not all roses and butterflies. Also all data is immutable in Erlang/Elixir which makes concurrency a lot easier.
- definiv 10y ago
  Elixir/Erlang is dynamically typed, but also compiled. At least in Elixir you can use .exs files (usually for tests or config) that are interpreted, but any .ex files are compiled.

qaq 10y ago

No, same as Go will never be able to match the unique characteristics of Erlang/OTP.

brightball 10y ago

The trade off is that a runaway process can't compromise everything else. The inherent performance difference comes from prescheduling vs cooperative scheduling. Prescheduling is slightly slower in exchange for consistency in the face of bad behavior. Add in the supervision tree structure and you end up trading "super fast" for "very fast, consistent and runs forever"

tiffanyh 10y ago
Is there any updates on the JIT work from 2014 to help speed up raw performance of Erlang? [1] http://www.erlang-factory.com/static/upload/media/1402914329562325jiteuc2014.pdf http://www.erlang-factory.com/static/upload/media/1402914329... [2] http://www.erlang-factory.com/euc2014/frej-drejhammar http://www.erlang-factory.com/euc2014/frej-drejhammar
- di4na 10y ago
  Yes. The news is basically "still in the roadmap, we got a bit more of time budget from it" from the OTP team. It is not something you will see tomorrow, but it is a long standing thing in the roadmap for the team. Of course, if you want to sponsorise the work...

napsterbr 10y ago

If you need raw computational speed you shouldn't be dealing with erlang / elixir anyway. Rust and go would be a proper comparison here

fooyc 10y ago
Anything that's good at handling a lot of I/O or a lot of concurrent processes tends to become CPU bound as more load is given to it. It's not only about raw computational speed. Being good at concurrency means that you can handle more work, unless you consume too much CPU.

querulous 10y ago

probably not. on mostly io bound workloads they should perform similarly but a beam instruction is inherently more costly than a go instruction so on cpu bound workloads go should dominate however, if you're using elixir/erlang for something cpu bound you're probably doing something very wrong so this isn't a real world concern for most users

the_duke 10y ago

Go is statically typed and compiled, while Elixir/Erlang is dynamically typed and interpreted, so beating Go is unlikely. A plus for BEAM is that each process (aka Goroutine) has it's own, independent garbage collector that doesn't interfere with anything else. The point is, though, you don't use the BEAM for it's raw speed, but for it's great concurrency and fault tolerance. Go has decent concurrency, but it's not all roses and butterflies. Also all data is immutable in Erlang/Elixir which makes concurrency a lot easier.

definiv 10y ago
Elixir/Erlang is dynamically typed, but also compiled. At least in Elixir you can use .exs files (usually for tests or config) that are interpreted, but any .ex files are compiled.