Rubinius roundup

Posted by Werner Schuster on Sep 25, 2007 12:01 AM

Community

Ruby

Topics

Performance & Scalability,

Dynamic Languages

Tags

JRuby,

Rubinius

Rubinius is a Ruby VM implemented mostly in Ruby, with a bit of C thrown in for the low level bits - although these parts are supposed to be rewritten in Ruby too. (For details see InfoQ's interview with Evan Phoenix on Rubinius). In the past year,

Rubinius has gathered a lot of interest and gained a group of developers, dutifully chipping away at the list of unimplemented features and incompatibilities. Ola Bini, of the JRuby team, just posted his thoughts on Rubinius in a post titled Rubinius is important:

In fact, I'm getting more and more convinced that for the people that don't need the things Java infrastructure can give you, Rubinius is the most important project around, in Ruby-land. More than that, Rubinius is MRI done right. If nothing substantial changes in the current timeline and plans for Ruby 1.9.1, I predict that Rubinius will be the CRuby implementation of choice within 6 months.

He follows with a list of arguments supporting this opinion:

• It is byte code based. This means it's easier to handle performance.
• It has a pluggable, very clean architecture, meaning that for example garbage collection/object memory can be switched out to use another algorithm.
• It is designed to be thread safe (though this is not really true yet), and Multi-VM capable.
  
• It works with existing MRI extensions.
• Most of the code is written in Ruby.
• It gives you access to all the innards, directly from your Ruby code (stuff like MethodContexts/BlockContexts, etc).
• The project uses Valgrind to ensure that the C code written is bullet proof.

Another aspect that has been improving is performance. Evan Phoenix recently published the results of some benchmarks comparing Rubinius with Ruby 1.8.x (called MRI for "Matz' Ruby Interpreter"). The results show Rubinius in the lead for many tests. Here Evan Phoenix' analysis:

There are a few trends in the data I’d like to point out.

• Of tests that did not error or timeout, rubinius was faster in 24 of 31. Wow first off, thats a huge improvement over the previous run.
• The slowest section for bm_so. Rubinius was only faster in 2 of 11, and actually error or timeout on 4. If you look at those benchmarks, you’ll see that they are basically tests of a few core methods, mainly things like String#<<. So it makes sense that at this stage, we’re slower on those. We haven’t yet tuned those at all.
• One big trend is that tests that only stressed the VM architecture came out WAY faster. 2 examples are bm_vm1_swap and bm_vm1_simplereturn. The first swaps two local variables using a, b = b, a a few million times. This is a good example where the bytecode VM is much faster than the tree walker in MRI. Next, bm_vm1_simplereturn shows off rubinius’s ability to create a method context quickly and return to the sender quickly. I’m thrilled about this number because even though rubinius MethodContext’s are first class, they’re still 3 times faster with no programming power loss.

It's important to point out that Rubinius is using bytecode interpretation. Optimizations such as Just In Time (JIT) compilation, turning bytecodes into native code at runtime, or others are still in the future, so more performance improvements are still to come. Other optimizations, such as advanced or configurable Garbage Collection strategies can help performance even more.

Rubinius is backed in various forms. Evan Phoenix was hired by EngineYard to work on Rubinius half time. Recently, Sun sponsored travel costs for Rubinius developers Wilson Bilkovichand Brian Ford, and sent along JRuby's Charles Nutter to the Rubinius sprint. It must have been a productive meeting, judging by the list of improvements:

• Evan hooked up Syck (the YAML parser) using our very cool subtend (Ruby C API compatibility) component.
• Wilson hammered out a bunch of StringIO specs in a couple hours.
• Evan promptly began writing a Ruby StringIO that passed the specs.
• Charles whipped out a bunch of def and case specs, the latter being a serious beast to compile.
• Wilson added these wicked colorized backtraces that enable you to quickly pick out the ultimate failure line and some significant points in the backtrace.
• Wilson implemented the rest of the missing case support in the compiler.
• Charles added some basic ObjectSpace support.
• I checked in a complete reorganization and a lot of fixes to our Ruby core library specs. We have around 2,800 specs, of which we’re passing over two thirds. We still have nearly 50% of the core library specs to complete.
• Evan fixed our Thread support and added some preemption.
• I added (with much help from Evan and some serious gdb sessions looking at x86 machine code) some coolness to our foreign function interface (FFI) to support reading and writing to C integers and doubles from Ruby. (The doubles support still needs a magic touch or two from Evan.) With that I was able to finish off our Math methods support and the rest of the Math specs.
• Wilson hammered out a ton of the machinery necessary to support compiling eval. If you don’t realize how awesome (and painful) this is, don’t blame me.
• I started on an implementation of File.fnmatch in preparation for Dir.glob(or dear glob is it is not-so-affectionately known to me) and cleaned up our fnmatch specs a bunch.

Rubinius also seems to play a role in Gemstone's Object Oriented Database (OODB) for Ruby plans, as mentioned in a recent interview on JRuby and Rubinius support for Gemstone.

• Older >