The proposal for this was previously discussed at: https://news.ycombinator.com/item?id=29971360
Ruby YJIT Ported to Rust
11–20 of 93 posts
Re: Ruby YJIT Ported to Rust
#12"YJIT code ported from C99 to Rust" Beyond passing the test suite, are there more numbers to compare both versions? (e.g., compilation time, lines of code, size of binaries, performance, etc.)
I think the goal of this right now is just to match the C version.
The C implementation of YJIT supported x86 Unix/Linux platforms, and it sounds like adding Windows and arm64 support, plus other improvements was a daunting task with the tools C provides.
Now it’s in Rust we’ll hopefully see further improvements quicker.
Re: Ruby YJIT Ported to Rust
#13Earlier quoted context omitted.
YJIT benchmarks can be found at https://speed.yjit.org/ The Rust port doesn't change performance much according to the pull request description.
Your own link states -- Overall YJIT is 33.4% faster than interpreted CRuby! On Railsbench specifically, YJIT is 32.4% faster than CRuby!
Yes, but YJIT in rust is the same ~33.4% faster than vanilla CRuby than YJIT in C. The rewrite into Rust is expected to make YJIT easier to maintain and that may in turn make possible further improvements to code generation, but the rewrite generates the same machine code (and therefore the same speedup) as before.
Re: Ruby YJIT Ported to Rust
#14What is the benefit? Can I run Ruby in the browser now?
Yes you can run Ruby in the browser if you want, but not because of this PR. Ruby-in-WASM was merged a few weeks ago.
This PR rewrites the YJIT just-in-time compiler code from C into Rust, because the dev team likes Rust better and expects that it will make development of new features easier.
Re: Ruby YJIT Ported to Rust
#15Why not C++, for better portability? If I want to design my own CPU, I will have to add it to GCC. But Rust is LLVM so if I want to support Ruby-jit on my CPU, I will also will have to support LLVM.
Re: Ruby YJIT Ported to Rust
#16How will this benefit Ruby?
Re: Ruby YJIT Ported to Rust
#17Why not C++, for better portability? If I want to design my own CPU, I will have to add it to GCC. But Rust is LLVM so if I want to support Ruby-jit on my CPU, I will also will have to support LLVM.
This is a non-issue. YJIT only targets x86-64. After all, this is a JIT. If you designed a new architecture X, you need to port YJIT itself to target X, in addition to GCC, LLVM, etc.
Re: Ruby YJIT Ported to Rust
#18"YJIT code ported from C99 to Rust" Beyond passing the test suite, are there more numbers to compare both versions? (e.g., compilation time, lines of code, size of binaries, performance, etc.)
I think the goal of this right now is just to match the C version. The C implementation of YJIT supported x86 Unix/Linux platforms, and it sounds like adding Windows and arm64 support, plus other improvements was a daunting task with the tools C provides. Now it’s in Rust we’ll hopefully see further improvements quicker.
This is the first time I've felt that Rust is starting to eat C's lunch.
Re: Ruby YJIT Ported to Rust
#19Why not C++, for better portability? If I want to design my own CPU, I will have to add it to GCC. But Rust is LLVM so if I want to support Ruby-jit on my CPU, I will also will have to support LLVM.
This is a non-issue. YJIT only targets x86-64. After all, this is a JIT. If you designed a new architecture X, you need to port YJIT itself to target X, in addition to GCC, LLVM, etc.
Oh, so YJIT is highly coupled to x86-64? Porting GCC + yjit is less work than porting GCC + yjit + LLVM.
Re: Ruby YJIT Ported to Rust
#20How will this benefit Ruby?
if YJIT is successful, ruby will be faster, which is good™. The rationale for the rust rewrite is that rust may be better suited for writing a JIT than C is.