4 ms·

Quite interesting. My takeaway is that it can be on par with YJIT or even outperform it despite being in early development. Btw one project I work on switched

Quite interesting. My takeaway is that it can be on par with YJIT or even outperform it despite being in early development. Btw one project I work on switched to YJIT in production and there are no problems so far (but no noticeable perf gains either)

weatherlight 4y ago
What about in memory usage?
stanislavb 4y ago
Yeah, I have the same experience with SaaSHub. I moved to YJIY a week ago - no issues, but no noticeable perf gains either (unfortunately).
maxime_cb 4y ago
You're right that the peak performance could be on par (or even better), but, and I acknowledge that I'm biased since I'm tech lead of the YJIT team, my takeaway is: 1. Kokubun, who works with us on the YJIT team, is leveraging insights he's learned while working on YJIT to build this. He has said so in his tweets, some of the code in RJIT is a direct port of the YJIT's code to Ruby. This is his side-project. 2. One of the challenges we face in YJIT is memory overhead. It's something we've been working hard to minimize. Programming RJIT in Ruby is going to make this problems worse. Not only will it be hard to be more memory-efficient, you're going to increase the workload of the Ruby GC (which is also working to GC your app's data). 3. Warm-up time will also be worse due to Ruby's performance not being on par with Rust. This doesn't matter much for smaller benchmarks, but for anything resembling a production deployment, it will. On your second point, if you're not seeing perf gains with YJIT, we'd be curious to see a profile of your application, and the output of running with `--yjit-stats`. You can file an issue here to give us your feedback, and help us make YJIT better: https://github.com/Shopify/yjit/issues https://github.com/Shopify/yjit/issues
- akanet 4y ago
  Maxime, just wanna say I'm a big fan of your work https://twitter.com/fulligin/status/1524652417559646208 https://twitter.com/fulligin/status/1524652417559646208
- cztomsik 4y ago
  > Programming RJIT in Ruby is going to make this problems worse. Not only will it be hard to be more memory-efficient, you're going to increase the workload of the Ruby GC Or it could be a win. Java went that way too.

weatherlight 4y ago

What about in memory usage?

stanislavb 4y ago

Yeah, I have the same experience with SaaSHub. I moved to YJIY a week ago - no issues, but no noticeable perf gains either (unfortunately).

maxime_cb 4y ago

You're right that the peak performance could be on par (or even better), but, and I acknowledge that I'm biased since I'm tech lead of the YJIT team, my takeaway is: 1. Kokubun, who works with us on the YJIT team, is leveraging insights he's learned while working on YJIT to build this. He has said so in his tweets, some of the code in RJIT is a direct port of the YJIT's code to Ruby. This is his side-project. 2. One of the challenges we face in YJIT is memory overhead. It's something we've been working hard to minimize. Programming RJIT in Ruby is going to make this problems worse. Not only will it be hard to be more memory-efficient, you're going to increase the workload of the Ruby GC (which is also working to GC your app's data). 3. Warm-up time will also be worse due to Ruby's performance not being on par with Rust. This doesn't matter much for smaller benchmarks, but for anything resembling a production deployment, it will. On your second point, if you're not seeing perf gains with YJIT, we'd be curious to see a profile of your application, and the output of running with `--yjit-stats`. You can file an issue here to give us your feedback, and help us make YJIT better: https://github.com/Shopify/yjit/issues https://github.com/Shopify/yjit/issues

akanet 4y ago
Maxime, just wanna say I'm a big fan of your work https://twitter.com/fulligin/status/1524652417559646208 https://twitter.com/fulligin/status/1524652417559646208
cztomsik 4y ago
> Programming RJIT in Ruby is going to make this problems worse. Not only will it be hard to be more memory-efficient, you're going to increase the workload of the Ruby GC Or it could be a win. Java went that way too.