Ruby and V8

Summer is drawing to a close and many of the things which have distracted me from my blog are becoming less pressing, so it's about time for me to crank this back up — we'll have to see how well I keep up with it. Of course, there are a lot of exciting things on the horizon that are prompting me to write. One of the biggest is the release of V8, the JavaScript VM that's part of Google's Chrome. Over on the Strongtalk list, David Griswold wrote:

I still think it or some derivative will quickly become the dominant dynamic language VM, for the following reasons:

• Given who the developers are, and with Google behind it, it will be the fastest JavaScript VM for a long time to come.
• For the same reason, it will be reliable and secure (as much as it can be, anyway; nothing is perfect).
• It will be supported on the three major platforms (Windows, Linux, Mac).
• It can be used with other browsers, so I'm sure it will be ported to Firefox (if only as an option). Some or all of the other browsers may also adopt it, given that it will have a very hard-to-overcome performance advantage (these sorts of VMs can't be pulled out of a hat). Although MS and maybe Safari may have too much of a Not Invented Here problem with it, as well as standards war issues.
• those things, plus the other architectural advantages it brings, will make it a primary target for serious web app development, esp. Google apps.
• So it will be ubiquitous

So it will be an irresistible platform for other dynamic languages, even if they could theoretically run a bit faster on a custom VM. Remember it will still be a lot easier to run other dynamic languages on JavaScript than it is to run them on Java, since at least JavaScript is fully dynamic, unlike Java.

I'm not the language guru that David is, but I not ready agree with him yet. While JRuby is showing good progress at creating a fast, stable Ruby implementation on top of a non-native VM, I don't think we've seen what a native, tuned VM for Ruby can really do. I'm also not sure we'll ever see Ruby's community turn away from their own VM (be it Rubinius or the 1.9 VM) for the 'standard implementation'. This doesn't mean that V8 is without value to the Ruby community though. Again, David Griswold:

The V8 development team has multiple members of the original Animorphic team; it is headed by Lars Bak, who was the technical lead for both Strongtalk and the HotSpot Java VM (as well as a huge contributor to the original Self VM). I think that you will find that V8 has a lot of the creamy goodness of the Strongtalk and Self VMs, with many big architectural improvements:

• open source
• will run (eventually) on Windows, Linux, and Mac
• dynamically JITs to native code
• can run completely independently from the browser
• generates hidden classes behind the scenes, since javascript doesn't have them (very reminiscent of the 'maps' used in the Self VM).
• is multi-threaded from the ground up, with the ability to share VM overhead between different OS processes.
• has even smaller object headers than in Strongtalk, making small object overhead even smaller
• kick-ass compacting, non-conservative garbage collector

Whether Ruby ends up on V8 or not, I'm guessing that some of V8 will end up in Ruby.

Some Real World Performance notes on Ruby 1.8 and 1.9

Update:

The performance numbers for Ruby 1.8.5 (below) are incorrect due to a mistake on my part. For updated in formation, please see my newer performance post.

p>One of the knocks against Antonio's Ruby Performance Shootout is that it uses a synthetic set of tests (the one's Ko1 wrote to exercise the parts of YARV he'd already done some optimization on). In an effort to get a 'more real' set of numbers (at least for me), I decided to use my LogWatchR tool to do some benchmarking.

LogWatchR is a program to watch syslog (we aggregate several hundred boxes' syslog entries to a pair of servers at my $JOB). I wrote it to use catalogs of good and bad entries (with dependencies, number of occurence thresholds, etc.) written in YAML and stored in external files, so that even a Junior Sys Admin could add new catalog entries pretty easily. To keep myself honest, I have a 20 minute sample of log entries and a simple pair of catalogs I use:

• 73607 log entries in the sample
• 1 entry in the good patterns catalog
• 5 entries in the bad patterns catalog

I can use this to make sure LogWatchR is performant, and works as expected.

In order to time LogWatchR, I ran the 20 minute sample through the program 5 times on each implementation of Ruby. Here are the results I got:

version	running time (in seconds)
ruby 1.8.5 (2006-12-25 patchlevel 12)	34.829 +/- .287
ruby 1.9.0 (2007-04-18 patchlevel 0)	12.967 +/- .095

At this point, all I can say is I'm really impressed with the work that the 1.9 team has done to speed Ruby up. Anytime you can get a better than 2.5x performance boost, you've gotta be doing something right.

JRuby 0.9.8 and rubinius don't work yet. They both have YAML related failures. I've talked with Evan about rubinius, and he says he's hoping that YAML will be working soon. I've also sent in a bug report to Ola, and hope that we'll see a fix in 0.9.9.

I plan on rerunning this benchmark periodically, so hopefully we'll see JRuby and rubinius included in the results soon.

If you enjoyed this article on profiling, you might also want to look at these:

• More Real World Performance Notes
• JRuby 1.0.1 Real World Performance Notes
• JRuby 1.1 Performance Numbers