4 ms·
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 la
by baggy_trough 5y ago
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.
- baggy_trough 5y ago"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...
- viraptor 5y agoThey 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.
- maxime_cb 5y agoYeah to be honest, C was never our favorite pick to begin with. We initially wrote YJIT in C99 because that was what the rest of the CRuby codebase was written in. However, JIT compilers are very complex pieces of software. They need to do things like symbolic transformations on graphs, and deal with multiple different kinds of intermediate representations. Doing that in C, you get really bogged down with the details of manual memory management and rolling your own data structures. You can get all kinds of subtle bugs if you aren't careful.
- baggy_trough 5y agoIf you know you're going to rewrite the thing in a new language, then why push to include it in ruby now?
- maxime_cb 5y agoWe didn't push to upstream now, we were invited to upstream in CRuby and we accepted the invitation. As for the Rust rewrite, we just started to work on the prototype, and no decision had been made. The ticket linked in this thread is me essentially asking the Ruby core devs for permission to do so. We wanted to give everyone an opportunity to chime in. Not sure what to tell you. Things don't aways happen in the most optimal order in the real world, sometimes plans change, but I'm fairly confident that we can make this work well.
- creamytaco 5y agoThse are all not only solved problems, but solved extremely well. Rust is a bad solution to this problem. You should be using dynasm https://luajit.org/dynasm.html https://luajit.org/dynasm.html instead of plain C.
- remexre 5y agoHow does that make graph transformations easier and avoid issues with memory management related to those? I tried looking in the docs at your link to see (because it looks a lot more like a syntax extension for an assembler than anything that helps with the problems the author noted), but the page notes, > Sorry, right now there is no proper documentation included other than some Examples and of course the source code. The source is well documented, though (IMHO). and the example doesn't seem to have anything relevant to the problems identified above.
- ksec 5y agoAnd 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.