Friday, September 08, 2006

More thoughts on JRuby

I also got some quick thoughts from Eric Hodel about his take on the JRuby announcement:

How do you think Sun's hiring of Charles Nutter and Thomas Enebo to work on Jruby will affect Ruby as a language?

Eric: I think the most likely change will be the addition of native threading, which is something that some people believe ruby has "needed" for a long time. I imagine it would also be possible to run ruby as an embedded language alongside Java.

I don't believe it would have much of an influence on the language or standard library, though.

The Ruby community?

Eric: Rails brought an explosion of interest in ruby and brought a bunch of fresh ideas. I don't think all of them were healthy ideas, but many of the language features were re-examined with fresh eyes and lots of neat stuff came out of it.

I imagine a bunch of Java developers joining the language will have a similar impact, but the community may have to educate them as well.

Your implementation of metaruby?

Eric: I'm not sure, not much of their code has utility to us, and our code could be useful to them if it was a few more years advanced at the current pace of development, especially on the Ruby2C side. I suspect we will continue to be separate for some time.

What a Little Bird Told Me About JRuby

Shortly after I read the news about Sun hiring Charles and Thomas to work on JRuby, I talked to Kevin Tew (the developer of the recently revived Cardinal project) about it. Here are some of his thoughts:

How do you think Sun's hiring of Charles Nutter and Thomas Enebo to work on Jruby will affect Ruby as a language?

Kevin: I think it's wonderful. It will greatly accelerate JRuby's stability and execution speed.

Having people working full time on Ruby besides Matz should help eliminate the rough edges and little inconsistencies of Ruby.

I would like to see stable support for tail recursion and continuations in Ruby and JRuby. I hope the JVM can continue to evolve to meet the needs of dynamic languages and not stifle the innovation of dynamic features.

How will it affect the Ruby community?

Kevin: The greater exposure of Ruby in the Java community can have nothing but positive effects for the Ruby community.

I'm a big believer of the positive influences that diversity and new blood can have on a project. I think each new implementation of Ruby is an added benefit to the community as a whole. I'm excited to see what new ideas will come from JRuby, given Charles and Thomas's new elevated status.

How will it affect your implementation of Cardinal?

It's always nice to have more than one example to look at when writing a new implementation of a programming language.

Building Cardinal on top of Parrot is much more similar to JRuby on top of the JVM than Matz's Ruby written in C. Having JRuby as a model will help speed up Cardinal development.

Hopefully a little of the attention JRuby is receiving can rub off on Cardinal.

Any other thoughts?

Kevin: I'm looking forward to meeting and working with Charles Nutter and Thomas Enebo.

JRuby and Sun

Sometimes, news happens when you're not there (even if you have a bit of forewarning. I spent yesterday up in the Wasatch Mountains doing maintenance work on a Camp for disabled youth as a part of the Salt Lake City United Way "Day of Caring" (2,600 volunteers from 96 companies worked on 110 projects — it was a great way to spend the day). The only down side was that I missed the news that Sun has hired Charles Nutter and Thomas Enebo to work on JRuby full time (and flood of responses that engendered).

This is great news, and should spark a lot of activity in the Ruby world. Some of the things that I'm looking forward to include:

  • More work on a formal specification for Ruby.
  • More work on a common test suite for the Ruby interpreter, core libraries, and standard library.
  • Increased visibility for Ruby as a whole.
  • Some JRuby books (as a language hobbyist, I'd love to read "The Design and Implementation of JRuby"

I'm sure there will be some doom-sayers, and probably some rocky times ahead as the JRuby project and the C implementation of Ruby figure out their relationship, I'm confident though, that these will be mere bumps on the road to a bigger, more vibrant Ruby community and a faster, better tested set of Ruby implementations.

In case you missed it, I interviewed Charles and Thomas a while before this chage. You can read the interview here, with a couple of outtakes here and here.

Wednesday, September 06, 2006

YARV Update (after my bus ride home)

I figured out what was wrong with the factorial test of YARV in my last post. I was only running 1,000 iterations of the factorial method. If I bump it up to 10,000,000 iterations, I get much better results:


$ time ruby fact.rb > /dev/null
real    2m42.446s
user    2m12.000s
sys     0m0.336s
$ time ruby-yarv fact.rb > /dev/null
real    1m19.009s
user    1m12.217s
sys     0m0.148s

This time around I get a 2x improvement. much closer to what I was looking for. 1,000 iterations wasn't enough to offset the startup and compilation time. I wonder what kind of times I'd see if I could dump the compiled byte-code?

Getting Started With YARV

I built YARV yesterday so that I could start playing with it. Building and installing it was easy, I just followed the directions on its home page. Testing also went pretty well (except for my last test) — the results were a bit more varied than I'd thought they'd be though. Here's what I saw.

I started out with my hokey little prime finder that I use as an example everywhere else. Here's the code


for num in 1..100_000 do
  is_prime = 1
  for x in 2..(num - 1) do
    if (num % x == 0)
      is_prime = x
      break
    end
  end
  if is_prime == 1
    puts "#{num} is a prime number"
  else
    puts "#{num} equals #{is_prime} * #{num/is_prime}"
  end
end

And here are the results:

$ time ruby primes.rb < /dev/null
real    3m12.391s
user    3m7.828s
sys     0m0.172s
$ time ~/bin/rubyyarv primes.rb < /dev/null
real    1m10.277s
user    1m7.008s
sys     0m0.084s
About a 3x speed up, pretty good stuff.

Then I whipped out a little recursive factorial function:


def fact(num)
  if num == 1
    num
  else
    num * fact(num - 1)
  end
end

1000.times do
  puts "500! is #{fact(500)}"
end

Which looked like this:

$ time ruby fact.rb > /dev/null
real    0m2.932s
user    0m2.792s
sys     0m0.008s
$ time ~/bin/rubyyarv fact.rb > /dev/null
real    0m2.230s
user    0m2.132s
sys     0m0.008s

Not nearly the speed up I'd thought I'd get. I'll have to profile it and see if I can figure out where the bottleneck is.

Then I decided to try my rwb test suite. Here's what it looked like:


$ ruby -Ilib test/test_rwb.rb
Loaded suite test/test_rwb
Started
....................................................
Finished in 0.024843 seconds.
52 tests, 95 assertions, 0 failures, 0 errors
$ ~/bin/rubyyarv -Ilib test/test_rwb.rb
Loaded suite test/test_rwb
Started
....................................................
Finished in 0.020679 seconds.
52 tests, 95 assertions, 0 failures, 0 errors

About a 20% speed-up here, not bad but not great either.

Finally, I threw the r43 test suite at it. This is where things broke down:


$ ruby -Ilib test/test_r43.rb
Loaded suite test/test_r43
Started
...............................................
...............................................
...........
Finished in 3.956994 seconds.
105 tests, 650 assertions, 0 failures, 0 errors
$ ~/bin/rubyyarv -Ilib test/test_r43b
Loaded suite test/test_r43
Started
....................EEEEEEEEEEEEEEEEEEEEE..EEEEE
................................................
......E
Finished in 0.671329 seconds.
[error messages deleted]
105 tests, 107 assertions, 0 failures, 27 errors

Either my install is broken, or there are other problems. Again, I'll have to take a longer look and see what I see. I'll try to post more about this tomorrow.