Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiling Ruby to machine language

patshaughnessy.net

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Compiling Ruby to machine language

#11

Post by eek2121 »

jlarocco wrote: post #5

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.

Typical. I may get absolutely destroyed for this, but being professionally proficient in a ton of languages, including Ruby and the ones I mention below, and the ones I'm about to mention:

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. ;)

Re: Compiling Ruby to machine language

#12

Post by shevy-java »

le-mark wrote: post #6

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.

I always found the steps to assembler harder. I'd wish we could have both a hardware interface that is resembled at the same level as the software - but super simple. With that I mean super-simple to understand and write; assembler is simple but not easy to understand. The complexity scales quickly. That's why C was successful - it was much easier to reason about the system in C than it was in assembler/assembly.

Re: Compiling Ruby to machine language

#14

Post by pat_shaughnessy »

hoten wrote: post #9

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 use…

That's the magic of YJIT, and what I'll describe in the rest of Chapter 4. YJIT uses a "wait-and-see" approach, and often defers compilation of the block/function until the actual types are provided by your program. And YJIT then keeps track of separate block versions based on the operand types, and can call the appropriate block version as needed.

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.

Re: Compiling Ruby to machine language

#15

Post by [deleted] »

pat_shaughnessy wrote: post #14
hoten wrote: post #9

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 use…

That's the magic of YJIT, and what I'll describe in the rest of Chapter 4. YJIT uses a "wait-and-see" approach, and often defers compilation of the block/function until the actual types are provided by your program. And YJIT then keeps track of separate block versions based on the operand types, and can call the appropriate block version as needed. This basic algorithm is called "Basic Block Versioning." Maxime Cheva…

[deleted]

Re: Compiling Ruby to machine language

#18

Post by blacksmith_tb »

eek2121 wrote: post #11
jlarocco wrote: post #5

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.

Typical. I may get absolutely destroyed for this, but being professionally proficient in a ton of languages, including Ruby and the ones I mention below, and the ones I'm about to mention: 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++, b…

What about something like Shoes[1]? I have played with it a little, just to make a simple UI to run some scripts I can run fine in a shell myself, but less-technical people may be too scared to fire up Terminal.app in order to do the same...

1: http://shoesrb.com/

Re: Compiling Ruby to machine language

#20

Post by vidarh »

pmarreck wrote: post #16

How fast is Ruby, lately? I haven't used it in about 10 years

I have a prototype ahead-of-time Ruby compiler. It's woefully incomplete - I've just recently picked it up again after years of inactivity, with heavy AI use to pursue rubyspec compliance (it's nowhere close). The point of mentioning that: MRI - the main Ruby interpreter - is fast enough that competing against it with an unoptimized compiler goes really badly unless you do a lot to optimise the garbage collector (I haven't yet).

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.

Post reply on HN