Really happy to see Pat keeping it up! His first Ruby under a Microscope book but also his blog posts are amazing and a major source of inspiration for me. I did meet him personally in a Euruko conference. Such a great person.
IIRC MacRuby used to compile to native code on OSX using LLVM, and was supposed to support native OSX APIs and Objective-C frameworks. It always seemed like a neat idea, and a slick integration, but I guess Apple moved to Swift instead.
I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.
The creator of MacRuby left Apple, and created RubyMotion. It's continued by different people, but still around, though it seems the main focus of the people involved now is DragonRuby (a game-focused Ruby implementation)
I find that using C as an intermediate step really helps conceptualize this process. It can be tough to imagine how to represent a language like ruby as C. Essentially you have to start from the point that everything is an object and method calls on objects, then build up from that. Then C to assembler is more manageable. Ymmv.
> To find hot spots, YJIT counts how many times your program calls each function or block
At first glance this seems too simple. Compare it to JavaScript JITs, which IIRC can compile hot spots even in functions that are only called a few times (e.g. those that contain heavy loops) via on-stack replacement. (Although I’ve also heard on-stack replacement called a “party trick” - more useful for optimising benchmark scores than for real code.)
But on the other hand, Ruby’s language design might help here. Idiomatic Ruby uses blocks for loop bodies - so can Ruby JITs optimise long-running loops by treating the loop body as just another function?
Once a YJIT block executes enough times to warrant compilation, how does this system keep track of which types to compile for? Each block is tracking how many times it's entered, but not how many times it's entered for int or float or whatever types; so in the given example how would Ruby handle the compilation of the "opt_plus" stub when the input types may vary?
And by what process is the correct compiled block used depending on the input variable types?
Glad to see that Ruby Under a Microscope is still being updated. It’s an essential read for anyone who wants to understand how Ruby works internally — and I truly enjoy reading it.
It seems to be gone from the repo, and doesn't seem to be worked on any more? A shame.
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.
[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)
Making dynamically typed, single threaded languages faster via JIT usually comes at the cost of a significant increase in memory consumption which for businesses smaller than Shopify is a much more significant factor.
Is it? Smaller business usually comes with smaller applications. Most cloud and hardware vendors give you about 4GiB of RAM per core, maybe only 2 when using "CPU optimized instances", that's huge and leave plenty of space for a couple hundred MB of JITed code.
Agreed. In Java land, if I understand correctly the OpenJ9 JVM can (or at least could) beat HotSpot in memory consumption, while being slightly behind in execution times. It still sees only limited adoption. This may be just because it's seen as an 'alternative' option, less trustworthy than HotSpot, but it also seems to indicate the HotSpot developers aren't prioritising memory consumption.
While not related to compiling Ruby, I found the book "Enterprise Integration with Ruby"[0] to be enlightening regarding using it outside of web applications.
Great clear explanation of how YJIT and ZJIT work. The details on block compilation and counting make JIT internals more accessible to Ruby developers.
21 comments
[ 4.4 ms ] story [ 38.4 ms ] threadI haven't kept up with the evolving Ruby implementation internals, so I will sure as heck buy this new version of the book.
I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.
https://en.wikipedia.org/wiki/RubyMotion
At first glance this seems too simple. Compare it to JavaScript JITs, which IIRC can compile hot spots even in functions that are only called a few times (e.g. those that contain heavy loops) via on-stack replacement. (Although I’ve also heard on-stack replacement called a “party trick” - more useful for optimising benchmark scores than for real code.)
But on the other hand, Ruby’s language design might help here. Idiomatic Ruby uses blocks for loop bodies - so can Ruby JITs optimise long-running loops by treating the loop body as just another function?
And by what process is the correct compiled block used depending on the input variable types?
I haven't used it in about 10 years
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp...
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)
https://bell-sw.com/announcements/2022/06/28/hotspot-vs-open...
https://eclipse.dev/openj9/performance/ (non-impartial source, of course)
0 - https://www.goodreads.com/book/show/624316.Enterprise_Integr...