6 ms·

The Ruby on Rails Podcast Episode 508: YJIT with Maxime Chevalier-Boisvert

95 points by unripe_syntax 3y ago

jacques_chester 3y ago
For those wondering why an interview with Maxime is interesting: Maxime coinvented the Basic Block Versioning approach to JITs[0] during her studies. It's the basis for YJIT, which has landed big speedups for the C Ruby implementation over the past few years. Disclosure: I used to work in a team adjacent to Maxime's. [0] https://arxiv.org/abs/1411.0352 https://arxiv.org/abs/1411.0352
- panic 3y ago
  Who was the other coinventor? I thought Marc Feeley was just her advisor here.
  - maxime_cb 3y ago
    Yes, Marc Feeley was my PhD advisor. We came up with the original idea together. I also see it as a development of the work I did in my M.Sc. thesis on type-driven versioning of functions. Basic block versioning is lazy, type-driven tail splitting of code.
    - panic 3y ago
      Ah, my mistake then, thank you for clarifying!
jjice 3y ago
Wow, I didn't realize there's a Ruby on Rails podcast that's been running for 15 years. That's seriously impressive. Sometimes I wish I was programming during the RoR hay days. It just seems like a damn fine framework and it's got a real cult (in a good way) following.
- MrFantastic 3y ago
  The "flexibility" of Ruby and RoR made code much harder to maintain than Python. Who cares if you can save 10 minutes coding a page if it takes you an hour to figure out what's happening on with that code.
  - weatherlight 3y ago
    Citations needed.
  - AlchemistCamp 3y ago
    Python is basically the same thing, just slightly less thoroughly OO and with a different syntax.
- thiago_fm 3y ago
  I think Ruby Rogues has been running as well for a similar timeframe. The Ruby community has always been awesome and lively!
- thedanbob 3y ago
  I started on Rails in 2011, just before the release of 3.1 (when they switched the default JS framework from Prototype to jQuery!). I basically "grew up" as a programmer on Rails. It's cool to look back and see how Rails, and Ruby itself, has matured over time. Each major release is easier to migrate to than the last and covers more use cases out of the box.
- mostlysimilar 3y ago
  Rails and Ruby are both better today than they have ever been. What's stopping you from picking it for your next project?
- gavinray 3y ago
  I was programming Rails during the Heyday. I don't miss it one bit. Yes, you can build things quickly, "rails g scaffold" was quite a tool. But the level of discipline required to keep a large Rails codebase from turning into spaghetti is not to be underestimated. Plus, because of Ruby's flexibility, a bunch of functionality is sort of "magic pudding" and happens via extension and meta-method sort of things. This makes things like Ctrl+Click being the source of truth and being able to generate some sort of ERD-diagram in your IDE of everything that touches another thing difficult to implement. I also don't miss dynamic types in the slightest. Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though.
tiffanyh 3y ago
Off-topic: I wonder why the site insists on using the super long domain name of "therubyonrailspodcast.com" when (presumably) they own "railspodcast.com" since it redirects to the longer url. Even if it's for legacy reasons, it seems like podcasts of all things would be the easiest to 301 redirect (the longer url to the shorter).
BasilPH 3y ago
I made a transcript: https://www.withfanfare.com/p/hacker-news-collection/episode-508-yjit-with-maxime-chevalier-boisvert https://www.withfanfare.com/p/hacker-news-collection/episode... It might be a bit rough around the edges, since I didn't do any manual editing.
czbond 3y ago
Where would the YJIT 3.3 performance improvements be mostly seen? (eg: task type) edit: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-while-using-less-memory/ https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w... edit 2: YJIT or truffle these days?
- maxime_cb 3y ago
  YJIT is optimized primarily for web workloads. We look at rails performance a lot, but also at various other libraries that are used in that context. If you look at the headline benchmarks at https://speed.yjit.org https://speed.yjit.org, it will give you an idea of what we're mostly focused on. This is in contrast with academic compiler project, which often focus on microbenchmarks and code that is very different from the code users actually run in practice. YJIT or TruffleRuby: I'm biased being that I work on YJIT. The nice thing about YJIT is that it's likely to work out of the box, and just be a matter of calling `ruby --yjit` to turn it on. It will probably use a lot less memory than TR, and it's probably more likely to deliver the result you're looking for at this time (speed boost, no hassle). That being said, for some small or specialized applications, TruffleRuby could deliver much higher peak performance. If you don't restart your server often and you have a lot of memory available, then maybe you don't care about warm-up time or memory usage, and TruffleRuby could be the right tool for you. Feel free to run your own benchmarks and also to blog about the results (though if you do, please share as much details about your setup as possible).
  - czbond 3y ago
    @maxime_cb - Great answer, thank you for the detailed response.

95 points by unripe_syntax 3y ago

For those wondering why an interview with Maxime is interesting: Maxime coinvented the Basic Block Versioning approach to JITs[0] during her studies. It's the basis for YJIT, which has landed big speedups for the C Ruby implementation over the past few years. Disclosure: I used to work in a team adjacent to Maxime's. [0] https://arxiv.org/abs/1411.0352 https://arxiv.org/abs/1411.0352

panic 3y ago
Who was the other coinventor? I thought Marc Feeley was just her advisor here.
- maxime_cb 3y ago
  Yes, Marc Feeley was my PhD advisor. We came up with the original idea together. I also see it as a development of the work I did in my M.Sc. thesis on type-driven versioning of functions. Basic block versioning is lazy, type-driven tail splitting of code.
  - panic 3y ago
    Ah, my mistake then, thank you for clarifying!

jjice 3y ago

Wow, I didn't realize there's a Ruby on Rails podcast that's been running for 15 years. That's seriously impressive. Sometimes I wish I was programming during the RoR hay days. It just seems like a damn fine framework and it's got a real cult (in a good way) following.

MrFantastic 3y ago
The "flexibility" of Ruby and RoR made code much harder to maintain than Python. Who cares if you can save 10 minutes coding a page if it takes you an hour to figure out what's happening on with that code.
- weatherlight 3y ago
  Citations needed.
- AlchemistCamp 3y ago
  Python is basically the same thing, just slightly less thoroughly OO and with a different syntax.
thiago_fm 3y ago
I think Ruby Rogues has been running as well for a similar timeframe. The Ruby community has always been awesome and lively!
thedanbob 3y ago
I started on Rails in 2011, just before the release of 3.1 (when they switched the default JS framework from Prototype to jQuery!). I basically "grew up" as a programmer on Rails. It's cool to look back and see how Rails, and Ruby itself, has matured over time. Each major release is easier to migrate to than the last and covers more use cases out of the box.
mostlysimilar 3y ago
Rails and Ruby are both better today than they have ever been. What's stopping you from picking it for your next project?
gavinray 3y ago
I was programming Rails during the Heyday. I don't miss it one bit. Yes, you can build things quickly, "rails g scaffold" was quite a tool. But the level of discipline required to keep a large Rails codebase from turning into spaghetti is not to be underestimated. Plus, because of Ruby's flexibility, a bunch of functionality is sort of "magic pudding" and happens via extension and meta-method sort of things. This makes things like Ctrl+Click being the source of truth and being able to generate some sort of ERD-diagram in your IDE of everything that touches another thing difficult to implement. I also don't miss dynamic types in the slightest. Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though.

tiffanyh 3y ago

Off-topic: I wonder why the site insists on using the super long domain name of "therubyonrailspodcast.com" when (presumably) they own "railspodcast.com" since it redirects to the longer url. Even if it's for legacy reasons, it seems like podcasts of all things would be the easiest to 301 redirect (the longer url to the shorter).

BasilPH 3y ago

I made a transcript: https://www.withfanfare.com/p/hacker-news-collection/episode-508-yjit-with-maxime-chevalier-boisvert https://www.withfanfare.com/p/hacker-news-collection/episode... It might be a bit rough around the edges, since I didn't do any manual editing.

czbond 3y ago

Where would the YJIT 3.3 performance improvements be mostly seen? (eg: task type) edit: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-while-using-less-memory/ https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w... edit 2: YJIT or truffle these days?

maxime_cb 3y ago
YJIT is optimized primarily for web workloads. We look at rails performance a lot, but also at various other libraries that are used in that context. If you look at the headline benchmarks at https://speed.yjit.org https://speed.yjit.org, it will give you an idea of what we're mostly focused on. This is in contrast with academic compiler project, which often focus on microbenchmarks and code that is very different from the code users actually run in practice. YJIT or TruffleRuby: I'm biased being that I work on YJIT. The nice thing about YJIT is that it's likely to work out of the box, and just be a matter of calling `ruby --yjit` to turn it on. It will probably use a lot less memory than TR, and it's probably more likely to deliver the result you're looking for at this time (speed boost, no hassle). That being said, for some small or specialized applications, TruffleRuby could deliver much higher peak performance. If you don't restart your server often and you have a lot of memory available, then maybe you don't care about warm-up time or memory usage, and TruffleRuby could be the right tool for you. Feel free to run your own benchmarks and also to blog about the results (though if you do, please share as much details about your setup as possible).
- czbond 3y ago
  @maxime_cb - Great answer, thank you for the detailed response.