Is it called a plug if you're not shilling your own stuff? Well, anyway, if you're interested in this, you might also want to check out the recorded talks from the recent RubyKaigi.
Specifically, there's two really interesting talks on JIT:
- @maximecb's talk on YJIT - https://www.youtube.com/watch?v=PBVLf3yfMs8
This is closer to TFA, which as written in the README was an experiment the author worked on to get comfortable working on YJIT.
You can also check out the full con playlist here, but about half the talks in Japanese. They're pretty great, though, so if you do know enough Japanese to understand a bit, it might be worth your time. I personally recommend the opening keynote on Typeprof. The playlist: https://www.youtube.com/watch?v=xLeLW-p43bc&list=PLbFmgWm555...
It's good to see (IMO) the development of a JIT in a strict sense. I'm personally skeptical about the current approach (invoking a compiler separately).
On the other hand, it's important to know that JITs may take a long development time to be performant, and that they also complicate the performance profile of a virtual machine.
For those unaware: Aaron Patterson, aka tenderlove, is an influential and longstanding personality in the ruby community who’s made many significant contributions to Ruby and Ruby on Rails over the years.
He’s also a fantastic writer with a quirky style, highly recommend perusing his technical writing: http://tenderlovemaking.com/
I've had the pleasure of meeting Aaron at a number of ruby confs. He's supportive from the largest all the way to the smallest.
My personal favorite thing he'll do is ask conference speakers questions that make the speaker look good/best-light-possible. Something slightly technical/challenging, not fully covered in the talk but definitely something the speaker can handle.
To be able to do this consistently means he knows the topic better than the speaker themselves (at least this has been true when I've been there).
This is in contrast to people who ask "gotcha" questions. Spend 3-4 minutes showing off their knowledge and then finally getting to the question which is to stump the speaker. I hate these kinds of people at conferences the most.
His keynotes for RailsConfs are among the best talks I've ever watched. You always start off thinking it's just a comedy routine but by the end you know a lot more about Rails and Ruby than you did before.
Also, you may learn a bit about his other passions. I once learned a fair bit about curing meats (and probably something about ruby, I guess) from tenderlove at one of his talks.
I remember running into him at Rails at RailsConf in Phoenix a few years go and brought up his work on the Rails journey router, which is an NFA and his eyes lit up and was really excited that someone appreciated and understood that crucial yet under the hood part of the Rails core. It was enjoyable to talk and meet him.
Thank you so much, I really appreciate it. I really should blog more, I just haven't been "feeling it" lately. Words of encouragement really help, so thank you so much! :D
Yet you keep visiting his website despite how gross it is for you? Wow. That's some sacrifice you're making only to learn more about Ruby. I suggest the community gives you the Ruby Hero award wdyt? I'm not being totally sarcastic (only a bit) this shows some true grit on your part.
I've been using Ruby for sound lately. It's a good exercise in optimization because Ruby's not that fast for numeric computation (without calling out to a C lib like Numo), so your algorithms have to be reasonable. I'm hoping that the various JIT efforts will eventually let me run multiple realtime voices in my synthesizer, without having to drop down to C.
Right now is an exceptionally good time to be a Ruby developer. There are so many jobs that pay well and the Stripes and the Shopifys of the world are eating all the great talent up.
I've been noticing how many recruiters have been reaching out to me with Ruby jobs. I try and explain that "Yes, I did Rails 2.3 and 3.x back in the day - but that was a LONG time ago". That doesn't seem to dissuade them in the slightest. Now, on one hand, recruiters are a hungry bunch. On the other, it's interesting to me how big of a need this is right now.
My guess is, that a ton of this stuff was built in the 2010s. Those Ruby developers have moved on... leaving a ton of infra behind. There's a desperate need for folks to come in and get to work on it. Most of these shops say things like, "all of our new stuff is in Elixir, but we still need to support all the old Rails stuff"
All I can say is, it's probably better than coming in to support VB... or COBOL!
Apologies if this is obvious - is this ISA specific, or does it sit upon cross platform libs?
I ask because I'm *very* interested in this, but am working on ARM
Edit - just to be clear why I'm interested. For me it matters not if Ruby is slow, until it does, which is usually a very specific and obvious piece of code.
How can you do ISA-agnostic JIT unless you implement a separate backend for each ISA? I.e. is it possible to write a JIT in a generic way such that it'll work for a class of ISAs?
It's x86-64 specific right now. I'm interested in adding ARM support so I'll do that at some point in the future. My desktop is x86-64 and our production machines are as well, which is why I started with it.
Yes, that is one of my goals. I'll be presenting this project at RubyConf and I hope that I can get the compiler to compile itself by then. Breaking the circular dependencies is somewhat tricky, and you'll see some frankly ridiculous code inside TenderJIT that is meant to break those cycles.
Pet peeve of mine: "X compiler/interpreter/JIT written in X".
Case in point five years and 150k+ lines with the slow Scala compiler written in Scala (it's conceptual slow because of the language (types, implicits, ...) and it's accidentally slow because written in Scala (a slow language) on the JVM (slow startups and warmups)). I do get the coolness, the eat your own dog food, the I-write-X-in-X-because-I-obviously-like-X-otherwise-I-would-not-create-it-duh, but as a user I hate it.
I would prefer "X written in A" where A is the reasonably fastest language, e.g. Rust.
> it's conceptual slow because of the language (types, implicits, ...) and it's accidentally slow because written in Scala (a slow language) on the JVM (slow startups and warmups)
Do you have reason to believe that the accidental part matters to any significant degree?
I mean, C++ compilers are notorious for being slow and most of them are written in C++, which is one of the fastest languages around. It seems to me that, if your language is conceptually slow to compile, the fastest implementation language in the world won't fix that problem for you.
On the other hand, if your language is conceptually fast to compile, a slowish implementation language won't hurt much (I've never heard any complaints about the speed of `javac` for example though I've heard plenty of complaints about the speed of Java in general).
Readit News
Specifically, there's two really interesting talks on JIT:
- @k0kubun's talk on why Ruby's JIT was slow - https://www.youtube.com/watch?v=db3GHHllRyQ This is about the MJIT engine built into MRI.
- @maximecb's talk on YJIT - https://www.youtube.com/watch?v=PBVLf3yfMs8 This is closer to TFA, which as written in the README was an experiment the author worked on to get comfortable working on YJIT.
You can also check out the full con playlist here, but about half the talks in Japanese. They're pretty great, though, so if you do know enough Japanese to understand a bit, it might be worth your time. I personally recommend the opening keynote on Typeprof. The playlist: https://www.youtube.com/watch?v=xLeLW-p43bc&list=PLbFmgWm555...
The talks in this playlist are a bit out of order, so you can refer to the schedule: https://rubykaigi.org/2021-takeout/schedule
It's good to see (IMO) the development of a JIT in a strict sense. I'm personally skeptical about the current approach (invoking a compiler separately).
On the other hand, it's important to know that JITs may take a long development time to be performant, and that they also complicate the performance profile of a virtual machine.
He’s also a fantastic writer with a quirky style, highly recommend perusing his technical writing: http://tenderlovemaking.com/
My personal favorite thing he'll do is ask conference speakers questions that make the speaker look good/best-light-possible. Something slightly technical/challenging, not fully covered in the talk but definitely something the speaker can handle.
To be able to do this consistently means he knows the topic better than the speaker themselves (at least this has been true when I've been there).
This is in contrast to people who ask "gotcha" questions. Spend 3-4 minutes showing off their knowledge and then finally getting to the question which is to stump the speaker. I hate these kinds of people at conferences the most.
"Oh, you want to learn about low-level Ruby internals? I know a good blog... but, oh, about that.."
My guess is, that a ton of this stuff was built in the 2010s. Those Ruby developers have moved on... leaving a ton of infra behind. There's a desperate need for folks to come in and get to work on it. Most of these shops say things like, "all of our new stuff is in Elixir, but we still need to support all the old Rails stuff"
All I can say is, it's probably better than coming in to support VB... or COBOL!
I ask because I'm *very* interested in this, but am working on ARM
Edit - just to be clear why I'm interested. For me it matters not if Ruby is slow, until it does, which is usually a very specific and obvious piece of code.
I guess that’s to be expected with “pure ruby” — all the cross-insn backends you can use (Cranelift, LLVM) are written in not-Ruby.
Thanks for the interest!
Yes, that is one of my goals. I'll be presenting this project at RubyConf and I hope that I can get the compiler to compile itself by then. Breaking the circular dependencies is somewhat tricky, and you'll see some frankly ridiculous code inside TenderJIT that is meant to break those cycles.
Case in point five years and 150k+ lines with the slow Scala compiler written in Scala (it's conceptual slow because of the language (types, implicits, ...) and it's accidentally slow because written in Scala (a slow language) on the JVM (slow startups and warmups)). I do get the coolness, the eat your own dog food, the I-write-X-in-X-because-I-obviously-like-X-otherwise-I-would-not-create-it-duh, but as a user I hate it.
I would prefer "X written in A" where A is the reasonably fastest language, e.g. Rust.
I love the Go compiler for speed.
Do you have reason to believe that the accidental part matters to any significant degree?
I mean, C++ compilers are notorious for being slow and most of them are written in C++, which is one of the fastest languages around. It seems to me that, if your language is conceptually slow to compile, the fastest implementation language in the world won't fix that problem for you.
On the other hand, if your language is conceptually fast to compile, a slowish implementation language won't hurt much (I've never heard any complaints about the speed of `javac` for example though I've heard plenty of complaints about the speed of Java in general).
Wait till you find out what the Go compiler is written in then.
https://golang.org/doc/go1.5#c
It's not just liking the language or eating their own dogfood.