[ruby-core:105506] [Ruby master Feature#18229] Proposal to merge YJIT

Issue #18229 has been updated by vmakarov (Vladimir Makarov).


maximecb (Maxime Chevalier-Boisvert) wrote in #note-9:
>  I have looked at MIR and it looks close to machine code, the kind of IR you would compile C code into. We are thinking of designing an IR that is maybe closer to Ruby semantics, so that Ruby-specific optimizations can be applied more easily. Open to discussion if you have input on the subject. We would appreciate your input.

MIR is designed to be used for different languages, including C.  Standard ruby methods implemented on C, e.g. `times`, can be translated into MIR and user-defined Ruby block called by `times` can be translated into MIR too (may be through intermediate C translation), then MIR for `times` and the block can be intermixed (inlined) and optimized.  So MIR permits optimization of code written on different languages.  In this way MIR can be used not only for Ruby but for other dynamic language implementations (e.g. CPython).

MIR also makes easy implementation of classical compiler optimizations because it is an extension of tuple based IR. 

You probably wrote about inlining methods (blocks) implemented on Ruby into another Ruby method.  It is more constrained approach.  Although if most standard Ruby methods like `times` will be rewritten on Ruby, it is less constraint approach but I am not sure that the overall machine code generated quality will be not worse.  Probably it is also double approach if type information (type annotation can be used for this) and info about absence of integer overflow from standard methods rewritten from C to Ruby can be propagated and used.

Still for further improvement of YJIT you need some IR to optimize machine code generated from several VM insns.  Right now YJIT is just a simple template code generator for given value types.

In any case, I am just at the very beginning to use MIR project for CRuby JIT and YJIT is a real thing.  And it is the only thing that matters.

----------------------------------------
Feature #18229: Proposal to merge YJIT
https://bugs.ruby-lang.org/issues/18229#change-93954

* Author: maximecb (Maxime Chevalier-Boisvert)
* Status: Assigned
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
----------------------------------------
# Background

YJIT is a new open source JIT compiler for CRuby.  The project is led by a small team at Shopify in collaboration with developers from GitHub.  The key advantages of this project are that the compiler delivers very fast warm-up and has fine grain control over the entire compiler pipeline.

This JIT translates YARV instructions to machine code and employs a technique known as [Lazy Basic Block Versioning (LBBV)](https://drops.dagstuhl.de/opus/volltexte/2015/5219/pdf/9.pdf) in order to specialize code based on types seen at run-time and reduce generated code size without needing to do static type analysis. The YJIT project was [presented at RubyKaigi 2021](https://www.youtube.com/watch?v=PBVLf3yfMs8).

# Limitations

YJIT works by translating YARV instructions to x86 machine code.  YJIT doesn’t support all YARV instructions, but is able to gracefully handle unknown instructions by returning control of execution back to the CRuby interpreter.

Today, YJIT only targets x86-64 architecture.  We may support ARM64 in the future, but due to the nature of the compiler design, we can’t easily support as many platforms as MJIT. Still, we anticipate that x86-64 and ARM64 will cover the needs of the vast majority of users, from PCs to servers to Apple M1s to cell phones and even Raspberry Pis.

# Advantages

YJIT has very fast warmup and can produce good real-world benchmark results when compared to other JITs. There are still many options for improving performance further.

# Integration with MRI

YJIT can’t work fully as a “plug-in” JIT.  It requires some modifications to CRuby, mostly related to compilation and invalidation.  For example, YJIT needs callbacks so it can be notified when the constant state changes or when BOPs are redefined.  These modifications are quite modest and could be advantageous for MJIT or other JITs in the future.  YJIT’s implementation is contained in the yjit_*.c files with very few modifications to CRuby.

# Benchmarks

YJIT optimizes a number of common benchmarks well. Here are some results compared to the CRuby interpreter without MJIT, [current as of Sept 2021](https://speed.yjit.org/benchmarks/bench-2021-09-27-071059):

activerecord: 1.37x
jekyll: 1.12x
liquid-render: 1.27x
mail gem: 1.09x
psych-load: 1.29x
Kokubun's railsbench: 1.16x
optcarrot: 1.68x
Chris Seaton's lee benchmark: 1.41x

Source code for these benchmarks can be found at https://github.com/Shopify/yjit-bench under "benchmarks".

# TODO / Known Bugs

We have been running YJIT in production, but it is still experimental.  Some key features are currently missing, the most important being “code GC”.  Currently, any generated code that is invalidated (or becomes “unusable”) is not collected, nor is the memory allocated for that code reclaimed.  This is rarely a problem in practice because most Ruby programs generate a fixed amount of code, but it is a problem that we want to fix in the short to medium term. This is an area which is currently under development.

# Stability and Compatibility

MRI’s full suite of tests including RubySpec tests pass with YJIT enabled.  We’ve tested YJIT against our production application (Shopify’s StoreFront Renderer) and all tests pass there as well.  Finally, GitHub has tested YJIT against their test suite and all tests pass.  We’ve deployed YJIT to production on a subset of servers and seen performance improvements.  See more details here.

# Merging Proposal

Despite some of the limitations and TODO’s listed here, we would like to propose merging YJIT so that we can get feedback from the rest of the community as well as add “integration points” for other JIT implementations.

We’ve intentionally made as few changes to MRI as possible to support integrating YJIT.  We’re committed to continue developing YJIT, but intentionally kept the changes to MRI small in order to ease the burden on upstream maintainers.

YJIT will be disabled by default and require an experimental command-line flag (`--yjit`) to be set.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>