Tenderjit – A JIT for Ruby Written in Ruby(github.com)
github.com
Tenderjit – A JIT for Ruby Written in Ruby
https://github.com/tenderlove/tenderjit
46 comments
There was actually an existing, similar in concept, Ruby JIT, Rhyzome: https://github.com/chrisseaton/rhizome.
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.
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/
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.
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.
He's also making cheese!
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
His handle and domain name are super gross. Every time I visit his website, woth its icky tagline, I feel the need to disinfect my eyeballs
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.
"Join STEM and build for the future! Don't let the cliche and sexist past our industry is known by prevent you from succeeding!"
"Oh, you want to learn about low-level Ruby internals? I know a good blog... but, oh, about that.."
"Oh, you want to learn about low-level Ruby internals? I know a good blog... but, oh, about that.."
no one is stopping them from being garbage collectors or construction workers either.
maybe they just arent interested in STEM, as a whole. is that so bad?
maybe they just arent interested in STEM, as a whole. is that so bad?
Love seeing people make ruby 3.0+ faster!
Long live Ruby. It has never lost wide interest; however, it seems there's a king of resurgence around it recently.
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.
Can you share any code? I'm interested in optimising interesting Ruby demos.
Yeah, here's my main sound repo: https://github.com/mike-bourgeous/mb-sound
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.
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.
I guess you might find this interesting, https://twitter.com/headius/status/1261024699837890561
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!
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!
arstechnica wrote an article on server side languages and ruby was the only one aside from php that had much growth!
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.
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?
You can write a JIT that generates C code and calls the system's C compiler: https://duckduckgo.com/?q=ruby+"MJIT"
Oh well I never thought of it, nor read of it. Need to go back to books. Thanks for sharing!
It’s x86-64 only. A quick look at the https://github.com/tenderlove/tenderjit/blob/main/lib/tender... linked from the README reveals heavy references to x86-64 registers. The “Fisk” library used appears to be a x86-64 assembler in Ruby.
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.
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.
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.
Thanks for the interest!
Thanks for the interest!
I immediately want to test it out and see if I can get it to JIT itself. I feel evil.
Hi!
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.
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.
Something like http://kleinvm.sourceforge.net/ ?
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.
I love the Go compiler for speed.
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.
> 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).
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).
> I love the Go compiler for speed
Wait till you find out what the Go compiler is written in then.
Wait till you find out what the Go compiler is written in then.
Only for the build time to take a nosedive when they ditched C.
Explained here, by a factor of 2.
https://golang.org/doc/go1.5#performance
Explained here, by a factor of 2.
https://golang.org/doc/go1.5#performance
True, and as they explain,
> 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.
> 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.
In one of the fastest languages, X==A :-)
If you want to know more about WHY people write compilers for X in X, check out https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
It's not just liking the language or eating their own dogfood.
It's not just liking the language or eating their own dogfood.
Maybe but it's a great learning tool for those of us that know ruby but are less familiar, with say, C or Rust.
Well, you could apply the futamura projections and have “X written in Y compiles to Z”
Love the approach, kudos for trying it out.
Why are we still talking about Ruby?
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