The Ruby on Rails Podcast Episode 508: YJIT with Maxime Chevalier-Boisvert | Hacker News Reader

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

therubyonrailspodcast.com

95 pointsunripe_syntax25 comments

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

Who was the other coinventor? I thought Marc Feeley was just her advisor here.

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.

Ah, my mistake then, thank you for clarifying!

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).

I made a transcript: 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.

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-w...

edit 2: YJIT or truffle these days?

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, 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).

@maxime_cb - Great answer, thank you for the detailed response.

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.

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.

Citations needed.

Python is basically the same thing, just slightly less thoroughly OO and with a different syntax.

I think Ruby Rogues has been running as well for a similar timeframe. The Ruby community has always been awesome and lively!

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.

Rails and Ruby are both better today than they have ever been. What's stopping you from picking it for your next project?

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.

you can use Django (python) with Types and the codebase will scale a bit larger, there are JITs available for Python too.

ctrl+click works great

can write simple Python code and not do anything crazy, works alright. up to around 30k lines I'd probably consider past the "prototype" phase though and would prefer a compiled language.

I would say Rails is still in its Heyday. I've been writing ruby since 1.8.7 and I'm constantly surprised by the frequency of major releases of rails, and the backward compatibility (Rails 3 -> 5 was hard). I completely agree about the discipline required to keep a large project clean, although I find that true across the board with large codebases.

I totally agree. The fact that it's not possible to determine the location of a method being called inside a file until it is run perfectly illustrates the problem with a hyper-dynamic language like ruby. It's a dream for people who love metaprogramming to do things magically, but a nightmare for anyone later inheriting that project.

I have a rant about it: https://bower.sh/on-autoloading

And don't get me started on the footgun that is ActiveRecord callbacks: https://guides.rubyonrails.org/active_record_callbacks.html

I didn't program RoR when it was hot, but I am in a RoR shop now. RoR is by far the easiest framework to jump into an existing project and find what is going on that I have seen, if anything its the opposite of hard to not turn into spaghetti. Comparing this to Spring, React, Node, ASP, etc. I would much rather do Ruby.

> Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though.

Why wouldn't you look at Phoenix LiveView, which inspired Laravel's Livewire, then? Elixir also gives you some other advantages you likely haven't encountered before if you haven't worked with Erlang or Akka.

I actually agree about large RoR codebases, the last few major ones I've seen were absolute dumpster fires and the solutions implemented to fix them, was more or less standard enterprise java patterns. So you ended up doing java anyway.

On the other hand, I'd say Elixir/Phoenix gives you exactly what you want these days and especially with the gradual type system, non-magic database ecto layer etc.

I started with Rails in 05, prior to the 1.0 release.

It was a whole new world for me. I had done BASIC, HyperCard, and C up to that point, and the whole idea of a web framework opened up my eyes. JavaScript, with prototype.js, was fascinating.

We didn’t even have database migrations yet, you just wrote your schema as a SQL file.

I moved to Sinatra a few years later, because at the time the “rails way” was really slow for a lot of things. I still use Sinatra to this day. Ruby is by far my favorite language, and sometimes I think it might be a time to get back into rails and see how far things have come.

rails nowadays is fantastic and is hitting its second wind.

Reply on news.ycombinator.com