YJIT enabled by default, Active Model improvements and much more | Hacker News Reader

YJIT enabled by default, Active Model improvements and much more

rubyonrails.org

73 pointsamalinovic9 comments

Enabling YJIT comes at the cost of using a noticeable amount more memory so it might be tricky to get going on a single server deploy that runs let's say Puma, Sidekiq and Action Cable (3 processes) on a $10 or $20 a month VPS.

But the good news is in Ruby 3.3 they are working towards reducing memory consumption even more. Someone from Shopify recently tweeted this in response to a question I asked about memory consumption:

> Our goal is to make the memory concern of YJIT to not be a thing for Ruby 3.3 anyway, so this really shouldn't be much of a concern

That's really exciting news. I mean it's already a huge deal to have YJIT and is worth using but now it's looking like a zero downside win all around and there's going to be no reason not to enable it.

YJIT tech lead here.

On the flip side, YJIT is probably one of the most memory-efficient JIT compilers out there (for any language). I say this having spoken to other JIT implementers.

We've worked really hard to reduce the memory overhead and at Shopify it's now down to less than 10% in our flagship production deployment.

Regardless, if memory usage is a legitimate concern for you, you can very easily remove the Rails initializer that turns on YJIT. You can choose between memory usage and response time. The choice is yours.

Oh yeah, please don't get me wrong. My original reply isn't to take away what YJIT accomplished. It was mainly to reference that in the past YJIT used more memory but maybe starting with Ruby 3.3 you won't have to think about that aspect anymore, even for apps running on a low spec machine.

I can't even begin to fathom at how much work and testing must have went into YJIT to make it work as well as it does. Thank you!

I’m curious what you think the next big opportunities are to speed up Ruby?

Is there a write up anywhere of the techniques employed to keep memory usage down that other implementations aren’t doing?

The article doesn't go into super deep details but we do touch on it in the paper we've recently published: https://dl.acm.org/doi/10.1145/3617651.3622982

And I went into some more details the talk I gave at RubyKaigi 2023: https://www.youtube.com/watch?v=X0JRhh8w_4I&t=2404s

Many have tried and failed. But Finally a Ruby JIT that is shipped and enabled by default. Discourse is now on YJIT as well [1], Still hoping we could get much larger performance improvement down the road.

[1] https://blog.discourse.org/2023/05/running-ruby-3-2s-yjit-in...

Yeah, that leaves Python as the one still not shipping a JIT on the reference implementation.

Ruby 3.3 (coming this Christmas) will have a much faster and more memory efficient YJIT than 3.2. We've made major improvements this year.

Reply on news.ycombinator.com