Merge YJIT: an in-process JIT compiler | Hacker News Reader

Merge YJIT: an in-process JIT compiler

github.com

86 pointsstanislavb24 comments

This is awesome! Ruby is a notoriously hard language to optimize thanks to its (wonderful) dynamism, so it's very exciting to see substantial performance gains with this new JIT.

Something that I noticed that might throw others for a loop as well: the changeset is north of 350K, but the actual JIT is only a couple of thousands of lines of C. 90% of the changeset is two torture test files.

> the actual JIT is only a couple of thousands of lines of C

Even for Ruby, a basic JIT can be implemented in a few hundred lines of C using a "threaded code" approach.

Real JIT compilers got started this way. Safari JavaScriptCore's JIT used a "context threaded code" approach and was just 4k LOC

https://webkit.org/blog/214/introducing-squirrelfish-extreme...

i.e. it's well tested and solid. Including running on some production Shopify systems :)

> torture test files

I like this term

"YJIT currently provides average speedups of 23% over the CRuby interpreter on realistic benchmarks, and near-instant warm-up time. Plans are to include YJIT in the Ruby 3.1 preview release so that more users can test it out and benefit from potential performance gains."

> YJIT uses significantly more memory when active -- e.g. OptCarrot takes 80MB without YJIT and 350MB with YJIT. This can be adjusted by setting --yjit-exec-mem-size.

This one gave me a worry. I think it can be addressed, but if it can't this whole effort seems a bit overrated to me.

It's always a trade off of time and space, especially for dynamic languages. Glad the flag is there, and it will be interesting to see more real-world data once it's out in the wild.

>No garbage collection for generated code. Will produce an error if --yjit-exec-mem-size is exceeded. This should be fixed in the coming months.

Sounds like at least part of it will be fixed.

Related past threads. Others?

YJIT: Building a New JIT Compiler for CRuby - https://news.ycombinator.com/item?id=28874283 - Oct 2021 (47 comments)

Proposal to Merge YJIT into Ruby - https://news.ycombinator.com/item?id=28691048 - Sept 2021 (77 comments)

YJIT: Building a New JIT Compiler Inside CRuby - https://news.ycombinator.com/item?id=27371977 - June 2021 (1 comment)

https://news.ycombinator.com/item?id=27231556 which is not strictly about YJIT but has YJIT things in it.

Could ruby do something similar to python's gil removal? https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/

Ruby doesn’t have a reference counting GC, so not really applicable.

When I read Maxime's Basic block versioning paper it gave me a strong sense of "this is the right way". Great to see the concept taking root.

More than just the JIT itself, I'm very interested in seeing if this will push Ruby towards making other performance-related inprovements to it's data structures and bytecode format:

https://pointersgonewild.com/2021/06/02/yjit-building-a-new-...

There was already a JIT since Ruby 2.6, the MJIT: https://k0kubun.medium.com/ruby-3-0-jit-and-beyond-4d9404ce3...

The author of that article (k0kubun) is also one of the reviewers on this PR.

What is the difference between the two JITs?

This one is a proper JIT, whereas the former generated C code, called the C compiler on it, and then loaded the generated code as shared object.

You can imagine how much it actually helped in the end.

Whatever the native code might help was let down due to the lantency of doing all that work.

But you do the process you described only once per "warmed up" method right? Yes it sound expensive but once it's warmed up it should be as good as YJIT or am I missing something?

"Why Ruby's JIT was slow" talk at RubyKaigi 2021.

https://www.youtube.com/watch?v=db3GHHllRyQ

Btw the actual commit is here since the pr was closed and merged separately: https://github.com/ruby/ruby/commit/6a9e2b3cc381fd1b6c5ec5ed...

The YouTube video: https://www.youtube.com/watch?v=PBVLf3yfMs8

... note some other optimizations that they plan to implement that should improve both the JIT and non-JIT performance.

Performance improvements are always welcome in any language.

This is so cool and for people who use Jekyll it improves Jekyll's liquid template rendering speed. JRuby and TrufflyRuby's JIT did not, at least for me.

https://news.ycombinator.com/item?id=27322533

Make sure you have liquid-c enabled.

I got some Insertion sort implementation running in 55% of the original time by enabling YJIT. Impressive work!

How was the memory between the two?

Reply on news.ycombinator.com