Rendered at 03:44:38 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
diablevv 44 minutes ago [-]
The escape analysis piece is what makes this particularly interesting. ZJIT can prove an object doesn't escape a method's scope and then eliminate the heap allocation entirely — the object lives on the stack (or in registers) and the load/store optimizations follow naturally once there's no indirection.
YJIT's profile-guided approach is powerful but pays a cost every time a hot path diverges from the expected type. The BBV approach in ZJIT bakes type assumptions directly into the compiled code, so you get the same specialization without the deopt overhead on the happy path. The tradeoff is code size — more type combinations means more compiled variants — but for server-side Rails apps where the method profile is fairly stable, that's usually fine.
Curious whether they're planning to share any of the escape analysis machinery upstream to YJIT, or if the JIT designs are diverging permanently.
mananaysiempre 10 hours ago [-]
Of all the facets of HN’s title autodestroy, I think removing “How” from titles is the worst one. I believe OP can edit it back in though.
(I passed over this article thinking it was a “look how mysteriously smart the mysteriously smart compiler is” acticle, not a “here’s how the smarts in a compiler work” one.)
dietr1ch 7 hours ago [-]
I think it'd fine having it be however broken it currently is as long as the correction was checked by whoever is submitting the entry before it gets published.
pjmlp 8 hours ago [-]
Yes, there is a timeout to fix title "corrections" after submission, but apparently still not well known.
QuantumNomad_ 6 hours ago [-]
Not well known and also, submitter might not always even notice that title was automatically changed slightly.
claudiug 8 hours ago [-]
for me is more interesting that Maxime Chevalier-Boisvert left shopify and is doing other stuff, who will carry on with zjit
schneems 5 hours ago [-]
You got your reply already. To add: YJIT is the one that does "basic block versioning" (Which was Maxime's thesis) while ZJIT is a more traditional design.
I am confident in that description but don't actually know what it means in practice (yes I've seen papers and talks, but I kinda need not-compiler-engineer to explain it to me.)
As I understand it BBV still holds promise, but the sheer volume of knowledge of more traditional methods might mean it gets better outcomes (also IIRC ZJIT is still lagging YJIT).
maxime_cb 52 minutes ago [-]
I gave a talk about ZJIT and the motivation for the change at RubyKaigi 2025 if people are curious. It's on YouTube.
YJIT's profile-guided approach is powerful but pays a cost every time a hot path diverges from the expected type. The BBV approach in ZJIT bakes type assumptions directly into the compiled code, so you get the same specialization without the deopt overhead on the happy path. The tradeoff is code size — more type combinations means more compiled variants — but for server-side Rails apps where the method profile is fairly stable, that's usually fine.
Curious whether they're planning to share any of the escape analysis machinery upstream to YJIT, or if the JIT designs are diverging permanently.
(I passed over this article thinking it was a “look how mysteriously smart the mysteriously smart compiler is” acticle, not a “here’s how the smarts in a compiler work” one.)
I am confident in that description but don't actually know what it means in practice (yes I've seen papers and talks, but I kinda need not-compiler-engineer to explain it to me.)
As I understand it BBV still holds promise, but the sheer volume of knowledge of more traditional methods might mean it gets better outcomes (also IIRC ZJIT is still lagging YJIT).
It would be nice to have ZJIT on speed.ruby-lang.org!