51–60 of 93 posts
Earlier 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.
Earlier quoted context omitted.
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
Earlier 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.
Earlier quoted context omitted.
How is JIT miscompilation or vulnerabilities in the JIT compiler not an issue?
A Ruby program can delete all of the files on a computer, insert arbitrary rows into a database, drop a table, send email with attachments, etc. Am I correct that you're concerned the Ruby JIT itself will have a security vulnerability in the act of JIT compiling Ruby code? This seems extremely myopic.
I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines?
Earlier quoted context omitted.
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.
Good luck with that on anything GPU or HPC related, or industries with language standards. Also until Rust compilers are bootstraped, they will always rely on a C++ infrastructure.
Bootstrapping seems a silly thing to be obsessed about as C++ will be around forever still, but it obviously can be bootstrapped if that becomes important.
Earlier quoted context omitted.
How is JIT miscompilation or vulnerabilities in the JIT compiler not an issue?
A Ruby program can delete all of the files on a computer, insert arbitrary rows into a database, drop a table, send email with attachments, etc. Am I correct that you're concerned the Ruby JIT itself will have a security vulnerability in the act of JIT compiling Ruby code? This seems extremely myopic.
[1] https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...
Here's a benchmark [1] done in Jan'22 against many ruby implementations, truffleRuby [2] seems to be way ahead in most, and at least ahead in all. Why truffleRuby isn't talk about much here? [1] https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj... [2] https://github.com/oracle/truffleruby
> TruffleRuby might not be fast yet on Rails applications and large programs. Notably, large programs currently take a long time to warmup on TruffleRuby and this is something the TruffleRuby team is currently working on. Large programs often involve more performance-critical code so there is a higher chance of hitting an area of TruffleRuby which has not been optimized yet.
I guess that they have a high-performing JIT, that is optimized for small but not large programs yet. I'm curious though, what, technically, makes such difference.