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

51–60 of 64 posts

Re: Why Is JRuby Slow?

#51

Post by cutler »

kaba0 wrote: post #31
oefrha wrote: post #18

Earlier quoted context omitted.

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…

How is matching V8 performance a big deal given that MRI Rack isn't significantly slower than Node?

Re: Why Is JRuby Slow?

#52

Post by rubyfan »

My biggest problem with JRuby really wasn’t server performance or multithread - it was start time. If you used JRuby for something like scripting then you feel it way more. Try using it for a map reduce process on large data workloads in Hadoop and you see the startup time of JRuby materially.

Q: Why would one do that? A: Ability to bundle your code to hadoop machines you don’t control

Re: Why Is JRuby Slow?

#53

Post by tom_mellior »

tom_mellior wrote: post #42
nijave wrote: post #13

Seems like there's obviously a big I/O performance difference. Maybe it's something simple like buffering being setup differently or not at all or sync vs async. It'd be interesting to dig in more Even something like mmap can drastically improve performance since it lets the kernel handle I/O asynchronously from your program execution (so your code doesn't block as much or as easily on I/O)

We don't know that it's really I/O, as in "pushing some bytes to the system". All we know is that the author saw a hot method called "write" and stopped the analysis there. It might well be something like messing around with character encodings to get those bytes in the first place.

Thinking about this more, we know that the author saw a hot "write" method in the profile for the fast run and doesn't have a profile for the slow run. The slow versions could be spending most of their time in a completely different place.

Re: Why Is JRuby Slow?

#54

Post by agumonkey »

rubyfan wrote: post #52

My biggest problem with JRuby really wasn’t server performance or multithread - it was start time. If you used JRuby for something like scripting then you feel it way more. Try using it for a map reduce process on large data workloads in Hadoop and you see the startup time of JRuby materially. Q: Why would one do that? A: Ability to bundle your code to hadoop machines you don’t control

Clojure had the same issue until someone made babashka through graalvm. It's now faster to boot than python..

Re: Why Is JRuby Slow?

#55

Post by lf-non »

sandstrom wrote: post #46

My impression is that interest in JRuby has gradually declined, in favor of CRuby (MRI). I guess both because CRuby has gotten a lot faster, and because in practice any difference is easily paved over with extra hardware (which is cheap).

IMHO interest in ruby (irrespective of implementation) itself is declining.

A lot of people have realised that dynamic typing hinders maintenance of long lived projects and the tooling and dev experience with type safe languages have also gotten much better over last few years.

Despite having worked with Ruby for multiple years, I pick Kotlin/C# for new projects.

I know ruby has recently introduced support for typing, but until the wider ecosystem embraces type-safety it is gonna be an uphill battle to write type-safe code in ruby.

Re: Why Is JRuby Slow?

#56

Post by vrotaru »

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…

IBM J9 has something called the JIT server. My understanding that JIT is done is one process and then provided as a service to clients (other processes)

Never used it though, so no idea how it works in practice.

Re: Why Is JRuby Slow?

#57

Post by lf-non »

kaba0 wrote: post #30
lf-non wrote: post #26

Earlier quoted context omitted.

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…

There is nothing at the JVM level that would disallow such dynamism. Clojure, JRuby, JPython all can run on the JVM. Also, if you are looking for interop, then GraalVM might be worth a look — not the better-known AOT part, but the runtime one, which can seamlessly do interop between a number of languages, and it even optimizes between them!

Yes, being possible and being performant are two very different things.

What I intended to convey in my previous comment was that using strategies like pre-compilation (eg. Spring EL) it is possible to get good performance even for dynamic logic not known at runtime.

So I was curious what was so dynamic about this use case that JVM performance drops down to pythonesque level.

I don't want to speculate - maybe there is something that JVM is unable to optimize; maybe it is something weird happening in the library; or maybe python has gotten really better in recent past or this use case was able to benefit from some python lib with native bindings.

Re: Why Is JRuby Slow?

#58

Post by pjmlp »

vrotaru wrote: post #56
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…

IBM J9 has something called the JIT server. My understanding that JIT is done is one process and then provided as a service to clients (other processes) Never used it though, so no idea how it works in practice.

It shares PGO data across the cluster so that all JIT clients eventually drive to an optimal set of common optimizations.

As it runs standalone it can also take advantage of the whole server for itself for more resource hungry optimizations without impacting running code.

The generated code is then reflected back into the client JVM instances.

Re: Why Is JRuby Slow?

#59

Post by pjmlp »

saurik wrote: post #48
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…

The way Android solved this problem (before they implemented AOT) was to fork the JVM post-load (and I think even JIT) of all the core Java and Android classes; the real somewhat-fundamental problem with the JVM in a multi-process system isn't really having to "load the virtual machine and JIT for every process start" but the multiple, almost-certainly-uncoordinated garbage collectors. http://www.cydiasubstrate.com/i…

They still use zygote, however as expected, cheap Android devices aren't the best hardware to run an AOT compiler, so with Android 7 they introduced a multitier execution, with interpreter hand written in Assembly, JIT compiler and AOT that take advantage of PGO data.

The AOT compiler only runs when the device is idle.

Starting with Android 10, they introduced a mechanism to upload PGO data into the store, so that when an APK is installed, if such data is already available the JIT/AOT don't have to relearn everything from scratch regarding the application.

https://source.android.com/devices/tech/dalvik/jit-compiler

They also improved the GC several times, the latest generation is quite good,

https://source.android.com/devices/tech/dalvik/gc-debug

There are several Google IO talks about how they went through this.

Re: Why Is JRuby Slow?

#60

Post by blablabla123 »

Around 2010 I really enjoyed working with JRuby. At that time dynamic languages weren't really a thing but I was able to convince my boss to try it in a project because of Java library compatibility. So I used it for a Swing GUI application doing data processing combined with R, Postgres and Processing. It was really fun to write it. (Apart from that I also used in on Google App Engine) I never had the impression it was slower or less responsive than any other language, however startup times were quite slow. But I think that was due to the JVM. The way Ruby developed - into the language of Rails - I don't see myself writing anything CPU bound with it though.

That said, I wish the article would just include numbers without the startup times. I also remember people claiming back at that time JRuby would be much faster than MRI.

Post reply on HN