MagLev, Ruby VM on Gemstone OODB, Wows RailsConf

murphee ends along a report from InfoQ: "Gemstone demoed [MagLev,] their Ruby VM built on their GemStone S64 VM, to an ecstatic audience. Gemstone's Smalltalk VM allows OODBs of up to 17 PetaBytes, with none of the old ActiveRecord nonsense: the data is persisted transparently. The Gemstone OODB also takes care of any distribution, allowing the Ruby VM and data to scale across many servers (Cheerio, memcached!). There's also an earlier quite technical interview with Gemstone's Bob Walker and Avi Bryant about MagLev."

Comments

Ruby Shootout

[cryptoluddite]

The MagLev VM, although only partially implemented, so far outperforms MRI 1.8. Being 'faster than 1.8' is a pretty weak claim compared to the competition:

Ruby 1.9: 3.32x
XRuby: 1.43x
JRuby: 1.32x
Ruby 1.8: 1.0x
Rubinius: 0.73x
Ruby.NET: 0.56x

What is cool is how well the Java-based Ruby implementations do: JRuby and XRuby. JRuby was the only Ruby implementation that did not have any tests error. For a VM that is supposedly so hostile to dynamic languages, those implementations were faster and more reliable than the actual Ruby VM and cleaned the floor with the CLR/.NET implementation. And the next version of Java should have stack allocations and invokedynamic bytecode and other optimizations.

What this shows to me is, first do one thing well (Java), then figure out how to grow it. In contrast to .NET/CLR which started out trying to do everything and ended up doing few things well.

Re:Ruby Shootout

[cryptoluddite]

I took a look at some more of the benchmarks and they are pretty much universally meaningless once you throw in a good optimizing VM. For instance translating the method benchmark into Java and having it loop 2^31 times instead of 6 million times and Java is 29,000 times faster than Ruby 2.8.

Adding a simple global+=1 to the method body makes Java only 16,000 times faster than Ruby 2.8.

Replacing the +1 with global*=5 makes the Java version only 536 times faster than Ruby 2.8.

These are the kinds of optimizations MagLev is doing, and they don't translate into anywhere near the gains in actual code. So you see, you really need to rethink your tests. Even for something seemingly ok like modifying a global can depend on how it is modified and what the VM can optimize (+1 vs *5). Frankly I would just test these different Ruby implementations using the regular shootout code, since these have been designed not to be optimized out.