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

81–90 of 158 posts

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

#81

Post by byroot »

cowsandmilk wrote: post #52
elif wrote: post #25

Earlier quoted context omitted.

That's like saying the leading F1 team is investing in optimizing side mirrors, therefore they believe side mirrors are the component with the most opportunity for improvement. The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. The "weakest link" belief is pure conjecture

> The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. Most companies don’t have unlimited budgets. Performance-oriented organizations profile and then spend money where profiling tells them to. Shopify isn’t hiring people to contribute to MySQL or Redis internals. They hired a full team to work on Ruby internals, not just creating YJIT,…

Disclaimer: I'm a member of the Ruby & Rails infrastructure team at Shopify and Ruby committer.

> Shopify isn’t hiring people to contribute to MySQL or Redis internals

You are not wrong, but the main reason is that contrary to Ruby, MySQL and Redis are used by a lot of huge companies and are themselves owned by companies with full time people on it.

In comparison Ruby is still mostly a volunteer ran project that receive little funding and effort relative to its importance.

As for why trying to make Ruby faster at all in the first place. It's not because it was too slow, it's mostly just that at our scale, the engineering time spent on optimizing the runtime pretty much pays for itself.

But that's nothing specific to Ruby, in most very large software companies you will find similar efforts. e.g. I remember Twitter had a team working on the JVM, etc.

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

#82

Post by fiedzia »

berkes wrote: post #50
wheels wrote: post #33

Earlier quoted context omitted.

Am I really going to have to get out the premature optimization quote? Most businesses fail. Those that don't fail, usually don't have interesting scaling issues. (You can go a really long way on a boring monolith stack.) So in most cases, whatever gets things out into the world and able to see if the business can be validated makes sense, and then you optimize later. A nonscalable stack that you can iterate on 50% f…

This hints at a false dichotomy. One that especially Ruby and Rails keep afloat. Productivity and Scalability(in performance sense) aren't opposites. Take Bash. Performs bad and is a guarantee for terrible productivity in a large category of software. But perfect for a niche. Take Java. Performs better than many, and allows for good productivity (if you avoid the enterprise architectures, but that goes for any langua…

> Productivity and Scalability(in performance sense) aren't opposites.

They often clash with each other. Rust for example is a lot less pleasant to debug than interpreted languages and that is a loss of productivity.

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

#83

Post by byroot »

stevebmark wrote: post #46
nindalf wrote: post #37

Earlier quoted context omitted.

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…

Rails was initially too slow for Github, so they forked it, didn't use "Rails" for a while [1], lost literal engineering years to upgrading it (same for Shopify), and now Github has an engineering department dedicated to working of the Rails master branch directly, which is huge engineering overhead and a problem and solution that shouldn't exist. Github co-founder Tom lamented using Rails at Github and has stopped u…

> Rails was initially too slow for GitHub, so they forked it, didn't use "Rails" for a while

That's a weird way of framing it.

They stuck with a fork of Rails 2.3 for a long time because the upgrade was deemed too costly, not because their fork was faster.

In the end their performance patches were either outdated or contributed upstream, and they are now on Rails main branch.

And while it was a fork, it was still largely "Rails".

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

#84

Post by p8 »

pjmlp wrote: post #65
moonchrome wrote: post #60

Earlier quoted context omitted.

C# in 2006 was a joke, probably worse than Rails in performance. This was the webforms era and old EF - meant for enterprise customers with a couple of hundred active users max... ASP.NET being a competitive/performant framework is a very recent development (since core basically which became usable past 2.0) Haskell, OCaml and D are niche languages, probably aren't mature enough now to use for a production system tha…

A joke is this comment. All of them were faster and used less resources than a very slow interpreted language, by having JIT and AOT compilers, state of the art GC and great IDE offerings, even the niche ones had better tooling (Leksah and Merlin, versus nothing).

Nobody cares about performance if you build a business application with a couple of users, a common use-case in 2005. The reason a lot of Java people jumped on the Rails bandwagon, was that an application that would take a month to build in Java with Spring/Hibernate, would take a day in Rails. See also: https://www.oreilly.com/library/view/beyond-java/0596100949/

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

#86

Post by byroot »

Alifatisk wrote: post #62
alberth wrote: post #18

TruffleRuby What's the current state of Shopify running TruffleRuby, given the tragic loss of Chris Seaton?

Is TruffleRuby compitable with Rails? If so, I wonder how much TruffleRuby would improve the performance and memory footprint. Especially with native images, I wonder how that would turn out.

> Is TruffleRuby compitable with Rails?

Rails proper, yes. Small rails app are generally drop-in compatible, but sizeable applications are likely to run in a few compatibility issues as most gems aren't tested against TruffleRuby.

> I wonder how much TruffleRuby would improve the performance and memory footprint.

The generally speaking Truffle is much faster at "peak" performance, but take very long to get there which makes it challenging to deploy.

It also uses way more memory, but it's partially offset by the fact that it doesn't have a GVL, so you get parallel execution with threads.

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

#87

Post by alberth »

lloeki wrote: post #59
alberth wrote: post #44

Earlier quoted context omitted.

No one disputes that Ruby is slow. But you picking “mirrors” in your analogy makes it sounds like a premature optimization. The reason why perf isn’t typically an issue with Rails is the design pattern is to leverage heavy caching. The use of caching is to address the slowness of Ruby.

The two major areas where caching is used in Rails are: - database queries - template rendering First one because round trip to db + running the query + allocating ORM result objects that otherwise get thrown away. Second one because allocating a ton of strings that get join'd and thrown away. > No one disputes that Ruby is slow. I am, because the blanket statement doesn't make sense without context. Also that view i…

> "Also that view is largely biased by the typical assumption that Ruby == Rails."

Given that the predominate / vast majority use case for Ruby is for web development and Rails being the dominate Ruby web framework ... it's a fair assumption & characterization for people to make that the Ruby == Rails use case.

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

#88

Post by dgb23 »

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 usage. Well until you make an effort to produce faster code.

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

#89

Post by pjmlp »

p8 wrote: post #84
pjmlp wrote: post #65

Earlier quoted context omitted.

A joke is this comment. All of them were faster and used less resources than a very slow interpreted language, by having JIT and AOT compilers, state of the art GC and great IDE offerings, even the niche ones had better tooling (Leksah and Merlin, versus nothing).

Nobody cares about performance if you build a business application with a couple of users, a common use-case in 2005. The reason a lot of Java people jumped on the Rails bandwagon, was that an application that would take a month to build in Java with Spring/Hibernate, would take a day in Rails. See also: https://www.oreilly.com/library/view/beyond-java/0596100949/

Some Java people did, there is a reason why Ruby is hardly used outside Rails, while Java rules most of the backend workloads, a mobile OS, and plenty of embedded workloads.

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

#90

Post by pjmlp »

KronisLV wrote: post #70
pjmlp wrote: post #67

Earlier quoted context omitted.

Stackoverflow is doing just fine with Windows Server. Java 6 would still blow the water out of Ruby's slow interpreter. Being pleasant isn't relevant for performance.

> Stackoverflow is doing just fine with Windows Server. Good for them! I guess it mostly depends on what you want to build your platform around, what the constraints are and what developer skillsets are popular in your market. > Java 6 would still blow the water out of Ruby's slow interpreter. Probably! I do recall major GC improvements starting from JDK 8 onwards, though when compared to Ruby even the older versions…

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