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

Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

railsatscale.com

Post reply on HN
Print view View original

131–140 of 158 posts

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#131

Post by byroot »

jacobsenscott wrote: post #119
byroot wrote: post #47

Earlier quoted context omitted.

> Ruby processes don't return the memory to the system That is not correct. Ruby do unmap pages when it has too many free pages, and it obviously call `free` on memory it allocated once it doesn't use it. What happens sometime though is that because of fragmentation you have many free slots but no free whole pages. That is one of the reason why GC compaction was implemented, but it's not enabled by default. But in mo…

I'm correct in practice. There are scenarios where ruby might free memory, but ruby is mostly used for rails, and you won't ever see that under a standard rails workload. It will plataue and stay there until a restart. When people see this they think it's a "bug" or a "leak" but it isn't. On the last fairly large rails app I tried to use jemalloc on there was no change in memory usage. I believe that advice is a bit…

> It will plataue

Yes, because extra empty pages are released at the end of major GC, which is occasional, and most web application will cyclicaly use enough memory that they will stabilize / plateau at one point.

> I believe that advice is a bit outdated.

It absolutely isn't, your anecdote doesn't mean much compared to the countless reports you can find out there.

> Also note using jemalloc doesn't cause memory to be freed to the system.

Yes it does, it has a decay mecanism, most allocators do. https://jemalloc.net/jemalloc.3.html

> It reduces fragmentation

Yes, and that allows it to have more free pages that it can release.

> at the cost of cpu cycles

Compared to glibc, not so much.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#132

Post by nomilk »

nomilk wrote: post #121
nomilk wrote: post #17

Earlier quoted context omitted.

Going to try this right now! Will report back. OOC, why isn't this part a ruby default? Isn't it always better to be more memory efficient. (I'm trying to understand what the trade offs are, if any) EDIT: well, exactly 6 minutes later, I'm done. I followed these instructions: https://elements.heroku.com/buildpacks/gaffneyc/heroku-build... The app seems to work like usual, I'll just have to wait and see what happens t…

For anyone interested, here's the result: https://imgur.com/a/c62gjKQ (the red vertical line is the point from which jemalloc was used). It looks like memory usage did indeed go down, and critical errors fell by about 84%.

For completeness, here are the metrics a full 24 hours after the change: https://imgur.com/a/lbdzFvN

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#133

Post by netheril96 »

rafark wrote: post #75
nik736 wrote: post #54

Earlier quoted context omitted.

Twitch was initially built with Ruby on Rails as well.

YouTube was initially built with php, so the revenue argument is true.

Was it? What I was told was that Youtube was built in Python and was gradually migrated to C++ after bought by Google.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#134

Post by pjmlp »

TheRealDunkirk wrote: post #106
pjmlp wrote: post #90

Earlier quoted context omitted.

Yet, Ruby hasn't necessarly taken over the enterprise, beyond those stuck with Rails apps.

It's amazing to me that so many people make "stuck with Rails" arguments in the enterprise. It's extraordinarily clear to me, having worked in 3 Fortune 250's, that the single, most-attractive-to-management feature of alternative stacks like Java and Javascript is... dun dun dun!... MASSIVE project bloat! Justifying huge teams and years of development time, leading to huge budgets and personal power within the compan…

So where are those two projects now for all of us to amaze ourselves with the power of Rails?

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#135

Post by pjmlp »

p8 wrote: post #110
pjmlp wrote: post #103

Earlier quoted context omitted.

Because Android team had some Kotlin shills that pushed for it with management blessing, and they are in bed with JetBrains for the Android IDE, that is why, and even them had to accept updating Java support, otherwise Android/Kotlin would lose the ecosystem of Java written libraries, hence Java 11 LTS last year, and Java 17 LTS this year going, back to Android 12 with APEX archives. Scala became a thing indeed, wher…

So where are the Shopify's of that era build on Struts and JSF?

Amazon.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#136

Post by turbo_fart »

dgb23 wrote: post #88
bkazez wrote: post #80

15% faster - and how much faster would Java, Rust, or Python be?

That’s not easy to answer, because it’s not quite an apples to apples comparison if you start factoring in libraries, frameworks and the specific workload. My rule of thumbs: Python has similar performance characteristics as Ruby. With Java/C#/Go you’d expect about an order of magnitude of improvement. With naive Rust/C++ you would likely be at the same average speed as Java for web applications but with less memory…

Node.js is about 20x faster than RoR for instance

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#137

Post by chucke »

nindalf wrote: post #37
berkle4455 wrote: post #30

Earlier quoted context omitted.

> And how many instances would be required if Go/Rust would have been used? Zero. Because Shopify would have waited until Rust came out in 2015, instead of launching in 2006, and they would never have gotten off the ground and been another failed techbro startup that instead of getting shit done, bikeshedded over languages. PHP and Ruby apps have generated far more revenues than all the Rust and Golang code combined.

Rails was a great choice for Shopify, GitHub and Stripe, no doubt. No one is questioning that. GP’s sarcastic “rails doesn’t scale” implies that it would also be a great choice for people starting afresh in 2023. The reply asks for a comparison with other languages popular in 2023, especially ones that are known for being more performant (lower memory and CPU consumption, lower latency). And that’s when you’re draggi…

You're implying that those languages made actual building products easier. I think we know by now they didn't. Go is a language which preaches building your boilerplate than reusing it. Produces very little of the economies of scale requires to build compelling products. It has other advantages, and the single binary thing captured a niche in infrastructure software, but that's it outside of Google. Rust is still young, jury is out, but it's already considered a big and hard to learn language, and that's not going to change soon. It'll eventually find a niche.

Ruby is still a great way to start it up. Consider that in 2006-2008, it's deployment story was horrible. Since then, the ruby ecosystem bootstrapped lockfiles, 12 factor app manifesto, and a lot of the conventions we all take for granted nowadays. And while there are certainly enough arguments to bikeshed on, its still a rock solid ecosystem.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#138

Post by TheRealDunkirk »

pjmlp wrote: post #134
TheRealDunkirk wrote: post #106

Earlier quoted context omitted.

It's amazing to me that so many people make "stuck with Rails" arguments in the enterprise. It's extraordinarily clear to me, having worked in 3 Fortune 250's, that the single, most-attractive-to-management feature of alternative stacks like Java and Javascript is... dun dun dun!... MASSIVE project bloat! Justifying huge teams and years of development time, leading to huge budgets and personal power within the compan…

So where are those two projects now for all of us to amaze ourselves with the power of Rails?

Locked under company copyright, and not shareable, of course.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#139

Post by ksec »

DylanSp wrote: post #111

I'm probably misinterpreting the numbers, but it sounds like the 3.3 interpreter also got some significant performance improvements - if 3.3 YJIT got a 13% speedup compared to 3.2 YJIT and a 15% speedup compared to 3.3 interpreter, that sounds like the 3.2 YJIT has only slightly better performance than the 3.3 interpreter. Is that interpretation correct? If so, what were the improvements in the 3.3 interpreter, or wa…

That is exactly my question as well. Why would I want YJIT if it is only 15% faster than normal Ruby? Given the memory overhead.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#140

Post by p8 »

pjmlp wrote: post #135
p8 wrote: post #110

Earlier quoted context omitted.

So where are the Shopify's of that era build on Struts and JSF?

Amazon.

Amazon was founded in 1994, that's not the same era.

Ruby didn't even exist back then and was released a year later. Rails was released in 2004. Shopify was founded in in 2006, 12 years after Amazon.

Post reply on HN