How will this benefit Ruby?
Explained here: https://bugs.ruby-lang.org/issues/18481
Ruby YJIT Ported to Rust
21–30 of 93 posts
Re: Ruby YJIT Ported to Rust
#22Why 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.
Why not a memory safe language, to avoid those 70% of CVEs?
(67% of 0-days last year: https://news.ycombinator.com/item?id=31085539)
Re: Ruby YJIT Ported to Rust
#23Earlier quoted context omitted.
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.
It's not like new architectures appear very quickly, much less adopted very quickly. The benefits of maintenance overhead reduction and development speed increase, far outweight the theoretical downside of having to port LLVM to that new architecture.
Re: Ruby YJIT Ported to Rust
#24Earlier quoted context omitted.
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.
It’s not that it’s highly coupled, just that it’s still the early days and only x86_64 was on the roadmap. Arm64 is planned, and will hopefully make it into Ruby 3.2
Re: Ruby YJIT Ported to Rust
#25What 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.
Don't forget Opal!
Re: Ruby YJIT Ported to Rust
#26Motivation: https://bugs.ruby-lang.org/issues/18481
"The motivation behind this is that we are facing challenges in terms of code maintainability. As you know, JIT compilers can get very complex, and C99 doesn't offer many tools to manage this complexity. There are no classes and methods, limited type checking, and it's hard to fully separate code into modules, for instance."
"We believe that having access to object oriented programming and a more expressive type system would help us manage growing complexity better and also improve the safety/robustness of YJIT. For instance we would like to add Windows support and a new backend to YJIT. That means we’ll have two separate backends (x86, arm64) and we’ll need to support two different calling conventions (Microsoft, SystemV), but currently, we have limited tools to build the abstractions needed, such as preprocessor macros and if-statements."
Re: Ruby YJIT Ported to Rust
#27[flagged]
Re: Ruby YJIT Ported to Rust
#28Earlier quoted context omitted.
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.
Can you say more about why you think that?
Re: Ruby YJIT Ported to Rust
#29Why 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.
If you want to design your own CPU, supporting LLVM is going to give you much greater benefits than supporting Ruby. Nevermind the fact that you don't even need this to support Ruby.
Re: Ruby YJIT Ported to Rust
#30Earlier quoted context omitted.
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.
Rust will eclipse C++. C is a harder nut to crack, particularly for the embedded space where ease of implementing and maintaining a compiler back-end/code-emitter for your new weird 8-bit architecture is important. C is pretty close to an assembly macro and it's barely updated, which is great for that use-case. But for use cases like interpreters Rust is perfectly suitable.