3 ms·
Sorry to be a bit overbearing here~ It's worth thinking about JRuby-performance-skeptical-ness when thinking about TruffleRuby due to some similarities. Not go
by kipply 6y ago
Sorry to be a bit overbearing here~
It's worth thinking about JRuby-performance-skeptical-ness when thinking about TruffleRuby due to some similarities. Not going to outline in a comment, but suffice it to say that TruffleRuby was once called JRuby+Truffle.
TruffleRuby has the power to work through JRuby shortcomings. With GraalVM, TruffleRuby gets to have C extensions! Graal is also open source, so we get more control of what we want it to do and more understanding of what it does. In theory, that gives TruffleRuby more room to get faster.
It's also worth noting Charles Nutter's comment on the post, that mentions that Hotspot C2 already does this optimization! (though they wouldn't have this kind of control over branch profiling)
- sdegutis 6y agoIIRC TruffleRuby is implemented very differently than JRuby and has a lot more potential. So I'm not sure any comparisons can really be made.
- deleted 6y ago[deleted]
- ericb 6y agosource: https://chrisseaton.com/truffleruby/ https://chrisseaton.com/truffleruby/ > TruffleRuby started as my internship project at Oracle Labs in early 2013. It is an implementation of the Ruby programming language on the JVM, using the Graal dynamic compiler and the Truffle AST interpreter framework. TruffleRuby can achieve peak performance well beyond that possible in JRuby at the same time as being a significantly simpler system. In early 2014 it was open sourced and integrated into JRuby for incubation, then in 2017 it became its own project, and now it is part of GraalVM. Since 2019 Shopify has sponsored development. > In early 2014 it was open sourced and integrated into JRuby for incubation Additionally, we also tried Truffle when it was JRuby, or in JRuby, however you want to put it, but without a lot of success. Things could be different now.
- sdegutis 6y agoI interpreted that sentence as meaning it was integrated into the JRuby project as a "home" for the project, similar to being under the management of a particular github org. Not that its implementation was in any way changed or integrated into JRuby.
- ericb 6y agoYour interpretation is understandable, but incorrect. https://www.jruby.org/2016/05/03/jruby-9-1-0-0.html https://www.jruby.org/2016/05/03/jruby-9-1-0-0.html
- eregon 6y agoConcretely, TruffleRuby never shared much in terms of the core language implementation with JRuby (essentially the parser and encoding stuff, never core methods/operators/etc).
- headius 6y agoThe main reason that JRuby and truffle Ruby parted ways was due to their desire to support C extensions. We went down that road many years ago and decided that the performance characteristics of the MRI extension API inside a managed VM like the JVM just would not scale, and most extensions are not thread safe or memory safe. In our estimation, C extensions are the biggest thing holding Ruby back. We wish the Truffle folks the best of luck in their efforts to fix their C extension performance and threading problems but they just aren't a fit for JRuby.