Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

Post reply on HN
Print view View original

21–30 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#21

Post by MSkog »

JohnBooty wrote: post #18
jrochkind1 wrote: post #13

Earlier quoted context omitted.

> I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly inco…

The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

You can also set RUBY_YJIT_ENABLE=1 to enable it.

Re: Ruby 3.2’s YJIT is Production-Ready

#22

Post by jrochkind1 »

JohnBooty wrote: post #18
jrochkind1 wrote: post #13

Earlier quoted context omitted.

> I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly inco…

The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

Thanks! Is there a "canonical" place to find this documented, like with the ruby distro?

> For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

Alternately, you can edit your shell init scripts to put the correct thing in `RUBY_OPTS` ENV variable, yes?

I would consider this preferable to editing executable rails scripts with implementation-specific stuff (and then hoping that the app is always launched with those edited shell scripts, which I'm not sure eg `bundle exec rails` will do). I don't think editing Rails scripts is probably the "right" or recommended way to do this.

But I'm not going to try to specify what you put in `RUBY_OPTS` since i haven't done it myself and don't want to spread misinformation! (Again, is this documented in a centralized trustworthy place? As I try to google it... I am somewhat frustrated with the ruby documentation situation!)

Re: Ruby 3.2’s YJIT is Production-Ready

#23

Post by JohnBooty »

bastawhiz wrote: post #12
asim wrote: post #2

It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the H…

The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code…

Love this post, although:

    Ruby is easy to hire for
I've always had the opposite experience!

Re: Ruby 3.2’s YJIT is Production-Ready

#24

Post by onlyrealcuzzo »

bastawhiz wrote: post #12
asim wrote: post #2

It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the H…

The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code…

> Switching is possible, but the cost to replace it is half a decade or more.

I would imagine if you're going to switch millions of lines from one language to another - you wouldn't do it by hand - you'd write something transpile it?

Has any company actually done something like this before - especially somewhat recently?

I can't imagine anyone doing it by hand...

Re: Ruby 3.2’s YJIT is Production-Ready

#25

Post by MSkog »

jrochkind1 wrote: post #22
JohnBooty wrote: post #18

Earlier quoted context omitted.

The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

Thanks! Is there a "canonical" place to find this documented, like with the ruby distro? > For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag. Alternately, you can edit your shell init scripts to put the correct thing in `RUBY_OPTS` ENV variable, yes? I would consider this preferable to editing executable rails scripts with implementation-specific stuff (and then hopi…

Perhaps this is what you are looking for:

https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md

Re: Ruby 3.2’s YJIT is Production-Ready

#26

Post by maxime_cb »

psychoslave wrote: post #7
asim wrote: post #2

It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the H…

I see the point to make a parallel with HipHop, but here YJIT is directly integrated in CRuby, the main implementation of the language, and it’s just a matter of command line flag whether you enable or disable it — at least from what I remember that I red. From what I remember, HipHop was distributed in a different toolchain than the vanilla PHP interpreter. Ruby also have other interpreters available by the way: htt…

Yes. Not only is YJIT directly integrated into CRuby, it's also 100% compatible with your existing Ruby code, which is why we chose to go that route.

We didn't want to independently reimplement Ruby because we knew that this would lead to a situation where we wouldn't be 100% compatible, which would stop people from using YJIT. If you think about PyPy for example, they have great performance numbers, but relatively few people are using it.

Re: Ruby 3.2’s YJIT is Production-Ready

#27

Post by simantel »

jrochkind1 wrote: post #13
erikrothoff wrote: post #10

I'm pretty sure (there isn't a lot of info on how to enable it in production workloads) we're running YJIT in production and didn't notice any improvement in load times, CPU usage or anything really. If any slightly higher metrics across the board. We're using Rails as API and web frontend with a pretty high number of requests per second, so I was hoping we'd see something. Does anyone have any experience rolling it…

> I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly inco…

Also worth noting that the Ruby 3.2 Docker image can't run with YJIT yet, so if your production setup is in a container, it's most likely not using YJIT.

GitHub issue link here: https://github.com/docker-library/ruby/pull/398

Re: Ruby 3.2’s YJIT is Production-Ready

#29

Post by bastawhiz »

JohnBooty wrote: post #23
bastawhiz wrote: post #12

Earlier quoted context omitted.

The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code…

Love this post, although: Ruby is easy to hire for I've always had the opposite experience!

In my time at Stripe, few of the candidates were fluent in Ruby, but it almost always took less than a couple weeks to get spun up with it. If you're looking for Ruby talent, it's more challenging.

Re: Ruby 3.2’s YJIT is Production-Ready

#30

Post by cguess »

onlyrealcuzzo wrote: post #24
bastawhiz wrote: post #12

Earlier quoted context omitted.

The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code…

> Switching is possible, but the cost to replace it is half a decade or more. I would imagine if you're going to switch millions of lines from one language to another - you wouldn't do it by hand - you'd write something transpile it? Has any company actually done something like this before - especially somewhat recently? I can't imagine anyone doing it by hand...

That doesn't really work in practice at scale. There's "Ruby" ways of doing things that don't just transpile over. It's also the entire Rails framework that would have to be ported then, which is beyond a monumental undertaking.

That's not to even mention the massive amounts of new bugs that would be put into the code that have been ironed out over years of debugging and testing in the Ruby base. There's a reason so many legacy operators still run COBOL despite even C being a better candidate, it was just created twenty years too late and the costs of moving it over is well outside of the savings of not doing that.

"If it ain't broke, don't fix it" is very much the key here.

Post reply on HN