This number is from a production workload with a significant chunk of IOs.

If you look at CPU bound micro-benchmarks like most similar announcements uses, you easily get into the 3x territory: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...

> “get into the 3x territory”

Where are you seeing 3x improvement?

Because even this graph from your article doesn’t show that, unless you’re comparing JIT vs non-JIT. But JIT has existed for awhile now (not new in 3.3).

https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...

In the yjit-bench suite, there are a number of micro benchmarks that had a 2-3x gain between 3.2 and 3.3: https://speed.yjit.org/stats-timeline.html

But my point is that the YJIT team never really communicate numbers from synthetic benchmarks, it's very focused on real world workloads.

Synthetic benchmarks are used internally, but mostly to optimize a specific pattern that was identified as a common hotspot.

All this to say this figure you quote is not to be directly compared to many similar announcements from other projects or benchmark suites.

Now if you still think it's not good enough, I encourage you to try your hand at it to see how much of an accomplishment that really is.