Elixir is great.
OT: I wish more funding & development effort went into BEAM itself on making it more performant.
Note: I’m not talking concurrency. I’m talking pure raw performance.
Seems like it’s been a one person show for over a decade on making it faster.
There are multiple people working on the JIT within the last 5-6 years. The WhatsApp folks also contribute meaningfully.
I suspect once the Erlang/OTP team squeezes all performance in the JIT, they will look into optimizing across modules, which will probably open up many new possibilities, but it requires rethinking some runtime primitives.
Hi Jose
You’re an inspiration for many. Thank you.
I’m curious to know what your top 3 hopes for BEAM itself are for the coming years (in any area that you think would make it better).
Thanks for the kind words and the nice question!
1. The cross module optimizations I mentioned above 2. Have a WASM target for the runtime itself 3. Make it easier to ship single file executables with the whole VM
But they are really “nice-to-have”s. I have been a happy user for 15+ years!
A few years ago, I was working on an interpreter implemented in elixir for a domain specific language. It was a pretty basic metacircular interpreter. It relied heavily on function signature dispatch. When I tried breaking up the massive “interpret” function across modules, performance tanked. I got it all back by using some macro shenanigans, but understandably the team did not like this.
Knowing what I know now, I would’ve tried to push for a threaded interpreter to get rid of the runtime overhead of dispatching altogether. I don’t know if they’ve changed the architecture of that module much since I left :-)
It’s pretty hard to make things like math faster for real world use cases in a bytecode interpreter.
It's a JIT nowadays. Admittedly an extremely simple one, to minimize compile times and maintenance overhead.
You can get substantial performance improvements by using guards though. See what Wings3D does with is_float() everywhere in hot numeric-heavy code.
Can you elaborate why adding guards makes things faster?
Presumably it gives the JIT more type information, parent example was specifically about one of the type-check functions you can use for guards (is_float). While running it'll use the is_float information to generate code for the float case, and bail out if the actual values fail the guards at runtime.
Other JITS like V8 will do things like speculative inlining and inserting its own type guards , but if this JIT is "Admittedly an extremely simple one" then it presumably doesn't do much of that.
i ran a quick experiment where instead of doing boxing the way its done in the beam currently, i used a different boxing (NaN strategy and there was a 10x speedup
oh, I didn't recognize your username here! It's been ages since I've seen you. Hope you'll be in Chicago in September.
i will not, sorry. but ill probably be at exmex
I’ll have to come up for the NYC meetup.
Is that translates to real workloads you should open a pr.
Java and Javascript run times do really well at that.