Hacker News Reader

Comment by ericb | Hacker News Reader

I remain skeptical of JRuby. As of about 2-3 years ago, there were many benchmarks touting it's performance, but in our large publicly deployed web app, it always underperformed and switching to MRI on Phusion more than doubled our performance on half the servers. We also spent like a developer-year on issues that accompanied being off the beaten path with JRuby, like various nokogiri complications.

I even contacted the devs at one point with a benchmark that ran jruby directly on strings for several minutes. The answer I got was always that it would eventually perform better than MRI with more warmup. Spoiler: it didn't. Well, maybe I was supposed to run it for another month and it would have.

View on HN

This article is about TruffleRuby, not jruby.

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)

IIRC TruffleRuby is implemented very differently than JRuby and has a lot more potential. So I'm not sure any comparisons can really be made.

source: 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.

I 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.

Your interpretation is understandable, but incorrect.

https://www.jruby.org/2016/05/03/jruby-9-1-0-0.html

Concretely, TruffleRuby never shared much in terms of the core language implementation with JRuby (essentially the parser and encoding stuff, never core methods/operators/etc).

The 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.

If you're willing to try again, I'd love to see that benchmark. JRuby almost always beats MRI on computation heavy benchmarks oh, and we have continued to get faster over the years. I would be very surprised if a string heavy benchmark wasn't faster on JRuby without too much warm up.

Haven't tested this but I feel like JRuby will really exceed only if the solution to your problem benefits from hardcore multi-threaded computations, for not having a GIL in this case diminishes the added JVM overhead.

Also, I'm a sucker for Java but JVM-based things deployability just rocks.

JRuby is also usually faster (sometimes much faster) on straight-line CPU-heavy operations, but you're right... real parallelism is one of the biggest selling points.

Sounds like every other believer of the JVM. I’ve been reading about how Java outperforms C for 20+ years now. When it doesn’t even come close, someone faithful of the JVM insists that I try some new garbage collector or wait for the next release.

Funny, I managed to spent a similar time in this industry and cannot remember any claim of Java being faster than C.

That's not to say it doesn't exist: too many monkeys with internet-connected typewriters will eventually make every claim. But Google turns up a paltry 652 results for "Java faster than C"[0][1].

[0]: https://www.google.com/search?client=safari&rls=en&q=%22java...

[1]: On a related note, I found one of those Google searches with a single hit. Isn't there a name for that? It's "PHP faster than C"

Edit: I'm on a roll here. "Google faster than C" also gets one result: https://www.google.com/search?client=safari&rls=en&q=%22goog...

Java running on a good VM such as HotSpot can outperform C in certain cases.

Reply on news.ycombinator.com