YJIT: Building a New JIT Compiler for CRuby (opens in new tab)

I kind of think it would be more accurate to describe it as Sorbet compiler. Since it only works on a subset of Ruby ( Which Stripe runs on ).

But it is AOT! That means we could at least have some widely adopted and supported AOT solution.

I went to a talk by the (one-of?) leads behind Truffle and it looks really great, but getting all C libs to work reliably did seem to be a big issue.

The performance of Truffle is amazing when it works, but I think the compatability issue is going to hamstring it for a while.

This one is Oracle free :)

>I mean JS used to be slowish and until V8 came

There was JS Engine performance war before Chrome v8 came around. From JavaScriptCore to whole bunch of monkeys [1] from Mozilla. Google v8 just makes the competition super heated and every one of them were working around the clock trying to out compete each other on the latest benchmarks. ( That was the dark era when Browser only cares about JS benchmarks scores and nothing in real world )

It would not be an exaggeration to say all the man hours on JS JIT is more than Perl, Ruby and PHP's VM combined. That is why I often said Ruby is the only Top 10 language that gets little to no funding and backing of FAANG. So both YJIT and Sorbet are much needed contribution from Stipe and Shopify. Along with help from Github and Gitlab ( hopefully :) ).

The VMs that gets more resources than JS would be JVM and .Net. And JVM is a monster on its own. Easily a multi billion dollar of investment over all these years. Or something using less man hours and resources like LuaJIT. But then Mike Pall is a super human.

[1] https://en.wikipedia.org/wiki/SpiderMonkey

Python does, via pypy [1], which has very impressive performance and Python3 support. However, there are some subtle drawbacks, e.g., building from source takes hours instead of seconds (like CPython), and C extensions are slower. Still, the performance of pypy on a wide range of pure Python microbenchmarks is extremely impressive, and comparable to V8 (I've been collecting such benchmarks at [2] lately).

[1] https://www.pypy.org/

[2] https://github.com/sagemathinc/JSage/tree/main/packages/jpyt...

Not sure - Google pouring money into faster JavaScript execution is probably a big reason, but maybe JavaScript's comparative simplicity and fewer built-ins make it easier to get more out of it?

Actually Ruby 2.5 w/o MJIT is faster than Python 3.8 and Perl 5.28 at prime number crunching (using quite mundane stuff: basic math + for loops + hash/dict + array operations) but Node/V8, Dart and Luajit are still an order of magnitude faster along with the added JIT penalty. Racket, Julia and Lua are somewhere in between. The story used to be quite different two years ago, with Ruby being slower than both Perl and Python.

IMHO, basically money & talent. Google hires the best and pours money into V8. The very best developers can work full time and without any distractions. Also, Google is personally invested in making Chrome fast. Not to mention the vast sea of developers Google has and can throw at any project.

Other languages struggle in this regard. Comparatively I imagine far fewer developers working full time on Ruby/Python, not to mention they would have budget constraints to hire and retain talent.

How many? Quite a lot, actually, I personally can count at least 10 attempts at JIT-ing Ruby.

The are 2 main reasons for that.

1. For a good decade - from ~2005 to ~2015 - Ruby was among the most often used tech stacks at startups, and any performance work on Ruby (of which two major fronts were GC and JIT compilation) were perceived as extremely impactful and attractive.

2. Ruby is actually one of the most if not the most dynamic and complex programming languages out there and thus is one of the most challenging to build a runtime for and optimize. It became a de-facto benchmark for JIT research (among the more conventional Java). Over the years many vendors invested into Ruby compilers to push their underlying VM technology. Microsoft sponsored IronRuby to improve their .NET runtime, Sun sponsored JRuby and Oracle sponsors TruffleRuby.

As for progress, the biggest roadblock to Ruby JITs adoption has always being Rails. Rails uses a lot of Ruby features and pushes the language pretty far. Thus, you can't run Rails without your Ruby implementation being very complete and very MRI-compatible (MRI is the default Ruby implementation).

Plus, Rails uses Ruby in a way that is defeats virtually all best practices to produce a JIT-friendly code. Thus, there's no JIT compiler that offers any performance improvements for Rails apps - and in truth there might not be one ever. In fact, YJIT is exciting because it's the first JIT-compiler that seems to offer some speedups for at least a fey Rails benchmarks. People follow it closely, because these speedups might be a fluke, and as the compiler becomes more compliant, they may disappear (that happened in past with some JITs).

Other people tackle this problem by switching away from Rails to other frameworks. AFAIK Stripe themselves don't use Rails in most of their code, so they might benefit a lot from this work even without big improvements for common Ruby benchmarks (language shootout, Techempower, Discource benchmarks).

There have been at least 16 attempts to write a compiler for Ruby!

I’m giving a talk about the history of compiling Ruby at RubyConf.

Too late how? Shopify isn't doing this so all the Node people will come back to Rails. They're doing it to run their platform faster and eventually save money. They also like Ruby. Also - for the companies running on Ruby (there are still quite a few) this is big news.