A Brief History of the BEAM Compiler

Re:A Brief History of the BEAM Compiler by jerrycurly on Thursday August 02, 2018 @02:25PM (#17674076)

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

Maybe Facebook would fund this effort given their huge BEAM investment from WhatsApp use.

[ Parent | on HN ]

Re:A Brief History of the BEAM Compiler by qaq on Thursday August 02, 2018 @02:52PM (#17674320)

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

[ Parent | on HN ]

Re:A Brief History of the BEAM Compiler by jerrycurly on Thursday August 02, 2018 @03:08PM (#17674508)

>> "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

[ Parent | on HN ]

Re:A Brief History of the BEAM Compiler by jxub on Thursday August 02, 2018 @03:14PM (#17674585)

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.

[ Parent | on HN ]

Re:A Brief History of the BEAM Compiler by jashmatthews on Thursday August 02, 2018 @03:47PM (#17674850)

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/

JRuby has no GIL, JIT, and is significantly faster than BEAM.

[ Parent | on HN ]

Re:A Brief History of the BEAM Compiler by skrebbel on Thursday August 02, 2018 @03:12PM (#17674567)

Many of them leave to a BEAM language actually, for speed reasons.

[ Parent | on HN ]

Re:A Brief History of the BEAM Compiler by jashmatthews on Thursday August 02, 2018 @03:36PM (#17674763)

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.

[ Parent | on HN ]

Re:A Brief History of the BEAM Compiler by bluesnowmonkey on Friday August 03, 2018 @07:47PM (#17684486)

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.

[ Parent | on HN ]