Compiling Ruby to Machine Language

This sounds like Microsoft when they moved from VB6 to VB.Net. At least they have a good thing going with C# though.

VB6 was quite an interesting beast. You could do basically everything that you could do in languages like C/C++, but in most cases, you could churn out code quicker. This even extended to DirectX/Direct3D! For Web pages? ASP Classic.

The tl;dr is that I really wish that ease of development were prioritized along with everything else. One of the reasons I like Ruby is the elegance of the language and ease of using it.

Note that I've been using it since the mid 2000s or so, but not exclusively (both it and VB6 defined my career, however). C# is my second most favorite.

If Ruby had the GUI design tools VB6 had, it would be interesting to look at the popularity stats

Anyway, I'm rambling, so there is that. ;)

https://en.wikipedia.org/wiki/RubyMotion

Yes that's something I want to dig into and explore in this chapter... when exactly does Ruby's JIT compiler activate and optimize our code? And you're right: since Ruby will JIT blocks as if they were separate function many loops will be optimized using this simple heuristic.

This basic algorithm is called "Basic Block Versioning." Maxime Chevalier-Boisvert from Shopify has some great presentations online about this; for example [1].

I believe ZJIT, the newer JIT engine, uses a different approach. I'm exploring that now.

[1] https://www.youtube.com/watch?v=zO9_uTaELCw — RubyConf 2021 - YJIT - Building a new JIT Compiler inside CRuby by Maxime Chevalier Boisvert.

I did recent testing that showed it to be faster than Python but slower than Lua: Lua, Ruby and Python ran my benchmark in 12, 18 and 25 seconds respectively.

This was measured using the latest versions of each language (5.4, 3.4 and 3.13), using only the interpreters, no JITs.

> I haven't used it in about 10 years

It looks like the relative performance of the three languages hasn't changed much since I did a similar benchmark with Ruby 2.0, about that long ago.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

So it's "fast". There's plenty more that can be done to make it much faster still, but even before yjit, MRI had gotten pretty decent.

Compared to itself from 10 years ago I think it's made great progress. Can't put a number to it but I wouldn't be surprised if it's 2x or 3x faster, especially with the "new" JIT (YJIT) enabled. The JIT comes with a memory usage penalty though. You can see some benchmarks over time (although not going back as far as 10 years) at https://speed.ruby-lang.org

1: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

AOT compiling Ruby is hard. I'm trying [1] [2].

Sorbet would be in a good position because part of the challenge of making it fast is that Ruby has a lot of semantics that are rarely used but that makes making compiled Ruby fast really hard. E.g. the bignum promotion adds overhead to every single operation unless you can prove invariants about the range of the values; the meta-programming likewise adds overhead and makes even very basic operations really expensive unless you can prove classes (or individual objects) aren't being mucked with...

So starting with type checking is an interesting approach to potentially allow for compiling guarded type-specific fast paths. If my compiler ever gets close enough to feature complete (it's a hobby project, so depends entirely on how much time I get, though now I also justify more time for it by using it as a test-bed for LLM tooling), it's certainly a direction I'd love to eventually explore.

[1] https://hokstad.com/compiler (not updated for a decade)

[2] https://github.com/vidarh/writing-a-compiler-in-ruby/ (updated now primarily by Claude Code; it's currently focusing on actually passing RubySpec and making speedy progress, at the cost of allowing some fairly ugly code - I do cleanup passes occasionally, but most of the cleanup will be deferred until more passes)