Tenderjit – A JIT for Ruby Written in Ruby
github.com
github.com
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.
This is more of a juxtaposition.
"Oh, you want to learn about low-level Ruby internals? I know a good blog... but, oh, about that.."
maybe they just arent interested in STEM, as a whole. is that so bad?
There's also an FFI wrapper for jackd: https://github.com/mike-bourgeous/mb-sound-jackffi
I'm certain there are still improvements that could be made to the APIs and to performance, so I'm not currently releasing these on rubygems.
Edit: I should really try these with TruffleRuby myself. I'll try to reply here if I do.
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.
Explained here, by a factor of 2.
> Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases.
And as of Go 1.17 that is pretty much forgotten waters.
It's not just liking the language or eating their own dogfood.