How I developed a faster Ruby interpreter (2022) | Hacker News Reader

How I developed a faster Ruby interpreter (2022)

developers.redhat.com

133 pointscyrc15 comments

Author is Vladimir Makarov creator of MIR: "a universal lightweight Just-in-Time (JIT) compiler known as MIR. The cornerstone of the project is a machine-independent medium-level intermediate representation (MIR)."

https://github.com/vnmakarov/mir

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

> YJIT was initially written in C but was rewritten in Rust to simplify the porting of YJIT to new architectures.

Curious. Why is that?

I don't remember exactly all the details, but the issue was something with developing for multiple platforms, with Rust you have traits, so it's easier to implement platform specific stuff with them, with C I don't know if there's anything similar, also you can think of all the other benefits that Rust brings.

From my experience once you learn Rust, it is very easy to build things and being confident that if it compiles it works, I think C also scares a lot of developers and it's harder to collaborate, because each code review must be carefully review by having a mental model of the entire app, while in Rust obviously that's the job of the compiler.

With C its macros and #define blocks. Not that fun.

with C people choose to use macros and define blocks because they want to, but it doesn't have to be done that way if you don't think that's fun. (Pushing back on choice of "fun"ness) Macros and define blocks turn into C code anyway.

I think those header files festooned with ifdef's are a nightmare, and it's the wrong choice, a type of premature optimization.

I'm familiar with various methods - and also what we observe in the wild across many FOSS projects. The #define, #ifdef, macro method is in the majority of what I see. And the examples of the "right way" are harder to find (now I wonder what GPT would suggest). None of those methods are fun for me anymore :(

I was simply pointing out that complaining about the C preprocessor is not complaining about C. You don't have to use the C preprocessor, you can do what it does in C, because that's what it does.

I agree it's possible to use C. Arguably C still lacking a better way of including files is a limitation of C as a language instead of only a complain on the preprocessor.

Just to add some clarification, I think what you mean is that one alternative way is to split implementations apart where necessary, and have separate translation units for various targets.

That can lead to a cleaner implementation without conditional compilation (or with conditional compilation restricted to picking the right files).

What other method(s) were you thinking of?

> What other method(s) were you thinking of?

runtime conditional configuration

anything Rust can do, C can do, C can even implement Rust. I'm not saying that you shouldn't prefer Rust, I'm sure it has nice features, i was just trying to clarify confusion about what C "requires" you to do. People use a lot of define blocks, but I don't. It's a throwback to wanting to minimize code size at compile time from back when that was important.

It's probably also partly because of Rust's "zero-cost abstractions" — you can create helper structs and wrappers, and not have to worry about it, unlike e.g. C++, which really likes to use object-oriented design patterns. And of course traits really do help with swapping out implementations depending on platform, but I think the real benefit is the use of structs instead of objects. They're no longer magic entities designed to be heap-allocated, they are just data — value types.

Oh and the borrow checker is good too.

Shopify have a full rundown on it here:

https://shopify.engineering/porting-yjit-ruby-compiler-to-ru...

(2022)

Added. Thanks!

I got excited thinking there was a new article about MIR, but this is an old post.

Reply on news.ycombinator.com