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

Ruby 3.3's YJIT: Faster While Using Less Memory

railsatscale.com

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#21

Post by dcchambers »

avg_dev wrote: post #9

I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code ve…

Obviously as an interpreted language, it's never going to be as fast as something like C, Rust, or Go. Traditionally the ruby maintainers have not designed or optimized for pure speed, but that is changing, and the language is definitely faster these days compared to a decade ago.

If you like the ruby syntax/language but want the speed of a compiled language, it's also worth checking out Crystal[^1]. It's mostly ruby-like in syntax, style, and developer ergonomics.[^2] Although it's an entirely different language. Also a tiny community.

[1]: https://crystal-lang.org/ [2]: https://crystal-lang.org/reference/1.10/crystal_for_rubyists...

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#22

Post by taf2 »

apstats wrote: post #2

I moved from ruby 2.7 to 3.2 for a rails app and was hopeful that it would lead to large speedups like shopify claims it did for them, but was bummed to find it did basically nothing. Anyone else running a large rails app have a similar or different experience?

Sorry to hear you had that experience we saw 30% speedup moving from 2.6 to 3.2 and the 95th in many cases was 40%... Did you happen to enable yjit and if so which app server are you running?

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#23

Post by apstats »

adamors wrote: post #13
apstats wrote: post #2

I moved from ruby 2.7 to 3.2 for a rails app and was hopeful that it would lead to large speedups like shopify claims it did for them, but was bummed to find it did basically nothing. Anyone else running a large rails app have a similar or different experience?

I benchmarked a good sized app (ran a black-box QA suite multiple times) while monitoring performance and req/response times with Prometheus/Grafana with Ruby 3.2. With YJIT enabled memory usage ballooned and performance dipped below non-YJIT Ruby 3.2, IIRC the difference was a good 10% degradation. Granted, it's an API only service so no HTML is being generated, only JSON and that could be the culprit. Suffice it to…

Interesting. Do you think html generation is one of the things that makes the numbers look so good for 3.2 YJIT? We run a mostly json api only app. I think json serialization is notoriously slow in ruby so I was hoping yjit would speed it up.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#24

Post by JohnBooty »

apstats wrote: post #2

I moved from ruby 2.7 to 3.2 for a rails app and was hopeful that it would lead to large speedups like shopify claims it did for them, but was bummed to find it did basically nothing. Anyone else running a large rails app have a similar or different experience?

Two thoughts.

1. How did you evaluate performance? Did you let it run for a while in production? YJIT's improvements will be most visible over time.

2. If your web app's response times are dominated by database queries, then YJIT will do nothing for you. Even re-writing your app in assembly language won't help. All languages are equally fast when sitting around waiting for the database to response. ;-)

That said, if your response times are dominated by db query wait times, maybe the async queries in Rails 7.x can offer you some very nice improvements. However, you will probably need to restructure (not rewrite, exactly, but restructure) your code to take advantage. Not the whole app, just the hot spots.

https://www.shakacode.com/blog/rails-7-1-active-record-api-f...

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#25

Post by alberth »

ksec wrote: post #19

My question is what's next? Without sacrificing (much) memory. We know from TruffleRuby that given enough warmups and lots of memory it could be multiple times faster than CRuby. And compared to Ruby 3.3 YJIT may be 2-3x faster. But it seems the communities as a whole cares a lot about memory usage. We know in order to make JIT more useful we need to move some of the Gems from C to Ruby. But other than that do we hav…

Truffle Ruby is 50-100% faster in most tests.

But uses 5-10x more memory.

Still has way more upside left to gain.

https://railsatscale.com/2023-11-07-yjit-is-the-most-memory-...

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#26

Post by cntainer »

apstats wrote: post #2

I moved from ruby 2.7 to 3.2 for a rails app and was hopeful that it would lead to large speedups like shopify claims it did for them, but was bummed to find it did basically nothing. Anyone else running a large rails app have a similar or different experience?

Pretty sure it means that Ruby isn't the bottleneck for your case.

In most WebApps the first performance bottleneck people tend to hit is the DB: missing indexes, n+1 queries, etc.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#27

Post by parentheses »

ksec wrote: post #19

My question is what's next? Without sacrificing (much) memory. We know from TruffleRuby that given enough warmups and lots of memory it could be multiple times faster than CRuby. And compared to Ruby 3.3 YJIT may be 2-3x faster. But it seems the communities as a whole cares a lot about memory usage. We know in order to make JIT more useful we need to move some of the Gems from C to Ruby. But other than that do we hav…

It does make sense in the web server context to optimize for memory first over compute. This could explain the dynamic you called out. Furthermore, the propensity for many popular gems to have native portions makes the trade off even more useful.

Regarding JIT being faster, types are the next effective tool IMO.

The two drivers I see are:

- JIT has more stack frames to optimize away, allowing more optimization - you addressed this one

- JIT has more information to limit possible outcomes, therefore finding more opportunities

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#28

Post by dang »

Recent and related:

YJIT is the most memory-efficient Ruby JIT - https://news.ycombinator.com/item?id=38265773 - Nov 2023 (29 comments)

Also:

Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster - https://news.ycombinator.com/item?id=37579926 - Sept 2023 (154 comments)

Running Ruby 3.2's YJIT in Production at Discourse - https://news.ycombinator.com/item?id=35895309 - May 2023 (1 comment)

Ruby 3.2’s YJIT is Production-Ready - https://news.ycombinator.com/item?id=34413012 - Jan 2023 (286 comments)

Our Experience Porting the YJIT Ruby Compiler to Rust - https://news.ycombinator.com/item?id=31344065 - May 2022 (89 comments)

Ruby YJIT Ported to Rust - https://news.ycombinator.com/item?id=31094130 - April 2022 (88 comments)

Rust YJIT is complete – it passes all the CRuby tests - https://news.ycombinator.com/item?id=31090084 - April 2022 (1 comment)

Ruby: Porting YJIT to Rust - https://news.ycombinator.com/item?id=29971360 - Jan 2022 (48 comments)

Benchmarking CRuby, MJIT, YJIT, JRuby, and TruffleRuby - https://news.ycombinator.com/item?id=29824076 - Jan 2022 (29 comments)

Merge YJIT: an in-process JIT compiler - https://news.ycombinator.com/item?id=28938446 - Oct 2021 (24 comments)

YJIT: Building a New JIT Compiler for CRuby - https://news.ycombinator.com/item?id=28874283 - Oct 2021 (47 comments)

Proposal to Merge YJIT into Ruby - https://news.ycombinator.com/item?id=28691048 - Sept 2021 (77 comments)

YJIT: Building a New JIT Compiler Inside CRuby - https://news.ycombinator.com/item?id=27371977 - June 2021 (1 comment)

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#29

Post by schneems »

ksec wrote: post #19

My question is what's next? Without sacrificing (much) memory. We know from TruffleRuby that given enough warmups and lots of memory it could be multiple times faster than CRuby. And compared to Ruby 3.3 YJIT may be 2-3x faster. But it seems the communities as a whole cares a lot about memory usage. We know in order to make JIT more useful we need to move some of the Gems from C to Ruby. But other than that do we hav…

> But it seems the communities as a whole cares a lot about memory usage.

Matz very much sees Ruby as still a general purpose language that still supports scripting as a first tier concern. From that vantage bootup and memory are hugely important. Also providers like Heroku (I work there) charge for memory and the primary way to get parallelism with the GIL/GVL is using multiple processes where memory use can multiply rapidly (literally).

> speed up Ruby on Rails?

You can look at other communities to get a preview of what might come. Ruby now has “object shapes” like node.js which will benefit the community more once people start using it, enabling warnings and fixing hotspots where instance variables are not declared optimally.

Personally, I would like to see rails embrace the power of database backed constraints and fallback to using validation queries only when the database throws an error on commit. You can already saturate a CPU with processes and threads, the biggest bottleneck (IMHO) for most rails apps is still the database. Counterintuitively, pushing those constraints to the database can mean a net decrease in DB computing needed and more overall throughput.

Aside from that I think JIT will help do more with fewer resources. Which makes sense when the main YJIT sponsor has a huge server bill and being able to slash it in half more than justifies such long term gambles.

Re: Ruby 3.3's YJIT: Faster While Using Less Memory

#30

Post by [deleted] »

adamors wrote: post #15
mortallywounded wrote: post #7

I get the need to improve Ruby's speed and memory usage, but there's much to be desired. I really enjoy Rails and Ruby in general, but the performance is terrible. I'd like to see how Ruby 3.3 stacks up to other languages and runtimes.

In 2023 if performance is a functional requirement, Ruby is still not the answer IMO. For companies like Shopify, there's really no other alternative at this point, but their "fast" is only fast compared to the performance they've had 1-2 years ago.

[deleted]
Post reply on HN