Massive Ruby speed boost with JRuby and Java 7.

http://blog.jruby.org/2011/12/getting_started_with_jruby_and_java_7/

by donw • 15 years ago

147 78 15 years ago

blog.jruby.org

gmac• 15 years ago

Anyone done any comparisons between this and the official (MRI/KRI/YARV) 1.9.2 or 1.9.3?

headius22• 15 years ago

I obviously have, but I have a lot of respect for the MRI folks and usually don't publish those results. You're free to try it out yourself. In general, JRuby should be significantly faster than MRI 1.9.2 or 1.9.3 for running Ruby code, and usually faster inside the core classes (String, Array, etc). If it's not, I consider it a bug, and encourage bug reports to that effect.

fendale3• 15 years ago

Until recently I dismissed JRuby, but then I needed to run some stress testing code against an Oracle DB. With MRI Ruby and the OCI8 library, the Ruby overhead stopped me being able to push the database hard enough. I switched to JRuby and JDBC and the results were amazing, so I am converted. The only niggle I have is the startup overhead, which I know is a JVM thing. Not a problem for my benchmarking, but a little bit of an annoyance for a command line ruby tool I use.

As an aside, I did run across a bug, not performance related, but a case around popen where JRuby doesn't behave the same as MRI - I raised a ticket (JRUBY-6225) but it doesn't seem to be getting any traction. I understand there are probably plenty of tickets to be prioritized, but this one is a bit of a show stopper for me. If anyone from the JRuby team is see this and has time to have a look at it I would be grateful.

jcromartie• 15 years ago

Why would respect for the MRI devs stop you from publishing benchmarks? It's not an insult to say that something else is faster. I'd imagine the competition might drive them to improve if at all possible.

beginner0014• 15 years ago

a) There will be problems in the Computer Language Benchmark. Like with the excellent LuaJit, they only allow one version of a language, so a war of implementations to appear would not be surprising.

b) Now that Python is in a difficult transition to Python 3, a strong ruby is a game changing point. Antonio Cangiano `New Relic Holy Shmoly, Ruby 1.9 smokes Python away!` could be Jruby smokes Python away :) (if there is a two-fold increase in speed I expect A. Cangiano article rewrited)

c) What about duby and groovye?

headius22• 15 years ago

Duby has become Mirah, and though I have not personally had a lot of time to work on it, it has continued slowly forward. It is basically just Ruby syntax for writing Java, though, so it performs identically to Java.

I don't know the status of Groovy performance in general. I do know that on small numeric benchmarks, JRuby + invokedynamic beats fully-dynamic Groovy, but you can "cheat" and static-type some numeric logic in Groovy, which puts it out in front again.

headius22• 15 years ago

Oh, and regarding JRuby versus Python 3...yes, if Ruby 1.9 smokes Python, and JRuby is faster than Ruby 1.9, then JRuby should smoke Python even more. I have not done the comparisons myself, though.

vorg2• 15 years ago

b) Also Jython is virtually dormant, at some older version of Python, while both JRuby and IronRuby are actively worked on.

c) Groovy hasn't added any support for invokedynamic or even started on it. A month ago they announced they're removing their meta-object protocol rework from the upcoming version 2.0.

SpringSource seem to be repositioning Groovy as a staticly-typed language, this year adding primitive types like in Java. Before everything was an object, and primitives were regarded as leaky abstractions. 2 months ago they employed someone to write a static type checker called "Grumpy" for Groovy, and eventually type inference and optimization, but the work's just started so it might take quite some time depending on how good their new hire is. This year they also tried to rewrite the Antlr 2.7 based parser in Antlr 3.2, using a Google Summer of Code worker, but they didn't get very far. Perhaps the static type checking for Groovy will be more successful, perhaps not.

I imagine this repositioning was instigated by the Grails team wanting a faster language, with dynamicity an optional extra to be used only when required.

sciurus3• 15 years ago

I wonder how long until the JRuby vs PyPy "benchmarks" start appearing.

igouy4• 15 years ago

> There will be problems in the Computer Language Benchmark.

???

http://shootout.alioth.debian.org/u32/jruby.php

> Ruby 1.9 smokes Python away!

"I ran a recursive Fibonacci function..." Really.

kennystone2• 15 years ago

"Compared to JRuby on Java 6, JRuby on Java 7 without invokedynamic is around 25% faster, and JRuby with invokedynamic is nearly 3 times faster."

JRuby already is as fast or faster than MRI, and a 3X increase in performance is absolutely huge.

beginner0014• 15 years ago

On my computer Linux 3.0.0-15-generic #24-Ubuntu SMP Mon Dec 12 15:23:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux RAM=6G "Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz"

A simple comparison using binary-tree (from computer language benchmark) between ruby1.9.1 and jruby show that on my machine jruby time is half of 1.9.1

~/lang/ruby/jruby-1.6.5/bin$ time ./jruby --server -J-Xmx2000m algo.rb 18 gives real 0m32.447s user 0m38.478s sys 0m0.904s

time ruby1.9.1 algo.rb 18 real 1m11.388s user 1m11.192s sys 0m0.148s

./jruby --server -J-Xmx2000m -v jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (OpenJDK 64-Bit Server VM 1.7.0_147-icedtea) [linux-amd64-java]

the algo.rb file is the version contributed by # contributed by Jesse Millikan # Modified by Wesley Moxam and Michael Klaus

this is n=18, for n=16,17 ... results are similar. Half the computing time.

beginner0014• 15 years ago

I just update to java7 in ubuntu 11.04 then using

sudo update-java-alternatives

there is an error: no alternatives for -javaplugin.so

headius22• 15 years ago

Your updated Java 7 is probably a 64-bit version. There's currently no Java applet browser plugin for 64-bit (and I'm not sure if there's plans to create one). If you don't mind missing out on Java applets, you'll be fine.

beginner0014• 15 years ago

A silly question: Can I call jruby or jirb with something like classpath?

I don't want to lose my java applet for firefox,(ubuntu 11.04 64 bits,four-cores).

I would also like to see some comparison, for example like in the computer benchmark game between jruby and other ruby implementations.

What about clojure and scala? will they get a speed up with the new java 7 update? , Will it be three-fold like jruby (in certain cases?). Thanks for the great work on jruby. Being more dynamic is great!

sciurus3• 15 years ago

Is this the case for Java 7? It's not the case for Java 6. There is one from Oracle, which I'm using.

  $ file .mozilla/plugins/libnpjp2.so 
  .mozilla/plugins/libnpjp2.so: symbolic link to
  `/usr/local/lib/jvm/jre1.6.0_29/lib/amd64/libnpjp2.so'

There's one from OpenJDK as well.

  $ apt-cache show icedtea-plugin
  Package: icedtea-plugin
  Source: icedtea-web
  Version: 1.1.4-1
  Installed-Size: 276
  Maintainer: OpenJDK Team <openjdk@lists.launchpad.net>
  Architecture: amd64

rmoriz4• 15 years ago

try:

  $ update-java-alternatives --jre-headless

  $ update-java-alternatives --jre

this will not update the plugin-alternative which is not available (yet), see headius' comment

  => https://gist.github.com/1501186

(UPD: sorry, the following only applies to the standard OpenJDK7 on Ubuntu, not the u2 release )

also on i386 and armel see https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/850...

workaround (change armel/arm to i386 if that's your arch):

  $ cd /usr/lib/jvm/java-7-openjdk-armel/jre/lib/arm/

  $ sudo ln -s jamvm/libjvm.so .

headius22• 15 years ago

That applies to ARM. I'm not sure of the equivalent workaround for x86_64 outside of installing a 32-bit Java 7 and setting that up as the source of the Java plugin.

rmoriz4• 15 years ago

FYI: If you want to use JRuby 1.7.0-dev (snapshot) with rbenv/ruby-build see https://github.com/sstephenson/ruby-build/issues/105

richardburton• 15 years ago

I have not got round to playing with JRuby but if you can squeeze 10-30% extra performance then I am keen!

donw2• 15 years ago

I'm a big fan of JRuby for two notable reasons. First, JRuby runs on the JVM, which is arguably the most mature and tested VM on the market today; second, you can leverage both the Ruby and Java ecosystems without any additional overhead (the Java interop is almost seamless).

Being able to write classes in Java (or Mirah) where speed is crucial, and use them from within JRuby without having to do any additional work, is a nice bonus as well.

The only downside is startup time, but that's been improving a lot recently.

vorg2• 15 years ago

I believe Rails can also run on the JVM via JRuby. I wonder what the benchmark is between Rails/JVM and Grails 2.0 ???

chrisdone• 15 years ago

10-30% faster is “massive”? Ruby standard is 5-30 times slower than all other popular language implementations, I'd expect at least a 100% increase to be considered “massive.” I'd call this just “a speed boost.” Anyway, keep it up.

donw2• 15 years ago

A quick look at the programming language shootout (http://shootout.alioth.debian.org/) puts Ruby in roughly the same performance league as Python and Perl, and you'd be hard-put to argue that these aren't popular languages.

pdhborges• 15 years ago

You must have missed this part:

"Compared to JRuby on Java 6, JRuby on Java 7 without invokedynamic is around 25% faster, and JRuby with invokedynamic is nearly 3 times faster."

lobo_tuerto2• 15 years ago

Three times faster == 300% speed increase. In your terms that would mean a _really_ massive upgrade.

thm76• 15 years ago

No, it's a 200% speed increase. If the speed before was 1 unit, it's now 3 units. That's 200% more.

sigzero4• 15 years ago

The only pain for me? The JRuby binaries are on Amazon S3 and my "expletive" company blocks Amazon S3.

headius22• 15 years ago

That is truly bizarre.

There's probably mirrors of the JRuby downloads somewhere, eh? I don't know them offhand...

sigzero4• 15 years ago

I tried to find one but I ended up "cheating". If you try and send from a gmail account it will fail but gmail will keep the file on its servers. So I can log into gmail at work, and download the binary from the failed sent message. sigh

toisanji• 15 years ago

how does eventmachine run on jruby and does anyone actually use jruby and eventmachine in production?

headius22• 15 years ago

EM does work, but it's not commonly used on JRuby. I think the fact that JRuby has real parallel-executing threads makes eventing frameworks like EM less interesting...especially since EM only runs a single event loop.

I'd love to hear about people actually using EM on JRuby, if there's such folks out there.

kreek• 15 years ago

Slightly off topic but does anyone know if Java 7 would allow fork to work in JRuby?

_m4• 15 years ago

I understand that most of the performance boost comes from the the invokedynamic optimization, not from anything special inside JRuby.

So, does this mean we can expect the same goodness for other dynamic JVM languages? Clojure maybe?

riffraff• 15 years ago

there is the need for the implementation to actually make use of invokedynamic, otherwise there would be no gains. As for clojure: http://news.ycombinator.com/item?id=2928285

moe3• 15 years ago

I've been eyeing jruby for quite a while but never had much success with it. There seems to always be the odd gem not supporting it (e.g. jruby-openssl is broken which a lot of my stuff depends on).

kennystone2• 15 years ago

Invoke dynamic means less of a need for C-Extensions, which is probably one of the largest sources of pain for JRuby compatibility. The JVM is better at running plain old ruby code now, so there's less need to go outside of it with C or Java.

tedunangst• 15 years ago

Well, you don't need extensions, but lots of library interfaces still use them because they haven't been updated to FFI. So sometimes you can't use the code you want. The good news is that it's usually pretty painless to whip up your own FFI binding.

headius22• 15 years ago

That's definitely our hope. JRuby has come further than any implementation in making Ruby fast enough to replace C or Java, and if it's possible to write more in Ruby then all implementations will benefit. C extensions are the number one thing holding the C/++ implementations back.

bascule• 15 years ago

jruby-openssl has worked fine for me for several years. Making outgoing SSL connections was one of the primary functions of the last app I worked on.

moe3• 15 years ago

It could indeed be that my jruby endeavors just happened at unfortunate times. The jruby-openssl bug that I'm currently seeing is a different one from last time - and it's apparently fixed in git-HEAD already, just not in the gems yet.

So I'm looking forward to the 0.7.5-release and with a bit of luck I might finally be able to jump on the jruby-bandwagon then.

headius22• 15 years ago

OpenSSL is a terribly complex library to support, but we've managed to steadily improve our pure-Java port (originally a herculean effort by Ola Bini, it wraps bouncycastle in an OpenSSL-lookalike API). There's still probably issues, but we have tried to fix them as they come up.

moe3• 15 years ago

Yes, that was no criticism, I'm hoping jruby will succeed.

Fwiw, I'm currently blocked on http://jira.codehaus.org/browse/JRUBY-6260

Apparently the fix is already done but hasn't made it into the 0.7.5dev gem yet.

jshen2• 15 years ago

maybe I'm a weirdo, but I care a lot more about memory consumption than processing performance. Starting up irb with jruby-head and java 7u2 uses around 80MB. 80MB for vanilla irb!

MRI uses around 8MB

Edit: I get down voted for saying that I care about memory consumption? My use case may not be everyones, but it's a legitimate issue is it not?

headius22• 15 years ago

Memory is cheap?

JRuby largely uses more memory because we have a "real" garbage collector. The JVM, unlike MRI, allocates much more memory than the app needs. That gives it freedom to delay GC runs and push old objects into rarely-GCed sections of memory. It does also mean JRuby uses more memory on startup.

JRuby also has the JVM's subsystems booted and considerably more complex caching and optimization logic. This does increase the base size of a JRuby runtime.

It's possible to get JRuby to start in under 30MB if you explicitly force the JVM to use less memory with -J-Xmx30M or lower. But is it that big a deal? Let the JVM breathe, and your code runs better as a result.

jshen2• 15 years ago

First, I'd like to say that I use JRuby a lot, and you guys have done an amazing job on it. I complain because I like JRuby, and wish I could use it more :)

I did set the Xmx and it still uses around 80MB. I'm not sure what in the world the JVM is doing there, but the permgen is another 20MB or so and then other native stuff, thread overhead, etc.

Is memory cheap? Yes and no. At work we have a rails site with two REST api backends both ruby. I also love RubyMine. Now here's my problem, I can't run all of those on the JVM on my macbook air. 4 gigs is not enough if I also have a browser open!

This is not a problem at all if I switch the apps to MRI and switch my editor to a non JVM based editor. I think the JVM people need to recognize this problem.

tlogan• 15 years ago

It is also important to mention that java7 G1 garbage collector gives much better results for certain installations (of course test it before deploying it on production). The pauses are much more predictable and, in my case, much shorter.

Here is how to get Oracle Java7 on Ubuntu:

  wget http://download.oracle.com/otn-pub/java/jdk/7/jdk-7-linux-x64.tar.gz
  tar -xvf jdk-7-linux-x64.tar.gz 
  sudo mkdir -p /usr/lib/jvm/      
  sudo mv jdk1.7.0/ /usr/lib/jvm/
  sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.7.0/jre/bin/java 0
  sudo update-alternatives --config java

headius22• 15 years ago

G1 is definitely an interesting piece of work. It's geared toward very large heaps where you need more predictable pause times, and is intended to replace the concurrent mark/sweep GC.

To enable G1 on Java 7: -XX:+UseG1GC. Prepend -J if passing to the 'jruby' command.

Massive Ruby speed boost with JRuby and Java 7.

Related Stories