[jruby] JRuby+Truffle Update

Hello all in the JRuby community, It has been a long time since there was any centralised update from the JRuby+Truffle research project, so the end of 2015 provides a good opportunity to do that. If you aren’t already aware of it, JRuby+Truffle [1] is a research project to provide a new high performance and complete backend for JRuby, using two new pieces of technology from Oracle Labs - the Truffle language implementation framework and the Graal JIT compiler. There were two goals there - high performance, meaning it's fast, and complete, meaning that it runs real Ruby code. Let’s review how JRuby+Truffle is doing on those two fronts. As a very crude overview of performance, JRuby+Truffle with the latest development version of GraalVM across 63 benchmarks is over 31x faster than MRI 2.3.0, over 32x faster than Rubinius 2.5.8, over 17x faster than Topaz (Ruby using PyPy technology) and over 24x faster than JRuby 9.0.4.0 with invokedynamic [2]. https://gist.github.com/chrisseaton/bf7a7ebf4c31702d37e5 Some benchmarks, such as the ‘linear dodge’ composition filter from PSD.rb are over 300x faster than JRuby - and this is real code taken from real gems that allocate objects and use metaprogramming - not artificial scientific workloads. If you just focus on the ’shootout’ benchmarks we’re almost 6x faster than JRuby, but if you focus on production benchmarks from Chunky PNG and PSD.rb we’re over 50x faster than JRuby. We think this shows how can be optimise more effectively on more realistic Ruby code than synthetic benchmarks. Obviously, benchmarking is extremely complex, results vary enormously and you should read more and examine them for yourself if you are interested. An entire chapter of my PhD is devoted to the how and why of our benchmarking system [3], and the same approach is now in use by IBM’s OMR project [4], and Oracle’s ahead of time compilation project for Java [5]. In terms of completeness, JRuby+Truffle passes 93% of the RubySpace language specs [6] and 90% of the core library specs [7]. We also pass a great deal of the stdlib specs, but coverage is very patchy there so talking about the percentage doesn’t make sense [8]. Most importantly, we are starting to be able to run real parts of the Ruby ecosystem. In 2015 we became able to run web servers like Webrick, web frameworks like Sinatra and database clients like Redis working. I would very cautiously say that if you take a gem or application that doesn’t use native code and doesn’t use some tricky things from the standard library like openssl, and keeping in mind those same restrictions across all your dependencies, then it will probably more or less work on JRuby+Truffle. We’re now ready to start accepting GitHub issues if this isn’t the case. Looking forward, we aim to show that running Rails on JRuby+Truffle is possible in 2016. That doesn’t mean running any random Rails application, but it does mean showing that the stack in general works on JRuby+Truffle. As a first step, JRuby+Truffle already passes 99% of Active Support specs. Is JRuby+Truffle going to be any faster at running Rails, when it eventually can do that? Well, we’re quietly confident based on what we know Rails applications do, and what we know JRuby+Truffle optimises well. Metaprogramming [9, 10], small intermediate data structures [11] and lots of method calls are what JRuby+Truffle does best [12], and it’s also what Rails does [3]. JRuby+Truffle is now a regular part of the JRuby 9 releases. You still need a modified JVM to run it - I recommend the GraalVM, available from the Oracle Technology Network [13], or you can build Graal from scratch from OpenJDK if you want [14]. It should soon be possible to use Graal in unmodified JDK 9 early access builds, so you won’t even need a custom JVM any more. GraalVM is actually even more than a VM with the Graal JIT compiler in it. Oracle Labs are working on many Truffle languages, such as R [15] and JavaScript. The GraalVM integrates all these languages into one package and is beginning to provide sophisticated interoperability between them. The summary is that JRuby+Truffle is making fast progress. We are very close to having a complete implementation of the language and most of the standard library. Performance has never permanently regressed from our early benchmarks in 2013 as we’ve implemented more and more of the language - in fact performance has only increased. The team is now three Oracle employees: me (Chris), Kevin, Petr, and our JKU Linz collaborator, PhD student Benoit. Of course, there’s a large team behind us working on Truffle and Graal, and we also have open source contributors such as Brandon Fish. We're preparing to grow the team, so if this work interests you and you are looking for a job please get in touch with me by email. We're looking for people with a good understanding of Ruby, Rails and Java. You don’t need to be an expert on compilers (but it’s great if you are). Remote work is fine. As always, we want to make it clear that we’re building on the efforts of the JRuby, core Ruby and Rubinius teams and are very grateful for all their work. Chris [1] https://github.com/jruby/jruby/wiki/Truffle [2] http://jruby.org/bench9000/ [3] http://chrisseaton.com/phd/ [4] https://www.youtube.com/watch?v=kOnyJurioyw [5] https://www.youtube.com/watch?v=Xybzyv8qbOc [6] http://lafo.ssw.uni-linz.ac.at/graalvm/jruby/specs-language-report/html/ [7] http://lafo.ssw.uni-linz.ac.at/graalvm/jruby/specs-core-report/html/ [8] http://lafo.ssw.uni-linz.ac.at/graalvm/jruby/specs-library-report/html/ [9] http://chrisseaton.com/rubytruffle/pldi15-metaprogramming/pldi15-marr-et-al-zero-overhead-metaprogramming.pdf [10] https://www.youtube.com/watch?v=lRMWwjqbXUo [11] http://chrisseaton.com/rubytruffle/small-data-structures/ [12] http://chrisseaton.com/rubytruffle/how-method-dispatch-works-in-jruby-truffle/ [13] https://github.com/jruby/jruby/wiki/Downloading-GraalVM [14] https://github.com/jruby/jruby/wiki/Building-Graal [15] https://bitbucket.org/allr/fastr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ruby-lang.org/pipermail/jruby/attachments/20151231/46b142e5/attachment.html>