7 ms·

JRuby and Truffle Update

130 points by bensummers 11y ago

brudgers 11y ago
Project: https://github.com/jruby/jruby/wiki/Truffle https://github.com/jruby/jruby/wiki/Truffle
VeejayRampay 11y ago
This is exciting. Not only for Ruby itself, but for the field of dynamic languages optimization in general.
jonathanwallace 11y ago
Great work, Chris Seaton et al. I was very impressed with Chris's presentation at Rubyconf about Truffle a few years ago. I look forward to your efforts and results in 2016!
marktangotango 11y ago
News on Truffle/Graalvm has been spotty at best, this report shows the tech is really quite phenomenal! One wonders how Nashorn (new JavaScript impl) performance will turn out. Could Oracle end up owning the fastest js?
- chrisseaton 11y ago
  Nashorn is actually Oracle's existing JS implementation on the JVM. The JS equivalent of JRuby+Truffle is called Graal.js, and is available today from here http://www.oracle.com/technetwork/oracle-labs/program-languages/ http://www.oracle.com/technetwork/oracle-labs/program-langua....
- apo 11y ago
  Here's a recent talk: https://m.youtube.com/watch?v=OUo3BFMwQFo https://m.youtube.com/watch?v=OUo3BFMwQFo
necrodome 11y ago
Are there any low-hanging fruits for contribution? Any pointers for starters?
- chrisseaton 11y ago
  I'd by lying if I said you could find something useful to contribute in just one evening's work, but if you have a few evenings you could probably pick a core library class, see what is currently missing in it, and fill in a few gaps. You'd need to understand Java and Ruby, but we can help you with the rest. Join us #jruby on Freenode IRC, or https://gitter.im/jruby/jruby https://gitter.im/jruby/jruby.
mintplant 11y ago
Was this the project that had some special plan for making native extensions work? I remember seeing something like that a while back on HN.
- chrisseaton 11y ago
  Yes we have an interpreter for C to run C extensions. It runs real C extensions from Oily PNG and PSD Native 3x faster than native, due to inlining C and Ruby together. http://chrisseaton.com/rubytruffle/cext/ http://chrisseaton.com/rubytruffle/cext/ People are now working on an LLVM bitcode interpreter instead, as this should support many languages not just C. There will be info about this at FOSDEM.
  - sandGorgon 11y ago
    Why are you doing that? Jruby has been a complete ecosystem in itself and very few MRI specific gems need porting over. You could spend a whole bunch of time on this and actually not make an impact on people who actually use jruby in production EDIT: now that I think of it, there's one extension that would be very useful - libgit2 + Rugged.
    - AlphaSite 11y ago
      The same system is used by Graal.js and the other languages for their native extensions.
    - nirvdrum 11y ago
      The Truffle backend in JRuby+Truffle uses a different class hierarchy that makes supporting the Java extension API tricky. It's certainly doable and we haven't ruled it out, but the API parts of JRuby really need to be ironed out first. Right now it's essentially anything that's public in JRuby core, which is a bad situation to be in. Various attempts at rectifying that have predictably broken third party code, so it needs to be handled with care. Of course, rather than trying to fix the general problem, we could support the most common JRuby gems out there or the core subset of the API they use. These are just the sorts of things we need to look at a bit more.
sandGorgon 11y ago
* 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 * I haven't looked at the benchmarks, but are they synthetic or are they actually relevant to typical rails usage?
- chrisseaton 11y ago
  We've focused on benchmarks that do metaprogramming and use lots of small intermediate hashes and arrays as we think this is relevant for Rails. See our Acid Test benchmark for an exteme example http://chrisseaton.com/rubytruffle/pushing-pixels/ http://chrisseaton.com/rubytruffle/pushing-pixels/ Evan Phoenix recently said at RubyKaigi that a weaker version of this benchmark is the standard that Ruby 3 should be aiming at.
  - sandGorgon 11y ago
    Your help page states that this does not support gems yet - so I guess a running Rails app has not been tested yet? Would love to try it out if you did.
    - nirvdrum 11y ago
      Correct. We do not currently support RubyGems. It's something we're working towards, but it's a fairly complex project and not having OpenSSL support currently limits the ability to install gems quite a bit. However, we do ship with a tool that will install gems using JRuby without Truffle and then running your script with a the $LOAD_PATH set up appropriately. Please see: https://github.com/jruby/jruby/blob/master/lib/ruby/truffle/jruby%2Btruffle/README.md https://github.com/jruby/jruby/blob/master/lib/ruby/truffle/... Re: Rails ... there's still a fair bit of work involved there. We've been working on passing all the ActiveSupport tests (we're currently at 99%), as that's a core dependency. We haven't looked much into the other gems. Things like ActiveRecord simply won't work since we currently don't run C or Java extensions. I think it's a bit more likely we'll start with a custom driver of some sort with an ActiveModel front-end. I strongly suspect the asset pipeline and Spring will present problems, as well. The rest of Rails should pull together somewhat quickly and that's a big goal for us in 2016.
rubyfan 11y ago
This is an exciting update. I've been watching with bated breath on this work. @chrisseaton is startup time similar to today's JRuby, i.e. slow? I feel like that's always been a bit of a sticking point for JRuby.
- nirvdrum 11y ago
  Unfortunately, our startup time is actually a bit worse than JRuby's. We end up having to essentially bootstrap two different runtimes, since JRuby+Truffle makes use of functionality from the main JRuby runtime. It's a known problem and we have concrete steps to take on improving the situation. It will get better, but you'll likely be disappointed with startup time today. In addition to the steps we're taking, there's a sister project in Oracle Labs called the Substrate VM that would allow us to build a static binary with startup time on par with MRI. I can't speak to release plans or timelines on anything. I only mention it to show that startup time is a concern for us and we're thinking about how to fix it in a wide variety of ways.
  - rubyfan 11y ago
    Good to know work is being done there. Since not all of Ruby's use case is long running, startup time is pretty relevant for scripts.
ksec 11y ago
Now that biggest question is, when will Truffle and GraalVM finish, or at least available not as an experiment or lab project.
- pron 11y ago
  Graal will be available as a plugin to stock OpenJDK's HotSpot in Java 9: http://openjdk.java.net/jeps/243 http://openjdk.java.net/jeps/243 (although I don't know what it means regarding the production-readiness of Graal itself)
dankohn1 11y ago
Congrats on the progress and thanks for the very useful update. Unlike many messages of this sort, yours answered all my questions, was appropriately respectful to alternative implementations, and included URL footnotes. Nice job.

130 points by bensummers 11y ago

brudgers 11y ago

Project: https://github.com/jruby/jruby/wiki/Truffle https://github.com/jruby/jruby/wiki/Truffle

VeejayRampay 11y ago

This is exciting. Not only for Ruby itself, but for the field of dynamic languages optimization in general.

jonathanwallace 11y ago

Great work, Chris Seaton et al. I was very impressed with Chris's presentation at Rubyconf about Truffle a few years ago. I look forward to your efforts and results in 2016!

marktangotango 11y ago

News on Truffle/Graalvm has been spotty at best, this report shows the tech is really quite phenomenal! One wonders how Nashorn (new JavaScript impl) performance will turn out. Could Oracle end up owning the fastest js?

chrisseaton 11y ago
Nashorn is actually Oracle's existing JS implementation on the JVM. The JS equivalent of JRuby+Truffle is called Graal.js, and is available today from here http://www.oracle.com/technetwork/oracle-labs/program-languages/ http://www.oracle.com/technetwork/oracle-labs/program-langua....
apo 11y ago
Here's a recent talk: https://m.youtube.com/watch?v=OUo3BFMwQFo https://m.youtube.com/watch?v=OUo3BFMwQFo

necrodome 11y ago

Are there any low-hanging fruits for contribution? Any pointers for starters?

chrisseaton 11y ago
I'd by lying if I said you could find something useful to contribute in just one evening's work, but if you have a few evenings you could probably pick a core library class, see what is currently missing in it, and fill in a few gaps. You'd need to understand Java and Ruby, but we can help you with the rest. Join us #jruby on Freenode IRC, or https://gitter.im/jruby/jruby https://gitter.im/jruby/jruby.

mintplant 11y ago

Was this the project that had some special plan for making native extensions work? I remember seeing something like that a while back on HN.

chrisseaton 11y ago
Yes we have an interpreter for C to run C extensions. It runs real C extensions from Oily PNG and PSD Native 3x faster than native, due to inlining C and Ruby together. http://chrisseaton.com/rubytruffle/cext/ http://chrisseaton.com/rubytruffle/cext/ People are now working on an LLVM bitcode interpreter instead, as this should support many languages not just C. There will be info about this at FOSDEM.
- sandGorgon 11y ago
  Why are you doing that? Jruby has been a complete ecosystem in itself and very few MRI specific gems need porting over. You could spend a whole bunch of time on this and actually not make an impact on people who actually use jruby in production EDIT: now that I think of it, there's one extension that would be very useful - libgit2 + Rugged.
  - AlphaSite 11y ago
    The same system is used by Graal.js and the other languages for their native extensions.
  - nirvdrum 11y ago
    The Truffle backend in JRuby+Truffle uses a different class hierarchy that makes supporting the Java extension API tricky. It's certainly doable and we haven't ruled it out, but the API parts of JRuby really need to be ironed out first. Right now it's essentially anything that's public in JRuby core, which is a bad situation to be in. Various attempts at rectifying that have predictably broken third party code, so it needs to be handled with care. Of course, rather than trying to fix the general problem, we could support the most common JRuby gems out there or the core subset of the API they use. These are just the sorts of things we need to look at a bit more.

sandGorgon 11y ago

* 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 * I haven't looked at the benchmarks, but are they synthetic or are they actually relevant to typical rails usage?

chrisseaton 11y ago
We've focused on benchmarks that do metaprogramming and use lots of small intermediate hashes and arrays as we think this is relevant for Rails. See our Acid Test benchmark for an exteme example http://chrisseaton.com/rubytruffle/pushing-pixels/ http://chrisseaton.com/rubytruffle/pushing-pixels/ Evan Phoenix recently said at RubyKaigi that a weaker version of this benchmark is the standard that Ruby 3 should be aiming at.
- sandGorgon 11y ago
  Your help page states that this does not support gems yet - so I guess a running Rails app has not been tested yet? Would love to try it out if you did.
  - nirvdrum 11y ago
    Correct. We do not currently support RubyGems. It's something we're working towards, but it's a fairly complex project and not having OpenSSL support currently limits the ability to install gems quite a bit. However, we do ship with a tool that will install gems using JRuby without Truffle and then running your script with a the $LOAD_PATH set up appropriately. Please see: https://github.com/jruby/jruby/blob/master/lib/ruby/truffle/jruby%2Btruffle/README.md https://github.com/jruby/jruby/blob/master/lib/ruby/truffle/... Re: Rails ... there's still a fair bit of work involved there. We've been working on passing all the ActiveSupport tests (we're currently at 99%), as that's a core dependency. We haven't looked much into the other gems. Things like ActiveRecord simply won't work since we currently don't run C or Java extensions. I think it's a bit more likely we'll start with a custom driver of some sort with an ActiveModel front-end. I strongly suspect the asset pipeline and Spring will present problems, as well. The rest of Rails should pull together somewhat quickly and that's a big goal for us in 2016.

rubyfan 11y ago

This is an exciting update. I've been watching with bated breath on this work. @chrisseaton is startup time similar to today's JRuby, i.e. slow? I feel like that's always been a bit of a sticking point for JRuby.

nirvdrum 11y ago
Unfortunately, our startup time is actually a bit worse than JRuby's. We end up having to essentially bootstrap two different runtimes, since JRuby+Truffle makes use of functionality from the main JRuby runtime. It's a known problem and we have concrete steps to take on improving the situation. It will get better, but you'll likely be disappointed with startup time today. In addition to the steps we're taking, there's a sister project in Oracle Labs called the Substrate VM that would allow us to build a static binary with startup time on par with MRI. I can't speak to release plans or timelines on anything. I only mention it to show that startup time is a concern for us and we're thinking about how to fix it in a wide variety of ways.
- rubyfan 11y ago
  Good to know work is being done there. Since not all of Ruby's use case is long running, startup time is pretty relevant for scripts.

ksec 11y ago

Now that biggest question is, when will Truffle and GraalVM finish, or at least available not as an experiment or lab project.

pron 11y ago
Graal will be available as a plugin to stock OpenJDK's HotSpot in Java 9: http://openjdk.java.net/jeps/243 http://openjdk.java.net/jeps/243 (although I don't know what it means regarding the production-readiness of Graal itself)

dankohn1 11y ago

Congrats on the progress and thanks for the very useful update. Unlike many messages of this sort, yours answered all my questions, was appropriately respectful to alternative implementations, and included URL footnotes. Nice job.