Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Is JRuby Slow?

earthly.dev

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Why Is JRuby Slow?

#31

Post by kaba0 »

oefrha wrote: post #18
zizee wrote: post #9

Earlier quoted context omitted.

Could you not make the same argument about JavaScript? JavaScript was pretty slow for many years. Google then put some significant engineering investment into the V8 engine, resulting in a huge increase in JavaScript's performance.

I think JavaScript performance received very significant investments from the biggest players (Google, Apple, Microsoft, etc.) thanks largely to the fact that you can’t throw more compute at it — JavaScript has to run on crappy user devices developers can’t upgrade. Ruby (or Python) never received anywhere near the JavaScript level of investment in performance. Of course there are fundamental design limitations too.

With GraalVM around, niche languages can pretty much take advantage of the significant investment into the JVM. Its whitepaper is truly novel, but the gist of it is that one has to implement an AST-based interpreter for a dynamic language, and then it will make use of state-of-the art JVM GCs, JIT, etc. TruffleRuby is the fastest Ruby implementation around, GraalJS can after warmup match the performance of V8, so it is indeed a very interesting technology.

Re: Why Is JRuby Slow?

#32

Post by jshen »

lf-non wrote: post #26
jshen wrote: post #12

Earlier quoted context omitted.

It can be with work. This is basically true of all languages. I remember telling my team that I wanted them to use Java instead of python for some new service we were building because I wanted it to scale better. They were not happy about it, and they coded up two versions, one in python and one in Java. I was shocked by the results, they performed roughly equally in terms of latency and scaling. When I dug into it,…

I am curious what library was this and what was it doing. We used spring expression language for dynamic evaluation of (user-defined) expressions in our code and for most cases we could compile and cache the expressions after first usage and invoking them was really fast and close to pure java expressions. We also had some JVM-python interop which we eventually got rid of (in favor of kotlin) because we were unable t…

It was the Google datastore library maybe 5-7 years ago.

Re: Why Is JRuby Slow?

#33

Post by dragonwriter »

habibur wrote: post #24

Here's the summary: Ruby like most of all other Linux applications from that age was written to run in multi-process mode for parallelism, instead of being multi threaded. But running multi-process is heavy on the JVM as it has to load the virtual machine and JIT for every process start, special when the processes are short lived. Java solves it by encouraging running things as multi-threaded instead of multi-process…

> Ruby like most of all other Linux applications from that age was written to run in multi-process mode for parallelism, instead of being multi threaded.

That’s...not really true. Ruby wasn’t really written with parallelism in mind at all, because it mostly ran on machines that couldn’t run really parallel processes. MRI threads were originally green threads, which allow a high degree of concurrency without parallelism, with less overhead than native threads.

When old MRI was replaced with YARV in 1.9 (which became the new MRI), it got native threads with a global VM lock (GVL, similar idea to Python’s GIL) which allowed running thread-safe native code with real parallelism but only having one thread running Ruby code at a time. This made Ruby thread-based concurrency somewhat more expensive, but some parallelism possible in Ruby (as native code can and some basic common processes like waiting on I/O do release the GVL.)

And Ruby 3.0 introduces a new parallelism model with Ractors (basically inspired by the Actor model), which are logically above the thread level (each contains its own set of nonshared threads) and below the process, don’t share mutable state within the VM, and each have their own VM lock, allowing a higher degree of Ruby parallelism without going multiprocess.

Re: Why Is JRuby Slow?

#34

Post by jillesvangurp »

phibz wrote: post #28

I was surprised at the level of analysis and optimization here. Just running flame graph and saying "I think IO is slow" isn't going to cut it. Let's break out a profiler and dig in to the output. And also try some Java tools like your kit.

Exactly, this is not jruby being slow but a particular ruby program being slow on jruby. There is a reason for that and it is extremely likely to be a fixable problem. This is code that was never optimized for the JVM so there is probably all sorts of stuff happening that makes a lot of sense on MRI that is maybe a bit sub optimal on the JVM.

One thing that comes to mind is that a lot of performance critical stuff in ruby is implemented via native libraries. The Jruby ecosystem has alternate implementations for a lot of that stuff. But it is probably also able to interface with native code directly. That sounds like that might be a little bit of a bottleneck potentially. And any alternate java based replacements for whatever is being called might have its own issues/bugs/etc.

But instead of hypothesizing what the problem might be (and getting that wrong repeatedly), profiling tends to be much more effective indeed. I've done this a couple of times to diagnose performance issues and it rarely is anything you'd expect. Once you know where it is spending its time, you can usually mitigate the issues. Use a profiler, add some logging, instrument the jvm, etc. There are lots of ways to do this. Even just knowing how often it starts a new process would be good to know. It's apparently more than once because otherwise you'd expect --dev to not speed things up like it did.

Re: Why Is JRuby Slow?

#35

Post by kaba0 »

cutler wrote: post #6

If you want fast Ruby it seems Crystal is your only option. Ruby is an interpreted language released in 1996 for scripting. Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat?

Since when did JRuby or Truffle Ruby fall flat? The article is about a given usecase/lib, that as others mentioned uses multiple processes, which doesn’t really favor a JIT runtime.

Re: Why Is JRuby Slow?

#36

Post by dragonwriter »

tmp231 wrote: post #5

I remember about 10 years ago the promise was that JRuby was going to let ruby be basically as fast as Java for many things. Invokedynamic and all that.

> I remember about 10 years ago the promise was that JRuby was going to let ruby be basically as fast as Java

I’m pretty sure it was more than 10 years ago that Charles Nutter wrote a detailed description of why that wasn’t going to happen without breaking compatibility with Ruby, identifying the specific language features preventing that.

Re: Why Is JRuby Slow?

#37

Post by dragonwriter »

cutler wrote: post #6

If you want fast Ruby it seems Crystal is your only option. Ruby is an interpreted language released in 1996 for scripting. Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat?

> If you want fast Ruby it seems Crystal is your only option.

Crystal may be fast, but its definitely bot Ruby. Choices for fast not-Ruby are not lacking.

> Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat?

Weird that you don’t put Ruby 1.9+ on that list, though that is as much or more a switch from what immediately preceded it with parallelism as an improvement area as 3.0 is (sure, Ractors are a bigger language change, but going from green threads to native threads with a VM lock was a major implementation change.) The difference is that 3.0’s relevant improvements are still experimental and its easier to misrepresent “haven’t yet stabilized and seen wide production use” as “fell flat” than it would be to claim thr same thing about 1.9’s improvements. But its not true in either case.

Re: Why Is JRuby Slow?

#38

Post by ZeroGravitas »

habibur wrote: post #24

Here's the summary: Ruby like most of all other Linux applications from that age was written to run in multi-process mode for parallelism, instead of being multi threaded. But running multi-process is heavy on the JVM as it has to load the virtual machine and JIT for every process start, special when the processes are short lived. Java solves it by encouraging running things as multi-threaded instead of multi-process…

I think I preferred the author's own summary:

> I think there are two reasons for this:

> * Real-World projects like Jekyll involve a lot more code, and JITing that code has a high start-up cost.

> * Real-world code like Jekyll or Rails is optimized for MRI Ruby, and many of those optimizations don’t help or actively hinder the JVM.

The title seems a bit provocative, though I guess if you were reading it from within the Jekyll community, it makes sense without further disclaimers, but otherwise the article seems fairly even-handed.

The threading stuff just seems like a special case of his second point.

Re: Why Is JRuby Slow?

#39

Post by ZeroGravitas »

nine_k wrote: post #17
canadianfella wrote: post #8

Earlier quoted context omitted.

> Ruby is an interpreted language released in 1996 for scripting. Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat? Because Lua (1993) and JavaScript (1995) can be very fast.

To be just, Lua is drastically simpler as a language. A simpler language likely takes less effort to write an efficient JIT for its VM.

And javascript's speed seems mostly a result of throwing amazing amounts of smart engineers at it over time, rather than anything inherent in the language itself.

Re: Why Is JRuby Slow?

#40

Post by [deleted] »

crazy5sheep wrote: post #10

There's once I was running some jruby stuff in jenkins during a build, the job kept on hanging on some stage, I thought there must be bug somewhere, I forced kill it a couple of times with no success, but kept the last one running before I head home. Then after a couple of hours, I found out an email said the built was passed... eventually, I had figured out that jruby was using /dev/random, since jenkins was running…

[deleted]
Post reply on HN