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

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


Congratulations, Maxime!

It is a big achievement to have **stable** JIT improvements on **real** program for such dynamic language as Ruby.

It is a big achievement also because the JIT is simple and fast.  I don't think any JIT for Ruby can have faster compilation speed than YJIT.

I like very clever idea	of lazy	BB versioning on which YJIT is built. I've tried to solve problem of generation of type specialized code in original MJIT by dynamic changing VM insns to specialized variants of them and subsequent code generation.  But it needs several (slow) code generation until the code is stabilized.  It also doesn't remove redundant type checks because GCC and LLVM are not clever enough to remove checks when bitmasks operations are used for type tagging in CRuby (although recent development of ranger project https://gcc.gnu.org/wiki/AndrewMacLeod/Ranger might solve this problem).  Lazy BBV has no such disadvantages.

In fact	I'd like to try BBV in MIR project (https://github.com/vnmakarov/mir) in machine independent way through new extensions on MIR and C level besides implementation of profiling and extensions pointing where to use it.

I also like YJIT approach for fast method calls and switching to the interpreter.  I think the same approach might be implemented in MJIT (GCC naked functions might help).

I believe serious thinking should be done how to add YJIT to CRuby. I've been working on GCC for a long time and adding command line options to GCC and making them deprecated is a serious problem.  Ideally by default CRuby should generate the best code without any options.  I think YJIT should work by default and when a Ruby method run too many times MJIT should be used as in a standard approach for JVM.

I don't see currently a working alternative to YJIT as tierI JIT	compiler for CRuby.  This might stay as it for a long time.  Saying that I also don't see a potential for big Ruby code performance improvement by YJIT without considerable redesign.  YJIT does not optimize machine code generated for several VM insns. To solve the problem, adding IR and making classical optimizations on it is needed.  Without IR YJIT can not move to another level of optimizations (interprocedural level, e.g. by using call inlining).  But that is ok, YJIT does excellent work as tierI JIT compiler and can stay	that way.

Maxime,	I were you, I'd	also take an opportunity for merging YJIT to change its name.  My experience shows me that it is better to avoid words "new" (because inevitably it is becoming old) and "yet another" (it is not yet another if it is a successful project) in any project name.  But it is just
my personal opinion.

I am not decision maker	but I'd	like to	support	making Maxime Ruby committer when YJIT will become of CRuby code because she is an author, can be the best maintainer of YJIT and there are few Ruby core developers familiar with specifics of machine code generation and its performance.



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

* 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>