Playing with JRuby, Part 1

As part of a new project, I’m experimenting with JRuby, to see (a) if the alleged performance gains are all that and (b) see how far the Java integration – especially interface implementation – can be pushed.

On the performance front, I did a quick-and-dirty test with a CPU-expensive script that finds prime numbers – not a real benchmark, but something to give me an idea of how JRuby held up under a steady load of basic math operations. Details follow.

Disclaimer: I know this is not the optimal algorithm for finding prime numbers. The point here is not to find prime numbers, but to tax my CPU predictably. If you post a comment with the general intent of HEY FINDING PRIMES UR DOIN IT WRONG, I’ll just delete it.

The CPU is an Intel Core Duo in an old Mac Mini. The Ruby and JRuby versions under consideration were:

[~/project/jrubytest/primes]> ruby -v ; jruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]
jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2008-12-17 rev 8388) [i386-java]

The code for the test was:

#!/usr/bin/env ruby
 
limit = (ARGV[0] || 100000).to_i
puts "FINDING first #{limit} PRIMES"
 
t0 = Time.now
primes = [2, 3]
counter = 2 # starting with 2 and 3
 
currnum = primes.last
while counter < limit
  currnum += 2
  primes.each do |p|
    break if (0 == (currnum % p)) and (p <= Math.sqrt(currnum.to_f))
    if p >= Math.sqrt(currnum.to_f)
      primes << currnum
      counter += 1
      break
    end
  end
end
 
puts primes.last
puts "Time: #{Time.now - t0}s"

The results showed just shy of a factor of 2 gain using JRuby (which is consistent with other tests I’ve run since writing this up):

[~/project/jrubytest/primes]> ruby ./primes.rb
FINDING first 100000 PRIMES
1299709
Time: 57.716853s
[~/project/jrubytest/primes]> jruby ./primes.rb
FINDING first 100000 PRIMES
1299709
Time: 33.885273s

These results were gotten after I’d made sure I had plenty of free RAM so I wasn’t I/O bound; the difference you’re seeing is all CPU. Note also that the timers are inside the Ruby code – they don’t account for JVM startup time.

Just for laughs, let’s see what the difference is with JVM overhead taken into account:

[~/project/jrubytest/primes]> date ; ruby ./primes.rb ; date ; jruby ./primes.rb ; date
Sun Feb 15 22:26:36 EST 2009
FINDING first 100000 PRIMES
1299709
Time: 54.065758s
Sun Feb 15 22:27:30 EST 2009
FINDING first 100000 PRIMES
1299709
Time: 34.427694s
Sun Feb 15 22:28:05 EST 2009

So startup overhead is about a second for JRuby. Not too shabby.

Part 2 of this post is going to cover some of the hairier tasks involved in:

  • Subclassing Java classes and implementing Java interfaces.
  • Packaging JRuby code in JARs with Rawr
  • Calling code in those JARs from Java

More to come…

Share
This entry was posted in Programming and tagged , , . Bookmark the permalink.

8 Responses to Playing with JRuby, Part 1

  1. lopex says:

    Nice post, but keep in mind you’re running JRuby in slowest mode out there (client compiler that is). Try running JRuby with –server (turns on hotspot heavily optimizing compiler). Also, JRuby trunk should be faster than JRuby 1.1.6

  2. brad says:

    Thanks for the tip – I’m still kind of a JRuby noob (despite being new to neither Java or Ruby).

    I’ll give that a try and re-run my test – if the results are startlingly different, I’ll post about it here.

  3. Thomas Enebo says:

    In addition to lopex’s comment….

    For testing JRuby also be sure to specify the version of the JVM you are using. Using latest release (Java 6) generally gives best performance (and is recommended). Just providing that info gives us a better understanding of your benchmarking efforts.

    We are also developing a tip page for benchmarking JRuby here (still under development):

    http://wiki.jruby.org/wiki/Benchmarks

  4. brad says:

    Of course, I should have included that information. The figures above were generated using Java 1.5.0 on Leopard. Can’t do Java 6 on my current home dev box. I’ll be upgrading soon, though.

    Again, thanks for the tips.

  5. Brad: A few of us have been in the same boat as you…32-bit Intel Mac I suppose? Search for “soylatte”, it’s a Java 6 compiled for Mac. It doesn’t have all the GUI goodies that the built-in JDK does, but it is much faster.

  6. brad says:

    Can I just say: JRuby community = awesome! You guys are really smoothing my transition into fluency with this tool.

    Charles – yeah, 32-bit Mac. I’ve seen soylatte around, but at the time I was fatigued after half-successfully trying to set up other Java installs. I’ll have another look at it – it’d be a real boost for me, as I’d like to move up to Hadoop 0.19 ASAP.

  7. Thomas Enebo says:

    Since we are bombarding you with help here is one more nice utility to help with Java versions:

    http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5

    If you scroll to the bottom of this document it has a nice alias ‘pickjdk’ for switching between versions of Java. Makes it dead simple to switch between versions.

  8. Pingback: Kickass Labs » Blog Archive » Playing with JRuby, Part 1A

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">