Rubinius 1.0 Brings MRI 1.8 Compatibility and Near Speed Parity

Posted by Mirko Stocker on Dec 03, 2009

Sections

Development

Topics

Ruby on Rails ,

Runtimes ,

Ruby

Tags

Virtual Machines ,

LLVM ,

Rubinius ,

RubySpec

Rubinius, the "Ruby for Ruby programmers" is finally nearing its 1.0 release. The 1.0 release focuses on compatibility to run real world applications, performance parity with MRI 1.8, and code quality.

Rubinius lead developer Evan Phoenix told InfoQ why this release is so important and what it contains.

1.0 is really the release we've been working on since Rubinius began. We're aiming for 1.8 compatibility and near speed parity. Our compatibility is already quite high, using RubySpec as the guiding force.

On the speed side, Rubinius is already many times faster than 1.8 on a lot of things. The big push is getting all the ruby code that implements the core class running as fast as the C code that makes up the 1.8 implementations. We're doing really well in this department, but it's quite possible that we'll be slower than 1.8 in some cases on the core classes.

We've already gotten some external reports of some real, in the wild code being a few times faster under Rubinius. Clearly those results won't scale up to all code for 1.0, but it shows that we're really getting close.

Rubinius can use the Low Level Virtual Machine (LLVM) compiler infrastructure to build native code. Note that it is currently not enabled by default in the RC1.

The LLVM work is great. In 1.0-rc1, you have to pass --enable-llvm to configure to have Rubinius built with LLVM. We're likely going to change that for rc2, building LLVM in by default and allowing users to opt-out if they feel they don't want it.

If LLVM is compiled in, the JIT is on by default, automatically compiling methods that are run a lot into machine code. We're getting great output from LLVM, especially using our type profiling work. This allows us to see what methods are commonly called and inline them, increasing performance.

In the early days of Rubinius, the focus was on more completeness, which has led to the RubySpec. Now the scale has shifted in favor of performance, or is it still on completeness?

We're focused on both. In the past, the focus has been mainly on completeness, but over the course of the last year we've focused on performance a lot. The LLVM work is a direct result of this, and it's paying off big time.

As for performance, it's getting great. On micro benchmarks, we're many (if not hundreds) times faster than 1.8. But as we know, micro benchmark results don't scale to real world code. In that, we're seeing results all over the map. Some users report a few times speed, some report similar performance, and there are reports quite a bit slower performance.

We're really focused on those areas of slow performance right now. We've built ourselves a lot of great tools to help isolate and fix performance issues, such as our built in profiler.

In improving performance, we look first at making the ruby code itself better. This can go a long way, improving things algorithmically and fixing inefficient code.

JIT improvements are our other main tool for improving performance. Teach the JIT how to compile ruby code down to machine code more efficiently has big payoffs, and we're always working on this.

Besides the performance and compatibility improvements, Rubinius also advances in other areas, like error reporting of missing closing ends.

And probably the most interesting question: will Rubinius 1.0 run Rails?

Of course! For rc2, we should be running both rails 2.3.5 and rails 3.

1.0-rc2 will be out near the end of December, just in time for people to play around with it over they holidays!

The first release candidate can be downloaded from the Rubinius website. Test your 1.8.6 code now and report any errors you find.

• Older >