4 ms·

TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin This is interesting to me as someone working on a Rails app currently. I'

TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin This is interesting to me as someone working on a Rails app currently. I'm surprised it hasn't become the defacto ruby implementation given the benchmarks shown on the site. What are the drawbacks? Just Oracle ownership? Or does it require an enterprise subscription?

d3nj4l 4y ago
This is partly covered in the GitHub Readme of TruffleRuby: TruffleRuby can run Rails and is compatible with many gems, including C extensions. However, TruffleRuby is not 100% compatible with MRI 3.0 yet. Please report any compatibility issues you might find. TruffleRuby passes around 97% of ruby/spec, more than any other alternative Ruby implementation. 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. However, I think this is slightly outdated, because I vaguely remember a talk from one of the rubycons about Rails being slightly faster with truffle. I can't say for sure why it's not been widely picked up yet; maybe other players are looking forward to JITs within Ruby itself, or don't like the two tier model of GraalVM (you can run it for free, but it also has an enterprise version with additional performance improvements.)
dragonwriter 4y ago
> This is interesting to me as someone working on a Rails app currently. I’m surprised it hasn’t become the defacto ruby implementation given the benchmarks shown on the site. What are the drawbacks? It is not supported on all platforms and listed as “experimental” (defined as “ features [which] are being considered for future versions of GraalVM and are not meant to be used in production”) on the platforms (Linux AMD64/ARM64, macOS [AMD64, presumably, since there is a separate listing for MacOS ARM64 where it is not supported]) that it is supported on. [0] That’s probably the main thing keeping it back from general adoption. (It’s also ~2 years behind MRI on features, but that’s less important.) There are also notes in the TruffleRuby repo and docs that it: (1) is possibly not fast on Rails and large programs (which are probably the bulk of where people would be looking for performance gains), (2) has some minor incompatibilities (individually no big deal, but the aggregate could be a factor) (3) Fibers (Ruby’s main lightweight concurrency construct) don’t have the lightweight performance they do in CRuby because they use full native threads. [0] https://www.graalvm.org/22.1/docs/introduction/ https://www.graalvm.org/22.1/docs/introduction/, under “Features Support”

d3nj4l 4y ago

This is partly covered in the GitHub Readme of TruffleRuby: TruffleRuby can run Rails and is compatible with many gems, including C extensions. However, TruffleRuby is not 100% compatible with MRI 3.0 yet. Please report any compatibility issues you might find. TruffleRuby passes around 97% of ruby/spec, more than any other alternative Ruby implementation. 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. However, I think this is slightly outdated, because I vaguely remember a talk from one of the rubycons about Rails being slightly faster with truffle. I can't say for sure why it's not been widely picked up yet; maybe other players are looking forward to JITs within Ruby itself, or don't like the two tier model of GraalVM (you can run it for free, but it also has an enterprise version with additional performance improvements.)

dragonwriter 4y ago

> This is interesting to me as someone working on a Rails app currently. I’m surprised it hasn’t become the defacto ruby implementation given the benchmarks shown on the site. What are the drawbacks? It is not supported on all platforms and listed as “experimental” (defined as “ features [which] are being considered for future versions of GraalVM and are not meant to be used in production”) on the platforms (Linux AMD64/ARM64, macOS [AMD64, presumably, since there is a separate listing for MacOS ARM64 where it is not supported]) that it is supported on. [0] That’s probably the main thing keeping it back from general adoption. (It’s also ~2 years behind MRI on features, but that’s less important.) There are also notes in the TruffleRuby repo and docs that it: (1) is possibly not fast on Rails and large programs (which are probably the bulk of where people would be looking for performance gains), (2) has some minor incompatibilities (individually no big deal, but the aggregate could be a factor) (3) Fibers (Ruby’s main lightweight concurrency construct) don’t have the lightweight performance they do in CRuby because they use full native threads. [0] https://www.graalvm.org/22.1/docs/introduction/ https://www.graalvm.org/22.1/docs/introduction/, under “Features Support”