Fast Allocations in Ruby 3.5
21 comments
·May 22, 2025alberth
tenderlove
It's not being abandoned, we're just shifting focus to evaluate a new style of compiler. YJIT will still get bug fixes and performance improvements.
ZJIT is a method based JIT (the type of compiler traditionally taught in schools) where YJIT is a lazy basic block versioning (LBBV) compiler. We're using what we learned developing and deploying YJIT to build an even better JIT compiler. IOW we're going to fold some of YJIT's techniques in to ZJIT.
> And if so, will these YJIT features likes Fast Allocations be brought to ZJIT?
It may not have been clear from the post, but this fast allocation strategy is actually implemented in the byte code interpreter. You will get a speedup without using any JIT compiler. We've already ported this fast-path to YJIT and are in the midst of implementing it in ZJIT.
ksec
>For this reason, we will continue maintaining YJIT for now and Ruby 3.5 will ship with both YJIT and ZJIT. In parallel, we will improve ZJIT until it is on par (features and performance) with YJIT.
I guess YJIT will always be faster in warmup and minimal increase of memory usage. ZJIT being more traditional should bring more speedup than YJIT.
But most of the speedup right now is still coming from rewriting C into Ruby.
uticus
> But most of the speedup right now is still coming from rewriting C into Ruby.
Quick glance, this statement seems backwards - shouldn't C always be faster? or maybe i'm misunderstanding how the JIT truly works
firemelt
after reading your source I'd say YJIT still there up until ZJIT is ready and on par with YJIT
and the features is there when its there
90s_dev
It seems to me like all languages are converging towards something like WASM. I wonder if in 20 years we will see WASM become the de facto platform that all apps can compile to and all operating systems can run near-natively with only a thin like WASI but more convenient.
berkes
Wasn't this the idea of the JVM?
90s_dev
I think so, but that was the 90s where we needed a lot more hindsight to get it right. Plus that was mostly just Sun, right? WASM is backed by all browsers and it looks like MS might be looking at bridging it with its own kernel or something?
lloeki
> that was the 90s
In the meantime the CLR happened too.
And - to an extent - LLVM IR.
foldr
And of course the ill-fated Parrot VM associated with the Perl 6 project.
rhdjsjebshjffn
I think that was more of a language-oriented effort rather than runtime/abi oriented effort.
firemelt
did it means more speeds to all rails/active records collections?
ksec
I know I may be jumping the gun a little here but I wonder what percentage speedup could we expect on typical rails applications. Especially with Active Record.
GGO
so far no diff here (https://speed.yjit.org/). But the build is from May 14 so maybe it will show up in new build?
tempest_
At this point from the outside looking in Ruby is Rails at this point.
null
Can someone explain, is YJIT being abandoned over the new ZJIT? [0]
And if so, will these YJIT features likes Fast Allocations be brought to ZJIT?
https://railsatscale.com/2025-05-14-merge-zjit/