yjit VS ruby

Ruby 3.2.0 is here and it offers some nice additions to the language. One of the most exciting new things is the addition of a compiler, YJIT. YJIT was created by the folks from Shopify and has been producion tested for a while, so it is safe to use in your environment. Some benchmarks show the difference in speed compared to Ruby without YJIT. I'll put some links if you want to know more: https://speed.yjit.org/ https://www.solnic.dev/p/benchmarking-ruby-32-with-yjit

> I’m curious how the impact affects development, deployment, etc.

YJIT is pretty much transparent in production, if not it's likely a bug.

When we tried MJIT in production to compare it against YJIT, it causes lots of request timeouts on deploy, because the JIT warmup would take 10 to 20 minutes and it's much slower during that phase.

But YJIT warms ups extremely fast and with a much lower overhead, it's seemless on deploy.

The only thing you may need to tweak is `--yjit-exec-mem-size`, it defaults to `--yjit-exec-mem-size=256` (MB) which is not quite enough for larger apps.

As for development, it would work, but with code reloading enabled, you'd likely exhaust the executable memory allocation pretty fast, because for now YJIT doesn't GC generated code [0]. It will come soon, hopefully before the 3.1.0 release, but that's one of the reason why it's not enabled by default.

[0] https://github.com/Shopify/yjit/issues/87

Just want to temper expectations because YJIT is still new. But if you run into crashes or bugs, please open an issue with as much detail as you can: https://github.com/Shopify/yjit

You raised a point that the compiler only does a subset. That's actually what I would expect from a new project. I don't expect a full implementation to start. It takes time for a compiler to be mature enough to be general purpose. Here is another Ruby compiler in its infancy: https://github.com/Shopify/yjit.

We already collaborate extensively with GitHub around Rails and Ruby. Our respective Ruby and Rails infra teams hold regular meetings, and they already contributed substantial patches to YJIT, e.g. https://github.com/Shopify/yjit/pulls/jhawthorn. Also things like https://bugs.ruby-lang.org/issues/17763 are a collaboration.

Yes. I put some suggestions here. I realize that not all of them are practical, but refactoring specific hot methods could make a difference.

> * A pointer to a unique class for that instance, called the “singleton class” of the object, also used for method lookup

I don't think this is accurate. The source code shows a generic `RObject` [0] contains flags, a pointer to a class (named `klass`), and instance variables. An `RClass` [1] contains flags, `klass`, `super` and a table of methods.

In both cases there is only a single pointer to a class that's used for method lookup.

> Ruby will look in the singleton class for the specific user instance first, and will only look for an instance method of the class if there is no matching method in the singleton class.

This is true, but it implies that Ruby does two separate lookups. The actual solution is more elegant.

An object's `klass` points to its singleton class, and method lookup happens only on that class and its superclasses. The second lookup implied above actually happens implicitly because the class of the object is an ancestor of the singleton class.

Specifically, for `class C`, its `klass` points to `<< C`, whose ancestors are `<< Object`, `<< BasicObject`, `Class`, `Module`, `Object` and `BasicObject`.

Ruby's whole object model, and the way it sets up this inheritance chain, is IMO beautiful and underappreciated.

> I’m not really sure why the Smalltalk solution wasn’t used

I think the way Ruby actually works is closer to the Smalltalk approach than the author realizes.

[0] https://github.com/ruby/ruby/blob/71f402c5d50919b0329d04704d...

[1] https://github.com/ruby/ruby/blob/71f402c5d50919b0329d04704d...

Ruby 3.4.0 was released today, December 25th, as the annual Christmas release (Ruby 3.4.0 Release). This year, we will also be explaining the NEWS.md file for Ruby 3.4 on the STORES Product Blog (incidentally, this will be an article for the STORES Advent Calendar 2024, written in Japanese). Please see the previous article for an explanation of what a NEWS file is.

I am most excited about the parser change, previously discussed here:

https://news.ycombinator.com/item?id=36310130 - Rewriting the Ruby parser (2023-06-13, 176 comments)

I remember being taught to use yacc in our compiler course because "writing it by hand is too hard". But looks like Ruby joins the growing list of languages that have hand-written parsers, apparently working with generated parsers turned out to be even harder in the long run.

That said, replacing a ~16k line parse.y[1] with a 22k line prism.c[2] is a pretty bold move.

[1] https://github.com/ruby/ruby/blob/master/parse.y

[2] https://github.com/ruby/prism/blob/main/src/prism.c

In fact, CRuby successfully combined “Self Tagging” with pointer tagging. Here's the commit:

https://github.com/ruby/ruby/commit/b3b5e626ad69bf22be3228f8...

Unix sockets can use tcp, udp, or be a raw stream

https://en.wikipedia.org/wiki/Unix_domain_socket#:~:text=The....

Puma creates a `UnixServer` which is a ruby stdlib class, using the defaults, which is extending `UnixSocket` which is also using the defaults

https://github.com/puma/puma/blob/fba741b91780224a1db1c45664...

Those defaults are creating a socket of type `SOCK_STREAM`, which is a tcp socket

> SOCK_STREAM will create a stream socket. A stream socket provides a reliable, bidirectional, and connection-oriented communication channel between two processes. Data are carried using the Transmission Control Protocol (TCP).

https://github.com/ruby/ruby/blob/5124f9ac7513eb590c37717337...

You still have the tcp overhead when using a local unix socket with puma, but you do not have any network overhead.

However, it turned out that this is really a bug in Ruby and will be fixed in Ruby 3.2.7, 3.3.7 and 3.4.0. While we're at it, I'd love to thank the Ruby core team for their swift responses and their efficiency at fixing this. It took Peter Zhu only a few hours, I wish I was as motivated as this gentleman.

https://github.com/ruby/ruby/releases/tag/v3_4_0_preview2