Don't get too excited. This is a micro-benchmark and not representative of what most real world apps will see.
A benchmark of something the scope of a typical rails app is likely to be much much less. Earlier descriptions of MJIT mention benchmark tests that were only ~11% improvement until the benchmark was "tuned" for the JIT. [1]
If you're modifying the the benchmark specifically for the JIT, it's not really a valid benchmark IMHO.
This is a fantastic result. The main issue with Ruby has always been the tradeoff of speed for an expressive and powerful language. In my experience the ecosystem around Rails is amazingly productive vs other languages and getting this much of a speed increase makes choosing it even more viable than it was already. Excited to see where Ruby and Rails go from here.
I never thought we'd get to the 3x of the 3x3 project for ruby 3, but looks like things are well beyond that already - which is great!
This should effectively kill the "ruby is slow" misnomer. One may find other languages better suited for certain particular uses, but this speed increase great expands the applicability of Ruby in the greater problem space.
Just because Ruby & Ruby on Rails have ceded popularity to javascript, does not mean that either have stopped improving. We usually abandon frameworks and languages because they have not kept up with the times or we outgrow them, but as time passes a ruby/rails stack becomes an even more effective approach to software development. With ActiveStorage and talk of push notification support built-in, and now this 6x(!) speed increase on 2.6 (and we're not even at ruby 3 yet!) makes for an effective one-man-band framework that normally require a whole team to deliver on. Amazing.
For someone who doesn't use Ruby what changes contribute to this? Is it just the JIT implementation or are there other factors? Is this reflected in real-world usage or only under certain loads, which this benchmark favors?
From the benchmark it looks like the JIT causes the lion's share of the improvement, since trunk (which will presumably become 2.6.0 going by the title) without JIT is 5.7x slower than with.
Good job! Ruby has always been a wonderful language from the get-go, and its influence on developers and software development are everywhere. The only thing anyone could really complain about was the performance (and the GIL, maybe variable scope, garbage collection and what have the Romans ever done for us, etc) so it’s time for the New Wave of cheaply-prototyped unicorns, minotaurs and sphinxes...
A benchmark of something the scope of a typical rails app is likely to be much much less. Earlier descriptions of MJIT mention benchmark tests that were only ~11% improvement until the benchmark was "tuned" for the JIT. [1]
If you're modifying the the benchmark specifically for the JIT, it's not really a valid benchmark IMHO.
[1] https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby...