4 ms·

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 truffleRu

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-yjit-jruby-truffleruby.html https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj... [2] https://github.com/oracle/truffleruby https://github.com/oracle/truffleruby

pizza234 4y ago
When I read about its performance, I had the same thoughts, however, I was surprised to read this in the Github project readme: > 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.
- stormbrew 4y ago
  This is always a problem for any JIT. Large codebases, especially ones as heavy on dynamic code paths as rails, run individual pieces of code less frequently than smaller ones (because they're just doing more work in general, and in rails' case are constantly spawning new code to deal with). Then you have to instrument the code while it's running under a VM to decide what (and how) to JIT, and then you have to compile and assemble it. You also probably have to deal with some quasi-locking around the call sites as you switch code from using the VM to using the JIT. So, basically by the laws of thermodynamics, all else equal a JITing VM will be slower than a non-JITing one, and the benefits of JIT won't kick in until you have enough code instrumented and compiled to make a dent in that performance loss from the extra work. And then, the cleverer your JIT, and the more you optimize the code under compile, the more off-balance this gets, because doing those things gets more expensive.
petercooper 4y ago
I must note that TruffleRuby is a fantastic and genius bit of work with similarly genius folks working on it, but to answer your question.. there's a big cultural aspect. Things involving Oracle, the JVM, and Java generally do not tend to particularly click well with the entire Ruby world (but are just fine in specific niches). Consider that JRuby was significantly faster than CRuby for a long time yet the level of usage it got never really reflected that. Also consider just how poor Windows support was in Ruby for many years - this also wasn't purely a technical issue.

pizza234 4y ago

When I read about its performance, I had the same thoughts, however, I was surprised to read this in the Github project readme: > 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.

stormbrew 4y ago
This is always a problem for any JIT. Large codebases, especially ones as heavy on dynamic code paths as rails, run individual pieces of code less frequently than smaller ones (because they're just doing more work in general, and in rails' case are constantly spawning new code to deal with). Then you have to instrument the code while it's running under a VM to decide what (and how) to JIT, and then you have to compile and assemble it. You also probably have to deal with some quasi-locking around the call sites as you switch code from using the VM to using the JIT. So, basically by the laws of thermodynamics, all else equal a JITing VM will be slower than a non-JITing one, and the benefits of JIT won't kick in until you have enough code instrumented and compiled to make a dent in that performance loss from the extra work. And then, the cleverer your JIT, and the more you optimize the code under compile, the more off-balance this gets, because doing those things gets more expensive.

petercooper 4y ago

I must note that TruffleRuby is a fantastic and genius bit of work with similarly genius folks working on it, but to answer your question.. there's a big cultural aspect. Things involving Oracle, the JVM, and Java generally do not tend to particularly click well with the entire Ruby world (but are just fine in specific niches). Consider that JRuby was significantly faster than CRuby for a long time yet the level of usage it got never really reflected that. Also consider just how poor Windows support was in Ruby for many years - this also wasn't purely a technical issue.