6 ms·
"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
by jfmc 4y ago
"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.)
- tmikaeld 4y agoWas looking for the same thing, what does this mean for Ruby performance?
- deleted 4y ago[deleted]
- block_dagger 4y agoNothing
- ModernMech 4y agoAccording to the post not much. The Rust version performs about the same because it generates mostly the same machine code.
- Rafert 4y agoYJIT benchmarks can be found at https://speed.yjit.org/ https://speed.yjit.org/ The Rust port doesn't change performance much according to the pull request description.
- npalli 4y agoYour own link states -- Overall YJIT is 33.4% faster than interpreted CRuby! On Railsbench specifically, YJIT is 32.4% faster than CRuby!
- WJW 4y agoYes, 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.
- ewalk153 4y agoI didn't know this was public, sweet! Nice that the tooling that generates this report is also published: https://github.com/Shopify/yjit-metrics https://github.com/Shopify/yjit-metrics
- rvz 4y agoIt means completely nothing for performance.
- pizza234 4y agoVery likely, the performance of a JIT comes from: - the architecture of the JIT itself - the generated code AFAIK, the Rust YJIT doesn't change any (they explicitly say that the generated code is approximately the same), so there no significant difference in performance should be expected.
- asymmetric 4y agoThe PR itself says: > The new Rust version of YJIT has reached parity with the C version, in that it passes all the CRuby tests, is able to run all of the YJIT benchmarks, and performs similarly to the C version (because it works the same way and largely generates the same machine code). We've even incorporated some design improvements, such as a more fine-grained constant invalidation mechanism which we expect will make a big difference in Ruby on Rails applications.
- faitswulff 4y agoRoR comparison benchmarks would be nice to see.
- matsadler 4y agoI 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.
- anitil 4y agoThis is the first time I've felt that Rust is starting to eat C's lunch.
- rubyfan 4y agoCan you say more about why you think that?
- anitil 4y agoI started in C and generally when people say 'rewrite it in Rust' I just roll my eyes, because I know how hard that is. But seeing it happen on a sophisticated project has made me take another look. Obviously for the embedded world everything is pitched at C currently and I don't think that will change, but for larger projects this is proof that my intuition was wrong. I suppose that's a long winded way of saying that it might be time for me to learn Rust.
- tormeh 4y agoRust 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.
- vlovich123 4y agoThis position is like saying C or C++ won't eat ASM's lunch. While technically true since there's a lot of ASM code still being written, especially for extremely low-level or high performance code, the vast majority of C and C++ developers don't actually touch ASM (i.e. C/C++ dominate ASM in terms of number of developer hours spent). I think you may also be overlooking the GCC backend for rustc and gccrs, a ground-up standalone reimplementation of the Rust language frontend for GCC. Both of those should drastically improve the coverage and availability of Rust to all the same platforms you would be using GCC to compile C code for. Depending on the compiler support, you might get that architecture for free unless the vendor is providing their own C compiler. The harder part is that your new weird 8-bit architecture probably won't benefit as much from the strong nostd ecosystem of libraries, so the overhead of writing Rust won't be counterbalanced. Still, like I said at the outset, this is an extremely niche use-case. Rust doesn't have to wipe C or C++ from the map for it to crack that nut. The harder nut for Rust to crack I think is actually C++. There are extremely large C++ codebases. Industry would love for there to be a significantly easier/cheaper story to tell in terms of integrating Rust with those codebases. That way you could set metrics around converting the codebase, new code has to be written in Rust etc. However, the challenge is that Rust can only replace components with very well-defined boundaries. Those boundaries are less clearly defined in C++ codebases than they are in C codebases (linkage + templates in particular are challenging). To truly crack the C++ nut probably requires solving this problem unless Rust codebases just starting eating C++ codebases commercially through development velocity (which is a much longer and harder path).