4 ms·

BEAM is phenomenal but one area that's still preventing people from adopting it is pure raw performance. People have to write NIFs far to often to obtain the r

BEAM is phenomenal but one area that's still preventing people from adopting it is pure raw performance. People have to write NIFs far to often to obtain the raw perf they need and in doing so, negates all the tremendous benefits of the BEAM. I hope more people push BEAMJIT development forward. http://www.erlang-factory.com/sfbay2017/lukas-larson.html http://www.erlang-factory.com/sfbay2017/lukas-larson.html Maybe Facebook would fund this effort given their huge BEAM investment from WhatsApp use.

qaq 8y ago
I think it depends on project domain. perf. is fine for most web apps for example.
- jerrycurly 8y ago
  >> "perf. is fine for most web apps for example." That same argument is made for Ruby and look at how many people leave due to slowness
  - skrebbel 8y ago
    Many of them leave to a BEAM language actually, for speed reasons.
    - jashmatthews 8y ago
      CRuby/MRI/YARV is almost as fast as BEAM at web stuff in terms of total throughput and JRuby is significantly faster. Sinatra + Sequel is faster at some things and slower at others. The default Rails setup makes huge tradeoffs away from performance.
  - jxub 8y ago
    The thing is that MRI Ruby is effectively single-threaded (unless you use things like concurrent-ruby which aren't that performant anyway) and threads can be blocked waiting for I/O, in fact they do most of the time, and is in I/O where Erlang really shines thanks to BEAM's nature of lightweight preemptive processes.
    - jashmatthews 8y ago
      CRuby is multi-threaded with a GIL. CRuby also supports light-weight cooperative threads called Fibres, which are used to build things like: https://github.com/postrank-labs/goliath/ https://github.com/postrank-labs/goliath/ JRuby has no GIL, JIT, and is significantly faster than BEAM.
bluesnowmonkey 8y ago
Always happy to see BEAM get faster but it won't match a NIF where you can control memory layout, mutate anything, use raw vector instructions. It's a killer combo though. Networking, memory management, high level application control in Elixir. Hot spots in NIFs. Kind of gets you the best of both worlds in terms of performance vs maintainability.

qaq 8y ago

I think it depends on project domain. perf. is fine for most web apps for example.

jerrycurly 8y ago
>> "perf. is fine for most web apps for example." That same argument is made for Ruby and look at how many people leave due to slowness
- skrebbel 8y ago
  Many of them leave to a BEAM language actually, for speed reasons.
  - jashmatthews 8y ago
    CRuby/MRI/YARV is almost as fast as BEAM at web stuff in terms of total throughput and JRuby is significantly faster. Sinatra + Sequel is faster at some things and slower at others. The default Rails setup makes huge tradeoffs away from performance.
- jxub 8y ago
  The thing is that MRI Ruby is effectively single-threaded (unless you use things like concurrent-ruby which aren't that performant anyway) and threads can be blocked waiting for I/O, in fact they do most of the time, and is in I/O where Erlang really shines thanks to BEAM's nature of lightweight preemptive processes.
  - jashmatthews 8y ago
    CRuby is multi-threaded with a GIL. CRuby also supports light-weight cooperative threads called Fibres, which are used to build things like: https://github.com/postrank-labs/goliath/ https://github.com/postrank-labs/goliath/ JRuby has no GIL, JIT, and is significantly faster than BEAM.

bluesnowmonkey 8y ago

Always happy to see BEAM get faster but it won't match a NIF where you can control memory layout, mutate anything, use raw vector instructions. It's a killer combo though. Networking, memory management, high level application control in Elixir. Hot spots in NIFs. Kind of gets you the best of both worlds in terms of performance vs maintainability.