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?
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.
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.
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?
It's not clear that would result in a speed up as graal + truffle can already do optimisations across language boundaries. So optimising a Ruby function that calls a C one can for example inline the C function and then continue optimising.
> 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.
There's nothing that prevents that. However, Ruby is traditionally thought of as a language written in C, and the gold standard for a Ruby interpreter to be 100% compatible with anything that runs on MRI. So writing JVM specific extensions means losing MRI compatibly, at which point you're deviating from tradition.
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.
I think that's a fair trade off. If people want to use Java and ruby together without having to worry about that precompilation step then there is still standard JRuby.
I really like the idea of TruffleRuby becoming its own super fast Ruby implementation unhindered by the need to provide the same feature set as JRuby.
Well you'd only use SubstrateVM when deploying to production, so I don't know why anyone wouldn't want to "worry about that precompilation step". During development it should be irrelevant. Or am I missing something here?
In an ideal world, you'd use the same Ruby for development and production -- you just get more predictable results that way. With SubstrateVM, we're addressing the startup time issue that usually drives a team to have different Ruby implementations in development and production. If you have another use case for split dev/production environments, please let me know.
A limitation of the SubstrateVM build is you can't just start calling code in a JAR you load at runtime -- that needs to be built into the image. A common use case for JRuby is as a really awesome shell to Java. You won't have that capability with SubstrateVM because we can't load arbitrary Java code at runtime. Likewise, you couldn't just swap out JARs with different implementations of interfaces on the fly (e.g., JDBC usage patterns). And JRuby can load gems that themselves have Java code in them, which also wouldn't work (setting aside the fact we also don't support their extension API).
Thanks, I was confusing myself there. Obviously you would really want to use SubstrateVM in development to get that sweet fast startup - I'm just blind to the startup time angle since I use the zeus gem to keep my application always already started up and fork off new processes as needed.
I was considering the case of building a single executable, including the entire ruby application and its dependencies, via SubstrateVM. This could make deployment a lot simpler.
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?
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++.
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?
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.
Graal already can compile bytecode, right, so I don't get why SubstrateVM finds it so hard to dynamically load code but a truffle java bytecode interpreter would work
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.
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.
"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."
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.
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 (e.g. fastlane, brew, awesome-react-native).
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.
42 comments
[ 2.8 ms ] story [ 39.2 ms ] threadThat's blazingly fast! The missing part now is C extension support and they seem confident to be able to deliver this.
Color me impressed.
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?
Compilers are cool.
We work on the C source code (actually the LLVM bitcode) rather than compiled C extensions, yes.
Ah OK, I guess I remember the 2015 news and thought it a "done deal" rather than a POC/WIP. Thanks.
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) and xml parsing (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....)
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)
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
Is there an HN reader app that does it? or just HN jargon?
The JVM is an exciting place to be right now.
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.
Pure Java is pretty fast, and an existing library has the advantage of not just already being around, but probably being battle-tested.
Does the ability to use Java libraries with TruffleRuby go away with SubstrateVM though?
I really like the idea of TruffleRuby becoming its own super fast Ruby implementation unhindered by the need to provide the same feature set as JRuby.
A limitation of the SubstrateVM build is you can't just start calling code in a JAR you load at runtime -- that needs to be built into the image. A common use case for JRuby is as a really awesome shell to Java. You won't have that capability with SubstrateVM because we can't load arbitrary Java code at runtime. Likewise, you couldn't just swap out JARs with different implementations of interfaces on the fly (e.g., JDBC usage patterns). And JRuby can load gems that themselves have Java code in them, which also wouldn't work (setting aside the fact we also don't support their extension API).
I was considering the case of building a single executable, including the entire ruby application and its dependencies, via SubstrateVM. This could make deployment a lot simpler.
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?
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.
"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/
I've used JRuby for a while, but I hadn't heard of Truffle
30 Comments which means HN as a community has lost interest in Ruby.
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.