
TruffleRuby Status - ksec
http://lists.ruby-lang.org/pipermail/jruby/2017-January/000511.html
======
dashesyan
What is TruffleRuby?

"JRuby+Truffle 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.
JRuby+Truffle 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."

via [http://chrisseaton.com/rubytruffle/](http://chrisseaton.com/rubytruffle/)

I've used JRuby for a while, but I hadn't heard of Truffle

------
ianopolous
I'm super excited that they are going to be releasing substrate VM. Substrate,
graal and truffle are all independently awesome technologies.

The JVM is an exciting place to be right now.

~~~
MrBra
But at the same time it's interesting to note that RubyTruffle will not even
rely on the JVM to run!

------
xutopia
"optcarrot benchmark
[https://github.com/mame/optcarrot](https://github.com/mame/optcarrot) runs
around 9x faster on JRuby+Truffle than it does on MRI"

That's blazingly fast! The missing part now is C extension support and they
seem confident to be able to deliver this.

Color me impressed.

~~~
masklinn
> The missing part now is C extension support

Wasn't part of truffle's point and advantage that it would interpret and JIT C
code alongside Ruby code and optimise across the boundary? Is the missing part
just the declaration of the MRI API on the C-side, or is it pre-compiled (and
thus not interpretable) C extensions?

~~~
chrisseaton
We wrote a first paper about it back in 2015. We've spent 2016 going back and
doing a better implementation of the idea. We hope to make it useful for real
C extensions in 2017. So it's still 'missing' in that it isn't integrated and
in use yet.

We work on the C source code (actually the LLVM bitcode) rather than compiled
C extensions, yes.

~~~
sandGorgon
Actually, I would deprioritize c extension support.

The jruby ecosystem is extremely mature and production ready. For example,
database connectors exist which are pure java rather than based on c
extensions. They may be better as well. Same goes for ssl
([https://github.com/jruby/jruby-
openssl/blob/master/README.md](https://github.com/jruby/jruby-
openssl/blob/master/README.md)) and xml parsing
([https://github.com/YorickPeterse/oga/blob/master/README.md](https://github.com/YorickPeterse/oga/blob/master/README.md))

Also goes for all the json parsing, etc stuff which seems to need c
extensions. Lots of systems stuff is perfectly workable using jruby
([https://github.com/minimagick/minimagick/blob/master/README....](https://github.com/minimagick/minimagick/blob/master/README.md))

This would be a different story if you were doing jython fof example - python
does not have a viable java based ecosystem.

If I were you, i would NOT focus on c extensions and instead work on other
stuff (like startup speed)

~~~
chrisseaton
Unfortunately running JRuby's Java extensions doesn't look any easier than C
extensions, so we've gone with C extensions to begin with.

Both types of extensions are hard because they're written against an API which
is just the entire internals of their implementations. If you don't use the
same internals it's very hard to meet that API.

This explains in depth
[https://www.youtube.com/watch?v=YLtjkP9bD_U](https://www.youtube.com/watch?v=YLtjkP9bD_U)

------
jcdavis
Great stuff!

The Graal/Truffle/Sulong stack is pretty amazing, being able optimize through
the ruby/C boundary is crazy. Really looking forward to see what comes out of
that work this year and beyond.

------
pmontra
If it runs Rails and it goes through a test suite at least as quickly as MRI
then I'm definitely going to use it. JRuby is just too slow to start.

~~~
mtw
It doesn't support nokogiri yet -- a letdown for me

~~~
pmontra
Yes, big problem

------
rubyfan
I'm pumped for startup improvements, it's about the only downside to JRuby.

Does the ability to use Java libraries with TruffleRuby go away with
SubstrateVM though?

~~~
chrisseaton
You have to compile the Java libraries that you want to use into your binary,
or we're looking at doing a Java bytecode interpreter in the same manner as
our Ruby interpreter.

~~~
BenoitP
On an unrelated topic, will TruffleRuby have all the OpenJDK's GC algorithms
available?

I'm thinking of Shenandoah specifically.

I understand they depend on inserting barriers with JVMCI, so I'm hopeful for
compatibility. How is SubstrateVM build? It is made out of using the OpenJDK
code base in a specific manner?

~~~
chrisseaton
I don't think we have the barriers for Shenandoah yet. It would be easy enough
to add them I believe. SVM is a new VM implemented in Java. It isn't made from
the OpenJDK's native implementation in C++.

~~~
zigzigzag
If that's the case surely it doesn't matter if you have the barriers for
Shenandoah, as it's written in C++ for HotSpot. Wouldn't you have to rewrite
it from scratch in Java for SubstrateVM?

~~~
chrisseaton
Yes for SVM having the barriers won't help. But I read the question as about
TruffleRuby in general, which can run on OpenJDK where Shenandoah is
available.

------
digitalnalogika
Are there any performance gains on that sample Rails application, however
simple?

~~~
chrisseaton
We haven't started to benchmark Rails yet. We're hopeful that we will do well
on Rails because actually our most powerful and novel optimisations are for
Rails-style code, such as metaprogramming and lots of intermediate arrays and
hashes.

------
miloshadzic
Re: the C extensions: Since the performance is so much better, would it make
sense to replace gems that use c extensions with pure ruby implementations?
Would that still yield better performance than MRI?

~~~
chrisseaton
> would it make sense to replace gems that use c extensions with pure ruby
> implementations

I think that the best practice for C extensions when used for performance is
that Gems have both a pure Ruby reference implementation and a C extension.
This means all implementations can run them and more people can read the code.
OilyPNG and PSD Native do this and it's been extremely helpful to my research.

C extensions, even when run in our interpreter, tend to run faster than Ruby
code because C has simpler semantics and needs fewer guards (checks) when
running code.

I haven't done a careful comparison of C extension performance compared to
Ruby performance when both are running on Graal. I should do that.

~~~
miloshadzic
Thanks

------
ksec
217 Points and an 1 day old news and it is Ranked 8xth on HN. While others has
less point in similar time frame gets higher. And i only got less then 100
Karma points, which means either some people downvote the story or there are
lots of bot.

30 Comments which means HN as a community has lost interest in Ruby.

~~~
petercooper
Not just HN. If you look at the last week's "trending" Ruby GitHub repos,
they're mostly old projects or even things from other ecosystems:
[https://github.com/trending/ruby?since=weekly](https://github.com/trending/ruby?since=weekly)
(e.g. fastlane, brew, awesome-react-native).

~~~
ksec
Yes. Sigh.

A signal that Ruby is dying? ( Or in maintenance mode, or not growing, which
ever you may prefer to word it ) Only Last week someone replied to me on HN
that their areas dont have any Open Jobs for Ruby Devs.

