[HN Gopher] Ruby: Porting YJIT to Rust
___________________________________________________________________
Ruby: Porting YJIT to Rust
Author : tosh
Score : 68 points
Date : 2022-01-17 20:30 UTC (2 hours ago)
(HTM) web link (bugs.ruby-lang.org)
(TXT) w3m dump (bugs.ruby-lang.org)
| baggy_trough wrote:
| It's a little disturbing that this YJIT was accepted into ruby
| 3.1 near the end of its cycle, just a couple months ago, and now
| it's being rewritten in a new language. Kind of a smell if you
| ask me.
| viraptor wrote:
| They posted the reasoning - C is limiting them from finishing
| the job cleanly for more platforms. It sounds like a reasonable
| choice to move to something leaner before yjit grows too large
| and the sunk cost issue starts being raised.
| baggy_trough wrote:
| "We are currently still early in our investigation of the Rust
| port. I am curious to know if you would also be open to YJIT
| being written in a language like Zig, or is that too
| new/experimental?" sounds half-baked...
| ksec wrote:
| And YJIT already work as it is? What is not to like?
|
| The YJIT and the CRuby are different part of the project. Just
| like TruffleRuby is written Ruby and based on Java GraalVM.
| They are basically writing a version 2 of YJIT in different
| language.
| Rochus wrote:
| Why don't they use Crystal? Wouldn't it support the listed value
| propositions too? And the syntax is close to Ruby.
| Gigachad wrote:
| Is Crystal still useful anymore? Now that Ruby has type
| checking / optional types.
| Rochus wrote:
| I think so. It has a similar syntax to Ruby, is statically
| typed with type inference, and has a much higher performance.
| I don't think it intends to nor can replace Ruby. But it's
| still an attractive alternative for many projects.
| Arcuru wrote:
| > Rust as a programming language community has a great deal of
| enthusiasm behind it. This could translate to more enthusiasm for
| YJIT and for Ruby as well.
|
| It's refreshing to see a project explicitly call this out as a
| benefit for adopting Rust. Love it or hate it, the RIIR (Rewrite
| It In Rust) crowd certainly has a lot of momentum behind it.
| gk1256 wrote:
| > it's refreshing to see a project explicitly call this out as
| a benefit for adopting Rust
|
| It seems to be a proposal. The proposal was made by a user who
| was registered on 09/27/2021.
|
| The text you quoted was included on his proposal. The project
| itself is not explicitly call that one out.
| ksec wrote:
| > The proposal was made by a user who was registered on
| 09/27/2021.
|
| maximecb is the lead of YJIT project in Shopify.
| dkga wrote:
| Yes! Love the acronym, too.
| megumax wrote:
| The platform `problem` shouldn't be a problem, because you
| wouldn't use ruby outside of Linux, Windows, Mac, FreeBSD,
| OpenBSD and Rust has support for more than that[1]. Backwards
| compatibility isn't a concert either, Rust promised and kept it
| for some years (after 1.6).
|
| The real problem is whether or not the expense of porting it is
| justified. Taking a look at the git repository of it (before it
| was merged into upstream), I understand why they want to rewrite
| it in Rust, the repository looks like a complete mess. I don't
| know if they want to use an existing JIT codegen like LLVM or
| Cranelift, or their own.
| byroot wrote:
| > you wouldn't use ruby outside of Linux, Windows, Mac,
| FreeBSD, OpenBSD and Rust has support for more than that[1].
|
| Ruby has support for plenty of "exotic" systems like HP UX, AIX
| etc. It's unclear how many people actually use it, but it's
| there.
|
| > I don't know if they want to use an existing JIT codegen like
| LLVM or Cranelift, or their own.
|
| Their own.
| pjmlp wrote:
| At least in what concerns AIX, IBM has migrated their
| compilers on top of LLVM, so some support is there.
|
| No idea about HP-UX, it is impossible to find anything now,
| apparently HPE has buried almost everything about it.
| Completely unrelated to how good it used to be about 20 years
| ago.
| byroot wrote:
| I just gave a couple examples I had in mind because they
| came up recently. The point was that the parent's
| assertion:
|
| > you wouldn't use ruby outside of Linux, Windows, Mac,
| FreeBSD, OpenBSD
|
| Isn't quite true.
| megumax wrote:
| I wasn't even referring to CRuby, I was referring to YJIT
| especially. For now, it only works on x86_64 Unix like
| systems (Linux and mac). I doubt that someone will ever port
| YJIT codegen to these "esoteric" architectures, so rust
| platform support is enough.
| byroot wrote:
| > I wasn't even referring to CRuby, I was referring to YJIT
| especially.
|
| My bad, that's really not what I understood from your
| initial statement. But yes agreed.
|
| The only real downside is discussed on the ticket. Ruby is
| primarily installed from source, so requiring a second
| toolchain is not ideal.
| petercooper wrote:
| Fun bit of trivia.. Ruby only (officially) dropped Atari ST
| support in 2016: https://github.com/ruby/ruby/blob/c5eb24349a
| 4535948514fe765c... .. I've never heard of anyone actually
| using Ruby on an Atari ST though(!)
| __s wrote:
| Looks like they aren't intending to use Cranelift. Which makes
| sense for an initial port that already has its own codegen.
| Personally found Cranelift a joy to use. Would be nice if
| Cranelift had a WASM backend to could compile a JIT to WASM to
| JIT WASM in WASM (this cyclic feature would be useful for
| creating JITs for dynamic languages in WASM rather than compiling
| the C interpreters to WASM)
| woodruffw wrote:
| It's unfortunate, but cranelift might still be considered too
| unstable for "primetime": my understanding as an outsider is
| that they're looking to stabilize YJIT sooner rather than
| later, to prevent it from being a perpetually
| unstable/experimental feature like MJIT ended up being.
|
| (Also, the last time I checked, cranelift emitted extremely
| suboptimal code. That's not their fault given the design
| constraints (it's a new project and they're aiming to beat
| LLVM's SelectionDAG in codegen performance), but it's probably
| not ideal given Ruby's long term performance goals. I'm also
| not sure how easy it would be to retrofit the LBBV[1]
| architecture of YJIT onto cranelift.)
|
| [1]: https://dl.acm.org/doi/10.1145/3486606.3486781
| taldridge wrote:
| Working on it! https://GitHub.com/teymour-
| aldridge/cranelift_codegen_wasm
| ksec wrote:
| It is interesting the discussion of Rust and Zig, which is the
| opposite spectrum of programming. It make sense if Ruby Cores are
| interested to develop / move to a new Ruby VM towards Rust. Not
| surprising considering Love2Code ( along with many other Ruby VM
| dev ) have complained over the years for CRuby's complexity. The
| Ruby Spec is a fairly recent thing done mostly by JRuby and
| TruffleRuby folks ( Correct me if am wrong ). If not, Zig on the
| other hand just works a lot better with old C code. One could
| argue Rust is Progressive and Zig is conservative.
|
| Unfortunately it is still way too early for Zig.
|
| I also wonder what is happening to TruffleRuby inside Shopify.
| And where is TenderJIT :)
| shellac wrote:
| Ruby spec has been going for a long time. It came from rubinius
| originally.
| pjmlp wrote:
| To me it looks like looking for new toys.
|
| My C complaints are well known, yet I don't see the need to
| make the build system even more complex, dropping platform
| support, for the benefit of yet another language, regardless of
| Rust or Zig winning in the end.
|
| Then they shouldn't have merged the JIT to start with and just
| do their own Ruby implementation instead.
| faitswulff wrote:
| In related news, I've also been following this PR to add Rust
| support to Ruby for gem native extensions:
| https://github.com/rubygems/rubygems/pull/5175
|
| It seems to have hit a minor speedbump dealing with support for
| Windows.
___________________________________________________________________
(page generated 2022-01-17 23:00 UTC)