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."

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:Talk really did wow the conference

[Standard User 79]

Doubtful. When people have scalability problems it's not ruby, it's rails. Web applications don't need much cpu but they do need to use memory in a reasonably efficient manner - something that rails cannot currently do.

OODB, oh oh

[Tablizer]

I thought the OODBMS fad was finally dead. OODB's resurrect many of the problematic ideas that drove Dr. Codd to formulate relational to begin with. Thus, they could be considered a step backwards. But this would start a paradigm Holy War here and we don't want that, do we?

Re:Sounds cool, but not open

[WeirdJohn]

JP Morgan uses Gemstone/S behind it's financial systems. I'd say that's a fairly major user. As I understand it MagLev is basically the Gemstone/S Smalltalk VM extended to understand Ruby bytecodes. They (Gemstone) state that the same VM can run Smalltalk, indeed Ruby will be able to talk to Smalltalk objects transparently. The only real questions are how much more complex does Ruby make the VM (Smalltalk VMs are absurdly simple), and what does this complexity do to stability (Smalltalk VMs typically stand up to enormous abuse)? Given the scalability of Gemstone, I don't see MagLev being absurdly scalable as being much of a surprise.

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 [debian.org] code, since these have been designed not to be optimized out.

Re:OODB, oh oh

[Ed Avis]

A relational database system usually allows you to write stored procedures to do the data manipulation entirely in the server without roundtrips. That's not the issue. What matters is your second point 'forcing you to express the idea with relational operators only'. Sometimes relational operators are a good fit for the data model and, if you twist your neurons in the right way to think of the problem relationally, allow you a much higher-level way to express an algorithm than procedural code, while keeping good efficiency. But there are many cases where the relational model doesn't seem to fit.

The question is, what powerful primitives does an OODBMS offer you? What efficiency advantages do they have over naive 'fetch record; do something; fetch another record' procedural code for dealing with large amounts of data? How can they take advantage of indexing or optimize cache usage to reduce disk seeks?

Re:I'm sorry...

[pnagel]

How do you update the application code?

By filing in the source code, or whatever mechanism your Smalltalk source control tool of choice provides.

Don't know the specifics of what they do in Maglev for ruby.

Won't you still need to manually write a converter for the data from one format to another?

Of course. If, for example, you decide to store birthdates for your customer objects too, you'd need to write a "for" loop that loops over all your customer objects and assigns an initial value to their birthdate attribute.

Because the runtime of an OODB program is measured in years, not hours, the layout of its objects tends to change a lot. And the libraries and runtimes tend to support this, whereas in plain old programs it is not supported.

In GemStone/S, they support this amongs other things by allowing you to have "previous versions" of a Person class. So, to add birthdate to a Person, you'd load a new version of the Person class, loop over all instances of the previous version, frob their data, and continue running.

But the frobbing code would be plain old Smalltalk (or Ruby, in the case of Maglev; or Java, in the case of GemStone/J) code.

And how is this better than just up front writing your persistence like we've always been doing?

It's better because the object model of persistent data is identical to the object model of plain old data as you've used it in non-persistent code.

Look, here's pseudocode for a non-persisten Person object constructor (I'l spare you the Smalltalk syntax):


createPerson(aName, aSurname)
    name := aName
    surname := aSurname


Here's pseudocode for the equivalent code inside a persistent OODB:


createPerson(aName, aSurname)
    name := aName
    surname := aSurname
    commit()


Compare this to using a relational database in as a backing store for objects intended to be used in an OO program.

1. You need declare the SQL schema of the table that will store your Person
    
2. You need to duplicate the same in your language
    
3. You need to write special code to extract the original values from the table into your Person object
    
4. You need to do the same for persisting changed values back
   

Re:news that matters?

[nguy]

That's changing.

Evidently not.

You can download GemStone/S 64 Web Edition for free, and use it free (for commercial use, too!). Only when your database grows beyond about 2 gigs, you need to get a license, which is about $7000 a year.

It's that sort of bullshit that killed systems like Smalltalk in the market. Companies like Gemstone will still be able to extract money from their captive audience for a couple of decades, but mainstream platforms are eating away at their market share, year after year.

The only chance platforms like this have is to go open source and sell high-end add-ons and support.

They haven't incorporated ruby into GemStone/S to make it attractive; they haven't incorporated it into GemStone/S at all.

Well, then you can add to all their other problems an unfocused product strategy and lack of integration across their product line.

Re:Sounds cool, but not open

[rossifer]

Perhaps you have yet to really understand how an object model that isn't driven by the constraints of the underlying RDMS can make the problem simpler.

There are vanishingly few cases where following the conventions of an RDBMS will limit your options in OO design. I have certainly come across instances where my initial object design didn't cleanly fit into relational tables, however, the issue was usually revealed to be a problem in the object design that would have caused even more problems later. In my experience, the exercise of co-designing a good database and a good object model usually results in a better overall design.

[OORDBMS's] can often make what is a very complex SQL query into a fairly simple [OQL construct]

I don't object to Object Query Languages and I absolutely agree that when you're looking at the data from an OO perspective, an OQL is very likely to be superior to SQL (if only because the type names will be preserved in the query). However, I get one or more decent OQL implementation with the ORM's I use, so I haven't had to give up OQL with an ORM solution so far.

What I'm objecting to is the loss of SQL and PL-SQL that occurs with OORDBMS's. Relational programming is an extra tool in the toolbox, and a very valuable one for the issues that surround large or complex datasets. Relational programming provides a proof/set theory/mathematical view of your data that is mostly orthogonal to how Object systems want you to think about data. Using an OORDBMS eliminates a whole way of thinking about data.

Perhaps there is more than one way to do it...

Exactly my point. Don't wedge yourself into a corner down the road where an integration that requires SQL can't possibly work just because you chose an OODBMS.

Re:OODB, oh oh

[__aavljf5849]

"What efficiency advantages do they have over naive 'fetch record; do something; fetch another record' procedural code for dealing with large amounts of data?"

Efficiency I don't know. But with a good OODB you do not "fetch record, do something, write start over". You just do it. In your typical ZODB application there is no difference between doing something on objects in memory and doing it on objects stored in the database. The only difference is that the objects inherit from a persistent subclass.

The benefit of this i that you no longer have to design the database. You design your objects as you would use them, and that's it. The database part is completely transparent. You don't have to care that there is a database there. This speeds up development something fantastically.