More optimizations in the compiler and JIT(erlang.org) |
More optimizations in the compiler and JIT(erlang.org) |
I really should learn from BEAM and the OTP and learn Erlang. I get the feeling it's super robust and reliable and low maintenance. I wrote a userspace multithreaded scheduler which distributes N lightweight threads to M kernel threads.
https://github.com/samsquire/preemptible-thread
I recently wrote a JIT compiler and got lazy compilation of machine code working and I'm nowhere near beginning optimisation
https://github.com/samsquire/compiler
How do you write robust software, that doesn't crash when something unexpected goes on?
I looked at sozo https://github.com/sozu-proxy/sozu
and I'm thinking how to create something that just stays up and running regardless.
The patterns defined by OTP are a work of art and tremendously rewarding. I've yet to use any other system/runtime that elegantly solves the amount of issues that come up when writing these type of systems up front.
The BEAM is a work of art. Nothing comes close.
Reading up on the Erlang GC was fun.
So was reading Kernel.ex (Elixir's bootstrap file)
It makes it really hard to optimise things that could be sped up by fusing operations.
The yielding part is harder. You need to have infrastructure in place to dynamically flush certain operations when unexpected yields happen.
Basically the thread scheduling system could trigger an overflow/underflow exception via a fairly fast operation by pushing an illegal value into a watchdog for the thread. An instruction was injected at the top of each function, loop, where the condition of the registers was in a knowable state, and I think a few other places to guarantee a degree of fairness.
For more realtime behavior you'd need to pepper these calls in many places, and any fusion operations would need to inject something similar into the instruction stream. Then you'd have to be very, very careful to avoid cache line aliasing that would crash the throughput via false sharing.
I guess most practical calculations would end up triggering the inexact flag.
(There's also a cute consequence: you can construct numbers outside the contiguous range of representable integers; so long as you never incur any rounding error, the result will be correct, and the inexact flag will not be set.)