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

11–20 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#11

Post by jrochkind1 »

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 JVM is as performant as it is because so much resources were invested in optimization (including various forms of JIT etc). It's an amazingly performant VM because of so much invested in tuning it. Or same about various Javascript VMs.

This kind of performance comes from lots of resources invested in tuning. Lots of resources are invested, generally, when there are lots of entities relying on a thing; that's a very good reason people invest in improving a thing, right?

So I'm not really sure what you mean -- you say "sunk cost", I say "Well, those who are using a thing are those who invest in improving it, how is it ever any different? And that there are people with current investments in ruby who will continue to invest to improve it is what will make ruby continue to thrive -- and how is it ever any different with any technology?"

What would make it "sunk cost", i suppose, is if you think ruby is a poor technology and everyone using it should switch to something else. I guess it is popular to hate on ruby right now, but that seems to be an orthogonal debate. Ironically, one of the most popular reasons to hate on ruby is "performance" (rightly or wrongly), so it seems especialy weird to me to show up with an argument like "Sure, they're drastically improving ruby performance, but is ruby the right choice of thing to improve it's performance? After all, ruby has such bad performance!"

To be fair, you didn't specifically say "because ruby has such bad performance", you didn't say anything about why ruby might be the wrong thing to invest in at all -- which makes it all the more just weird FUD, intentionally or not.

You are suggesting that just in general we should prefer switching to new languages over investing in the existing ones? Since you didn't supply any specific arguments, it makes it seem as if you suggest this as a general principle, regardless of details? I think many of our experiences is that this leads to always using immature technology; to reach the stability and performance of (say) the JVM or V8 requires... investing in the thing, not constantly chasing a new immature thing hoping it will be different this time.

Re: Ruby 3.2’s YJIT is Production-Ready

#12

Post by bastawhiz »

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 written in it, and there's a ton of operational knowledge about how to use it well. Switching is possible, but the cost to replace it is half a decade or more. During that time, you're not building new features, you're worrying about compatibility and making sure there's no downtime. Instead of making incremental improvements, your infra folks are worrying about migration paths.

At the end of the day, the major arguments against Ruby is lack of native type checking (solved with tooling) and performance. For Shopify, you can either undertake a major engineering effort to rewrite your stack (years of effort, incidents, no real feature development, morale killing) or kick a few million dollars at making the thing your engineers like faster. The cost of replacing Ruby is tens of millions of dollars: not just engineers putting pen to paper, but lost business from putting the company on hold, breakages, and throwing out immense amounts of operational knowledge and experience.

Said another way, telling a thousand+ people to drop what they're doing, learn a new language, and redo all their work is an expensive way to end up with a worse version of what you already have. It's not a sunk cost fallacy if you literally can't afford to change.

Re: Ruby 3.2’s YJIT is Production-Ready

#13

Post by jrochkind1 »

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 incorrect info here about how to enable it. I agree that it's not clear to me where to find this documented. I am pretty sure it is not on by default.

Re: Ruby 3.2’s YJIT is Production-Ready

#15

Post by JohnBooty »

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…

    Does anyone have any experience rolling it out?
FWIW, the linked article has prod benchmarks.

    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
Sure you're running it? You have to compile with YJIT support, and then pass the command line arg. (It doesn't support YJIT out of the box because, I presume, they didn't want to force a Rust dependency on everybody?)

Here's how on MacOS + asdf, others will be similar. Note that I think --enable-yjit might work (but do nothing) even if you don't have support compiled in.

    # if you already installed 3.2.0
    asdf uninstall ruby 3.2.0
    
    # install Rust
    asdf plugin-add rust
    asdf...      
    
    # now install Ruby 3.2
    asdf plugin-update ruby
    export RUBY_CONFIGURE_OPTS=--enable-yjit
    asdf install ruby 3.2.0
    asdf global ruby 3.2.0

    # verify it's installed and ready
    ruby --enable-yjit --version

    # now run your workload
    ruby --enable-yjit foo.rb

Re: Ruby 3.2’s YJIT is Production-Ready

#16

Post by olau »

asim wrote: post #4
xoac wrote: post #3

Earlier quoted context omitted.

Someone has to do this work, and I this is a good example of a company giving back to what was originally a non-industry project (Ruby).

Yes, I'm just asking whether that needs to be Shopify? And whether their time is best spent elsewhere.

The loss of human time in big corporations is immense. Coordination overhead and losses due to information logistics problems. I'd imagine a project like this with no dependencies on the rest of the stack can be run efficiently. From a bang per buck point of view it might beat other means (rewrite, using multiple languages, redoing ops to run on cheaper backbone) by a huge factor.

I get your sunk cost objection, but it's a bit depressing to hear people worry about someone doing genuinely useful work. Nobody wants to take responsibility or get their hands dirty. There's still plenty of low-hanging fruit in both language implementations and databases. The world today is just mountains upon mountains of bullshit.

Re: Ruby 3.2’s YJIT is Production-Ready

#18

Post by JohnBooty »

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…

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.

Re: Ruby 3.2’s YJIT is Production-Ready

#19

Post by JohnBooty »

the_sleaze9 wrote: post #17
panzi wrote: post #14

What does 10% speedup mean? Doing 10% more work in the same time or needing 10% less time for the same amount of work?

I have to admit my brain seems to be short circuiting on this one. Aren't these 2 ways of saying the same thing?

At it's heart they seem to be asking kind of a latency vs. throughput question. The answer is frustratingly "it depends" but for some real world Rails benchmarks, Shopify has published quite a few benchmarks including the ones in the linked article.

Re: Ruby 3.2’s YJIT is Production-Ready

#20

Post by maxime_cb »

frou_dh wrote: post #6

Does this work put Ruby into a faster category than Python until if/when Python gets a JIT in its official implementation?

If you believe the language benchmark game, Ruby is faster than Python on many of the microbenchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And the benchmark game is using Ruby 3.1, whereas 3.2 is significantly faster. YMMV though, it is going to depend on your use case, but we are always working on making Ruby faster, and if you run into a use case where Python is a lot faster, you can ping me on twitter @Love2Code and tell me about it. We'll take a look.

Post reply on HN