5 ms·

> version of the JIT in Rust 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 an

> version of the JIT in Rust 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.

aardvark179 7y ago
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.
- jashmatthews 7y ago
  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.
ksec 7y ago
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 https://bugs.ruby-lang.org/issues/12589 [2] https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby-2-6-388ee0989c13 https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby... [3] https://www.youtube.com/watch?v=emhYoI_RiOA https://www.youtube.com/watch?v=emhYoI_RiOA
- jashmatthews 7y ago
  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.

aardvark179 7y ago

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.

jashmatthews 7y ago
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.

ksec 7y ago

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 https://bugs.ruby-lang.org/issues/12589 [2] https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby-2-6-388ee0989c13 https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby... [3] https://www.youtube.com/watch?v=emhYoI_RiOA https://www.youtube.com/watch?v=emhYoI_RiOA

jashmatthews 7y ago
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.