Is that something different to what vmakarov is doing [1], the work of current MJIT from k0kubun [2] seems to be based on this earlier work. And I believe vmakarov is working on RTL from YARV instructions, and a light weight JIT [3].
If I remember correctly there was a Tracing JIT for CRuby in 2016, but discontinued due to memory consumption
[1] https://bugs.ruby-lang.org/issues/12589 [2] https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby... [3] https://www.youtube.com/watch?v=emhYoI_RiOA
Re:Artichoke – A Ruby made with Rust
by jashmatthews on Sunday August 04, 2019 @01:01PM
(#20607723)
Yup. Quite different. Similar to RuJIT but I’m trying quite a different approach to trace recording and using CraneLift, an optimized code generation backend, rather than using tinycc
Light weight JIT only helps to remove the overhead of GCC etc. Not to be able to inline, constant fold etc. Something like the JRuby IR is required for that.
Re:Artichoke – A Ruby made with Rust
by aardvark179 on Sunday August 04, 2019 @09:06AM
(#20606290)
What is your plan for C extensions? They are heavily used in Ruby and tend to create a tricky barrier to optimisation. The fact the standard library is mostly written in C doesn’t help either.
Re:Artichoke – A Ruby made with Rust
by jashmatthews on Sunday August 04, 2019 @11:22AM
(#20607041)
Same thing LuaJIT does. Implement the really performance critical functions in IR and emit direct calls to C implementations of the complex ones.
In LuaJIT the FFI specifies enough type information to be able to call native functions from a trace.
I’m targeting optimizing through ActiveSupport String.blank? now I’ve got some micro benchmarks running.
I'm building a tracing JIT for CRuby in Rust at the moment. I started out trying to build a method JIT but mixing type analysis and iterative inlining to deal with real idiomatic Ruby code gets complex very fast. With tracing, both follow naturally.