Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby YJIT Ported to Rust

github.com

Post reply on HN
Print view View original

61–70 of 93 posts

Re: Ruby YJIT Ported to Rust

#61

Post by pizza234 »

tmikaeld wrote: post #3
jfmc wrote: post #2

"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.)

Was looking for the same thing, what does this mean for Ruby performance?

Very 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.

Re: Ruby YJIT Ported to Rust

#62

Post by rvz »

tmikaeld wrote: post #3
jfmc wrote: post #2

"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.)

Was looking for the same thing, what does this mean for Ruby performance?

It means completely nothing for performance.

Re: Ruby YJIT Ported to Rust

#63

Post by pizza234 »

dj_gitmo wrote: post #44

> ... it works the same way and largely generates the same machine code How can they make this determination? Do they just eyeball a few sections of the machine code from each output? Is there some tool that can compare binaries? Is this just a very literal, function by function, translation from C to Rust? I don't know much reading/comparing machine code.

I'm not familiar with what YJIT generates, however, in general terms, if the ASM code for a given bytecode is small enough (Which I think it is), one can just compare them side by side, or just log them and compare them separately. I think a JIT for Ruby should compile relatively small chunks of ASM, not big walls of code (but again, this is my guess).

Re: Ruby YJIT Ported to Rust

#64

Post by pizza234 »

infamouscow wrote: post #31
brobinson wrote: post #22

Earlier quoted context omitted.

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 )

Because Ruby is already memory safe and JIT miscompilation is a logic bug.

The fact that a language is memory safe doesn't imply that the underlying virtual machine/interpreter is.

On the other hand, it's definitely true that the ASM generated is as unsafe as it gets, but the first point still stands. The memory unsafety of the VM is simply an additional attack vector.

Re: Ruby YJIT Ported to Rust

#65

Post by bilkow »

throwaway-m3232 wrote: post #15

Why 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 I want to design my own CPU, I will have to add it to GCC.

Why do you "have" to add it to GCC? You could only add it to LLVM instead.

Re: Ruby YJIT Ported to Rust

#66

Post by pjmlp »

FullyFunctional wrote: post #55
pjmlp wrote: post #47

Earlier quoted context omitted.

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.

I've been around for a long time and I haven't seen a PL with this much momentum since Java was launched. Inertia is real, but the benefits over C++ are undeniable. 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.

Ada/SPARK already provided such benefits, and NVidia has chosen it instead of Rust for automotive firmware.

Rust momentum is meaningless for GPUs unless NVidia decides it gets to play in CUDA, and they are now one of the companies with more ISO C++ people on their payroll.

It is also meaningless for PlayStation, Nintendo and Xbox, unless the respective SDKs integrate Rust.

Bootstraping isn't silly, because LLVM and GCC are written in C++, so there isn't any "Rust will eclipse C+", when it depends on it for its existence.

Re: Ruby YJIT Ported to Rust

#67

Post by infamouscow »

bastawhiz wrote: post #58
infamouscow wrote: post #43

Earlier quoted context omitted.

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.

It's a bad look if a malicious HTTP request to your Rails app can trigger RCE on your server. It's not about running code that's malicious, it's about bad data triggering a code path in the VM that is able to change the function of the application.

What you're describing is a logic bug.

JITs write instructions to memory in a manner that's only slightly different than writing bytes to a file. The generation of those instructions can either be correct or incorrect and happens regardless of programming language.

A JIT written in Python is equally capable of generating bad code as a JIT written in C or Rust or Lisp. A perfect port of a buggy JIT written in language A will generate the same buggy code even after being ported to language B.

Re: Ruby YJIT Ported to Rust

#68

Post by hardwaregeek »

This is so cool! If new contributions to Ruby could be written in Rust, I'd be a lot more inclined to contribute. I don't think I'm alone here. Andy Kelley noted that the new Zig compiler has significantly more contributors, likely due to it being written in Zig and not C++.

Some people may roll their eyes at this, but it is a lot more enticing to work on a Rust codebase than a C/C++ one. I'm less likely to screw up and create a serious bug; I get a lot more help from the compiler; the build system is standardized and simple; and it's just plain fun.

Re: Ruby YJIT Ported to Rust

#69

Post by mustache_kimono »

mustache_kimono wrote: post #49
throwaway-m3232 wrote: post #15

Why 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.

I'm not sure I understand why some people really hate Rust, but when the argument feels like "But can't we be miserable forever?" I just have to laugh.

FYI -- my technical thinking -- because Rust is a nicer language for the people who have to work with it. Full stop.

Rust offers substantial memory safety guarantees, but that isn't the only thing it offers. People who don't know this are those that haven't tried it. Others have focused on security in this thread, and I think that's wrong headed. That's obviously not the reason for choosing Rust here. It's that it makes things that are important now and in the future, like say concurrency, easier and more likely to be correct. Yes, ergonomics and a nice dev experience actually matter even for the people writing your compiler!

Moreover, Rust GCC support is far closer to being a thing that yjit is to being a thing. So -- let the kids play.

Re: Ruby YJIT Ported to Rust

#70

Post by ewalk153 »

Rafert wrote: post #9
tmikaeld wrote: post #3

Earlier quoted context omitted.

Was looking for the same thing, what does this mean for Ruby performance?

YJIT benchmarks can be found at https://speed.yjit.org/ The Rust port doesn't change performance much according to the pull request description.

I didn't know this was public, sweet! Nice that the tooling that generates this report is also published: https://github.com/Shopify/yjit-metrics
Post reply on HN