IronRuby 0.9: Performance and interop with IronPython

I'm a few weeks behind the curve on this one, but I'm finally catching up with my backlog; IronRuby 0.9 has been released. It looks like they didn't make the version 1.0 by OSCON but they have made a lot of progress.

• IronRuby 0.9 Released

Jimmy Schementi lets us know the highlights of the new release:

Library performance was a big focus for this release; basically going though the Ruby Benchmark suite and making sure any obvious slowness was fixed. As I said in my previous post about OSCON, IronRuby is approximately 2x faster than MRI when running the benchmark suite, but in the near future a complete evaluation of IronRuby’s performance will be done and published on the website.

Antonio Cangiano has already published benchmark results between IronRuby 0.9 and Ruby 1.8.6, and things look really good for IronRuby.

On the compatibility front, the Win32OLE Ruby library is now available in IronRuby. This builds on top of IronRuby’s existing COM interop from version 0.5, letting you script any Windows component/application that exposes a COM interface. Though it hasn’t been fully tested yet, this will make things like Watir work on IronRuby.

Lastly, there have been interop improvements with .NET, most notably making Generic types more friendly to all the crazy things Ruby can do to them, and also with other DLR languages, making it really easy to call IronPython from IronRuby.

Two points particularly worth noting - Antonio Cangiano has posted benchmarks of IronRuby on Windows showing that IronRuby is faster than Ruby 1.9.1 and substantially faster than Ruby 1.8.6. Part of the reason for this could be down to how much worse Ruby performs on Windows than on Linux (which in turn may be down to the old version of gcc it is compiled with on Windows through Mingw - something that is due to change). That aside it is still an impressive result for IronRuby.

The second important point is that IronRuby has matured a lot, to the point where IronPython and IronRuby can now interoperate happily through the Dynamic Language Runtime. Although often portrayed as mortal enemies these languages are really siblings (and which siblings don't argue?) - so a platform on which Python can use Ruby libraries, and vice versa, is very interesting. This has been the vision of the Common Language Runtime for a long time and is a vision shared by the Parrot Virtual Machine, but not yet become a reality.

Because IronPython and IronRuby are both moving targets (developing very fast) it can be hard to try the interoperation in practise, because you need to find a build of both languages that share a common build of the Dynamic Language Runtime. Fortunately the IronRuby binaries for download on Codeplex include compatible IronPython binaries (a build of IronPython 2.6 beta 2) for interop (as a separate download):

• IronRuby 0.9 and IronPython interop binaries

Here's a basic example of executing Ruby code from IronPython:

IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReference('IronRuby')
>>> from IronRuby import Ruby
>>>
>>> engine = Ruby.CreateEngine()
>>> source = engine.CreateScriptSourceFromString("puts 'Hello from Ruby'")
>>>
>>> source.Execute()
Hello from Ruby
>>>

Here's a slightly longer example that uses IronRuby to load the Ruby date library and then pulls out the Date class and instantiates it from Python!

import clr
clr.AddReference('IronRuby')

from System import Array

paths = [r'C:\Binaries\IronRuby\lib\IronRuby', r'C:\Binaries\IronRuby\lib\ruby\1.8']
array = Array[str](paths)

source_code = "require 'date'"

from IronRuby import Ruby
engine = Ruby.CreateEngine()
engine.SetSearchPaths(array)
source = engine.CreateScriptSourceFromString(source_code)
source.Execute()

RubyDate = engine.Runtime.Globals.Date

date = RubyDate(2009, 9, 22)
print date.year()