Fast Allocations in Ruby 3.5

78 tekknolagi 17 5/22/2025, 2:01:55 PM railsatscale.com ↗

Comments (17)

alberth · 1h ago
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/

tenderlove · 20m ago
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 · 1h ago
>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.

firemelt · 1h ago
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 · 1h ago
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 · 1h ago
Wasn't this the idea of the JVM?
90s_dev · 1h ago
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 · 28m ago
> that was the 90s

In the meantime the CLR happened too.

And - to an extent - LLVM IR.

foldr · 1h ago
And of course the ill-fated Parrot VM associated with the Perl 6 project.
rhdjsjebshjffn · 49m ago
I think that was more of a language-oriented effort rather than runtime/abi oriented effort.
foldr · 41m ago
Parrot was intended to be a universal VM. It wasn’t just for Perl.

https://www.slideshare.net/slideshow/the-parrot-vm/2126925

rhdjsjebshjffn · 26m ago
Sure, I just think that's a very odd way to characterize the project. Basically anything can be universal vm if you put enough effort to reimplementing the languages. Much of what sets Parrot aside is its support for frontend tooling.
firemelt · 1h ago
did it means more speeds to all rails/active records collections?
ksec · 1h ago
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.
tempest_ · 28m ago
At this point from the outside looking in Ruby is Rails at this point.
GGO · 1h ago
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?