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

51–57 of 57 posts

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

#51

Post by damagednoob »

maxime_cb wrote: post #5
hartator wrote: post #3

Earlier quoted context omitted.

Yeah, our last benchmark was with 3.1.2 + YJIT, but we actually saw a regression in term of performance while RAM usage was indeed up: https://serpapi.com/blog/benchmarking-ruby-3-1-yjit-ruby-2-7...

Hope you try again with 3.3. The improvements we've made to YJIT since Ruby 3.1 are massive.

From the blog post, it sounded like their benchmark relied heavily on a gem with a C extension (nokogiri). It's hard to imagine a performance improvement on code that YJIT has no control over.

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

#52

Post by ksec »

byroot wrote: post #31
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…

There is still lots of optimizations to make. On the JIT side, there is still no inlining, which opens the door to much more aggressive optimizations. But also on memory as well. There was a lot of improvements done on the Ruby garbage collector for 3.3, but there's still a lot of room for improvement, and a few fine folks at Shopify are looking into making the GC swappable so we'd be able to use mttk GCs with MRI. A…

>On the JIT side, there is still no inlining,

Oh wow. Had no idea there was no inlining. That is potentially another 2-3x performance.

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

#53

Post by byroot »

ksec wrote: post #52
byroot wrote: post #31

Earlier quoted context omitted.

There is still lots of optimizations to make. On the JIT side, there is still no inlining, which opens the door to much more aggressive optimizations. But also on memory as well. There was a lot of improvements done on the Ruby garbage collector for 3.3, but there's still a lot of room for improvement, and a few fine folks at Shopify are looking into making the GC swappable so we'd be able to use mttk GCs with MRI. A…

>On the JIT side, there is still no inlining, Oh wow. Had no idea there was no inlining. That is potentially another 2-3x performance.

To be slightly more correct, there is inlining but only of trivial methods that simply return an immediate value or a constant, e.g.

    class NilClass
      def blank?
        true
      end

      def present?
        false
      end
    end

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

#54

Post by TobiasBales »

mlinksva wrote: post #45
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…

> We know in order to make JIT more useful we need to move some of the Gems from C to Ruby. Just curious, how well do we know this, e.g., theory, experiments, it's being done, or ? It'd be fun if RiiR[uby] were a small part of the overall memory saftey glacier (e.g., https://www.cisa.gov/case-memory-safe-roadmaps )

https://railsatscale.com/2023-08-29-ruby-outperforms-c/ by Aaron comes to mind

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

#55

Post by mortallywounded »

CyberDildonics wrote: post #50
adamors wrote: post #15

Earlier quoted context omitted.

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.

Exactly, ruby performance is like someone beating their personal best time jogging around the neighborhood and then writing an article about it. It's something positive in their own ecosystem, but is not competitive when people need results.

Yes-- unfortunately I've been downvoted to hell for even suggesting we discuss other languages in comparison.

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

#56

Post by Lio »

dcchambers wrote: post #21
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…

> Obviously as an interpreted language

Isn't the point of YJIT that it's a ruby compiler.

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

#57

Post by hartator »

damagednoob wrote: post #51
maxime_cb wrote: post #5

Earlier quoted context omitted.

Hope you try again with 3.3. The improvements we've made to YJIT since Ruby 3.1 are massive.

From the blog post, it sounded like their benchmark relied heavily on a gem with a C extension (nokogiri). It's hard to imagine a performance improvement on code that YJIT has no control over.

Yes, we ended up replacing Nokogiri by Nokolexbor, our own port of lexbor parser with like almost full compatibility with Nokogiri APIs while being around 5x faster: https://github.com/serpapi/nokolexbor
Post reply on HN