Compiling Ruby to machine language
patshaughnessy.net
Compiling Ruby to machine language
1–10 of 56 posts
Re: Compiling Ruby to machine language
#2Really 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.
Re: Compiling Ruby to machine language
#3[deleted]
Re: Compiling Ruby to machine language
#4I loved Ruby Under a Microscope when I first read it, and using that knowledge was able to have fun with some CTFs years ago.
I haven't kept up with the evolving Ruby implementation internals, so I will sure as heck buy this new version of the book.
Re: Compiling Ruby to machine language
#5IIRC 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.
Re: Compiling Ruby to machine language
#6I 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.
Re: Compiling Ruby to machine language
#7> 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?
Re: Compiling Ruby to machine language
#8Really 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.
What a lovely comment - thank you!
Re: Compiling Ruby to machine language
#9Once 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?
Re: Compiling Ruby to machine language
#10> 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 sco…
> Idiomatic Ruby uses blocks for loop bodies
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.