Does anyone had experience with truffleruby on rails? It sounds like truffleruby will be the future, but still the rails startup took 4 times longer than expected. I can’t see any benefit of truffleruby. My opinion is based on this small comparison between truffleruby and MRI GitHub - andrekullmann/truffleruby-playground: Playing with truffleruby. Performace and handling
Thanks for any advice.
For most Rails apps, the speed of the ruby interpreter is seldom the bottleneck. I think the main benefit of interpreters like TR and JRuby are the ability to run code in parallel, because there is no global interpreter lock.
I don’t think TR is the future. It is a great project, but MRI ruby is progressing full speed ahead, with great enhancements on every release. I think MRI ruby will continue to be the future.
Thanks Scott for sharing your opinion.
A little old comment but I believe main concepts are still relevant:
So the app boot time and time to reach peak performance are still the main tradeoffs even though the boot time has been improved recently. I’m just far from being the best person to elaborate
The application startup is currently expected to not be faster on TruffleRuby. What should be faster is the throughput after enough warmup (and it it’s not, please file an issue at Issues · oracle/truffleruby · GitHub).
Please do not say “truffle ruby doesn’t seem like a good choice” based only on startup numbers. Especially for a Rails application, throughput/latency is very relevant and startup is not the only metric which matters.
Just like for JRuby or typically any VM with an optimizing JIT using profiling information (e.g. JVM, JS VMs, etc), startup is expected to not be faster. The reason is the interpreter gathers additional profiling information (e.g. which branches are taken, which types are seen, etc), which is later used by the JIT compiler to produce much better code than if there was no profiling information. Gathering that additional profiling information takes time and this is a big part why you see a slowdown on startup. When loading the application there is constantly new code being seen, so even though the JIT is compiling in parallel, there is still a significant amount of time spent in the interpreter.
We (the TruffleRuby and GraalVM teams) are working on improving startup/warmup on TruffleRuby and there has already been significant progress with multi-tier compilation, etc.
A game changer for this is Auxiliary Engine Caching which lets you persist the JIT-compiled code and reuse it across processes, so you’d have one profiling run, and then later runs would start fast and run in compiled code almost all of the time. This is not fully supported yet in TruffleRuby but we are currently working on it.
Do you have any data to back that?
I think it’s a common misconception, for instance see https://twitter.com/_byroot/status/1557273485516341248
This is probably not worth arguing too much about (what is “the future” is subjective), but I don’t see significant performance speedups in CRuby, and nothing comparable to TruffleRuby in terms of peak performance. For instance see Benchmarking CRuby, MJIT, YJIT, JRuby and TruffleRuby · On the Edge of Ruby which notably includes a rails benchmark.