3 ms·
I like a lot of things about Lua, the focus on embedded use and keeping the implementation nimble among others. LuaJIT is very impressive, but it's already drow
by sifoobar 8y ago
I like a lot of things about Lua, the focus on embedded use and keeping the implementation nimble among others. LuaJIT is very impressive, but it's already drowning in its own complexity.
I spent the last two years more or less full time trying out ways of making interpreters of similar complexity go faster without making the same mistake.
One method that seems really promising so far is AOT tracing [0], making guarantees and removing redundant code ahead of time based on incomplete semantic models. It's different from a full compiler in that it only tries to improve the situation and will back out and leave code alone where the semantic model is insufficient. And since it acts as a transformation on VM code, it's fairly transparent and easy to debug. The complexity of the models is a three way compromise between faster tracing, faster code and implementation complexity.
Once the VM code is reasonably optimal, further compiling to C by generating the interpreter code inline becomes even more attractive. Which also leads to native executables as a bonus feature.
[0] https://gitlab.com/sifoo/snigl#tracing https://gitlab.com/sifoo/snigl#tracing
- mingodad 8y agoHello Andreas ! It's an interesting approach for jit, I did looked at your link and one of the reasons to reshape Lua with a C/C++/Java/Javascript syntax was code reuse and learning curve, at first looking at the syntax of snigl it seems that you'll need to rewrite a lot of software to make the language usable and convince people that the learning curve and small comunity will be worth at the end. Best wishes !
- sifoobar 8y agoAgreed; C, Forth & Lisp are all acquired tastes. Which is fine, one size never fits all. Just wanted to mention some alternatives to LuaJIT, since I don't think it's a viable way forward for languages of this scale. Likewise!
- sifoobar 8y agoJust noting that JIT means speculating from what you've seen so far, what I'm doing is proving invariants and removing redundancy at compile time. Which means more predictable performance, since the code stays the same once it starts running; and a less complex implementation, since there's no need to de-optimize anything. The reason I'm tracing is that it's the only way I've found to prove anything of value in such a formless language; even Lisp knows which arguments belong to which function call, in Forth that depends on what came before. And it fits well with an interpreted language, since a slow compile often defeats the purpose of compiling in the first place. The tracing I've implemented so far is instant in comparison.