Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

Post reply on HN
Print view View original

211–220 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#211

Post by brigandish »

jerf wrote: post #105
pantulis wrote: post #55

Earlier quoted context omitted.

It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's not a black-or-white decision.

Static typing was a nightmare (by modern standards) in the 1990s. Dynamic scripting languages were such a breath of fresh air that we were willing to pay the steep performance penalties without hardly a thought. Sort of like the saying "deleted code is debugged code", code that you actually write always performs better than the code you didn't write because it was too soul-sucking. But static typing languages, librar…

> Now I prefer even to "prototype" in static languages because the crossover to when they start providing me net benefit is around a week or so into my development process.

I've moved from Ruby to Crystal as much as I can, and at first I found it painful but now I appreciate the myriad complaints from the type checker. It's eliminated 99% of the specs I used to have to write.

Re: Ruby 3.2’s YJIT is Production-Ready

#212

Post by nateberkopec »

brigandish wrote: post #209
nateberkopec wrote: post #177

Earlier quoted context omitted.

TruffleRuby can’t run production Rails traffic today, and YJIT can.

The README states "TruffleRuby runs Rails". Anything specific?

It passes most (maybe all?) of the Rails test suite. But it can't run a randomly-selected production Rails application.

This was based on my conversations with Chris Seaton before his passing, about 6 months ago.

Re: Ruby 3.2’s YJIT is Production-Ready

#213

Post by int_19h »

hbrn wrote: post #203
bcrosby95 wrote: post #116

Earlier quoted context omitted.

Its all guts, feels, and "everybody knows" - but afaik there's been no hard proof about statically typed languages being superior to dynamically typed ones, or vice versa.

The big difference between the two that I noticed is that dynamic camp doesn't aggressively proselytize. And it doesn't shame infidels (it pities them, if anything).

Oh, it does. It just happened back when Python and Ruby were new and hot. These days, Rust is new and hot, and so ...

Re: Ruby 3.2’s YJIT is Production-Ready

#214

Post by int_19h »

pantulis wrote: post #154
jeltz wrote: post #107

Earlier quoted context omitted.

Nonsense. I used to be a professional Ruby developer and that is nowhere close to the truth. While I prefer static typing it is not hard at all to code in Ruby once you have learned the basics and I almost never used IRB other than when I was a beginner.

It's good practice to use irb to quickly check stuff or inspect the programmatic surface of a new library. But that's a Ruby feature that you don't have in other languages! In no way its mandatory to code inside irb. Most of my time was spent in Textmate or Emacs.

A REPL such as irb is by no means unique to Ruby. Even many statically typed compiled languages have them these days.

Re: Ruby 3.2’s YJIT is Production-Ready

#215

Post by samsquire »

This is awesome. I am impressed.

I recently wrote a toy compiler for x86_64. I use an external assembler.

My dream is to write a JIT compiler runtime.

https://GitHub.com/samsquire/compiler

My understanding is that you generate machine code and then mprotect the code to be executable then jump to the void * as a function pointer to execute generated instructions.

What I would like to understand more is tracing compilers and how they optimise hot loops. And how they deoptimise and optimise at runtime based on runtime information.

Re: Ruby 3.2’s YJIT is Production-Ready

#216

Post by int_19h »

v3ss0n wrote: post #158

Python have a 99% compatible jit implementation called PyPy and nobody much know about it. It was production ready since 5 years ago but ignored by mainstream. It is 400% faster than vanilla python on average and Guido and MS is working on for a few percent gain instead of promoting it or eventually making it default. PyPy.org

"On average" is mostly meaningless because it depends so much on the kind of code you use it with that you need to do your own measurements to judge. I've seen a 30% improvement on one project, 200% on another, and none at all on yet another.

Re: Ruby 3.2’s YJIT is Production-Ready

#217

Post by hbrn »

int_19h wrote: post #213
hbrn wrote: post #203

Earlier quoted context omitted.

The big difference between the two that I noticed is that dynamic camp doesn't aggressively proselytize. And it doesn't shame infidels (it pities them, if anything).

Oh, it does. It just happened back when Python and Ruby were new and hot. These days, Rust is new and hot, and so ...

I do remember dumping on Java back in those days, not so much on static typing itself. Seems like those were mostly language wars: Python vs PHP, Python vs Java, Ruby vs PHP, etc.

It might be just anecdotal, but I noticed people often say that writing in Ruby makes them feel happy.

Static typing (or functional programming, or TDD) doesn't seem to make people happy. It makes them feel superior.

Whether it truly makes them superior, or just taps into their insecurities is an open question.

Re: Ruby 3.2’s YJIT is Production-Ready

#218

Post by nickjj »

simantel wrote: post #27
jrochkind1 wrote: post #13

Earlier quoted context omitted.

> I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly inco…

Also worth noting that the Ruby 3.2 Docker image can't run with YJIT yet, so if your production setup is in a container, it's most likely not using YJIT. GitHub issue link here: https://github.com/docker-library/ruby/pull/398

It was supported immediately for Alpine based images because rustc 1.60+ was available in that distro.

Initially when 3.2 was released Debian based images didn't support it because Bullseye ships with a version of rustc that's too old to compile YJIT.

But https://github.com/docker-library/ruby/commit/6db728e addressed this a few days ago by installing a pre-compiled version of rustc straight from Rust and YJIT is available in Debian now.

You can confirm if it's available to use by running:

    $ docker container run --rm ruby:3.2.0-slim-bullseye ruby --enable-yjit -v
    ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [x86_64-linux]
If it weren't available then you would get an unknown argument error.

Re: Ruby 3.2’s YJIT is Production-Ready

#219

Post by int_19h »

hbrn wrote: post #217
int_19h wrote: post #213

Earlier quoted context omitted.

Oh, it does. It just happened back when Python and Ruby were new and hot. These days, Rust is new and hot, and so ...

I do remember dumping on Java back in those days, not so much on static typing itself. Seems like those were mostly language wars: Python vs PHP, Python vs Java, Ruby vs PHP, etc. It might be just anecdotal, but I noticed people often say that writing in Ruby makes them feel happy . Static typing (or functional programming, or TDD) doesn't seem to make people happy. It makes them feel superior . Whether it truly make…

YMMV. I used to be very gung-ho about dynamic typing 10 years ago. Since then, my experience using it in a fairly large Python code base is that it doesn't make me happy, and the code patterns that make it workable tend to be very similar to how statically typed code would look anyway.

Ruby specifically is a separate question IMO because it has a lot of convenience features that are kinda orthogonal to the whole typing debate. Crystal is a good example of how you can retain those in a statically typed language.

Re: Ruby 3.2’s YJIT is Production-Ready

#220

Post by ironick09 »

brigandish wrote: post #208
xfalcox wrote: post #175

Earlier quoted context omitted.

You can enable YJIT and get a ~30% speedup by passing an extra environment variable to your Docker container. Moving away from CRuby to an alternative Ruby is a lot harder than that. Also Oracle.

> Moving away from CRuby to an alternative Ruby is a lot harder than that. In what way? Truffleruby passes over 97% of CRuby's specs and it runs on my command-line without any problems so far. It was easy to install too. I'm sure if I dig into those failing specs I'll find something but will it be important? I'd love to know.

It’s probably not hard for someone to run the interpreter and try a few things out - but large private code bases are where the struggles would begin I imagine.
Post reply on HN