Slashdot Mirror

← Back to Stories (view on slashdot.org)

MagLev, Ruby VM on Gemstone OODB, Wows RailsConf

Posted by kdawson on from the rails-oh-i-get-it dept.

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

31 of 132 comments (clear)

  1. I'm sorry... by Anonymous Coward · · Score: 5, Insightful

    What?

    1. Re:I'm sorry... by corsec67 · · Score: 4, Informative

      Agreed, I develop in Ruby on Rails full-time, and I barely understood 1/3 of that summary.

      OODB = Object Oriented Database (possibly a OODB type of model) helps in translating that from specialist to mere geek.

      --
      If I have nothing to hide, don't search me
    2. Re:I'm sorry... by snl2587 · · Score: 2, Informative

      And I, for one, wouldn't want to work for you for failing to understand what the GP was saying.

    3. Re:I'm sorry... by ESqVIP · · Score: 4, Informative

      Indeed, incredibly poor summary.

      Basically, GemStone, a company which has been working on large-scale object-oriented database systems and a Smalltalk implementation (GemStone/S) for decades, has decided to support Ruby on their infrastructure. Turns out Ruby is indeed quite similar to Smalltalk, and some microbenchmarks already show them as being 8~60x faster than MRI (the main Ruby 1.8 implementation). Should those numbers remain consistent, this will be an incredibly fast implementation of a popular scripting language, surpassing by Python, PHP, Lua, and other Ruby implementations in raw numbers.

      This might be a massive push for Ruby/Rails on "enterprise" systems. And if they succeed, this could also be one interesting step reviving the popularity of OODBMSs.

    4. Re:I'm sorry... by ESqVIP · · Score: 2, Informative

      Definitely not. They've been talking about a free-gratis version, and there's chance they will open some of their standard library (possibly sharing part of it with Rubinius, since both have a similar goal of writing as much as possible directly in Ruby), but you shouldn't expect them opening their VM or OODB stuff anytime soon.

      But well, if anything, they show how far open implementations of dynamic languages can get performance-wise. The current breed of languages has always lagged behind the old ones (like Lisp and Smalltalk), and this is great proof there's no technical reason for that.

    5. Re:I'm sorry... by pnagel · · Score: 5, Informative

      Basically, GemStone, a company which has been working on large-scale object-oriented database systems and a Smalltalk implementation (GemStone/S)

      You make it sound as if the object oriented database and the Smalltalk implementation are two separate products. Which is a common misconception.

      To oversimplify, GemStone's Smalltalk VM is an OODB. It adds the following features to the language:
          1) Begin transaction, commit transaction, abort transaction.
          2) All of your process space, your global variables, your datastructures etc. are persisted. You can switch power-cycle your computer and have the same program running as used to run before.

      I'm sure they did the same for Ruby with maglev.

      This approach cuts out layers and layers of persistence crap. Bye bye object-relational persistence mapping crud.
    6. Re:I'm sorry... by pnagel · · Score: 2, Interesting

      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


  2. An audience that needs ... by Marbleless · · Score: 5, Funny

    >Gemstone demoed [MagLev,] their Ruby VM built on their GemStone S64 VM, to an ecstatic audience.

    An audience that needs ...

    a) to buy some vowels, and
    b) to find significant others to get ecstatic about! ;)

    --
    --I thought I was wrong once, but I was mistaken.
  3. Sad . . . by Anonymous Coward · · Score: 5, Funny

    > murphee ends along a report from InfoQ

    I am sorry to hear of murphee's death, and hope that no more lives are claimed by this report's incomprehensibility.

  4. Shot in the dark by smittyoneeach · · Score: 4, Insightful

    "MagLev, Ruby VM on Gemstone OODB, Wows RailsConf"
    Some magnetic levitation involving rubies, VM (Ware?), more gems, object oriented databases (didn't they die?), World of Warcraft, rails (magnetic levitation again?), and, finally, conference.
    Doesn't the Lameness Filter usually take care of this sort of thing?

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    1. Re:Shot in the dark by noidentity · · Score: 5, Funny

      Just yesterday I was working on SuperCollider, hooking it with OilRig, implemented with SuperTanker, using ConcreteRoad as the substrate. I had some problems with the DeepSea module, but it was really due to RadioAntenna. You're confused? These are just the names of some database libraries, nothing to do with what their names imply.

  5. Re:Sounds cool, but not open by catch23 · · Score: 2, Informative

    Just so you know, gemstone isn't exactly new, it might be as old, or older than some of those Oracle products and have been running in production environments for years. Just because you've never heard of it doesn't mean it's brand new. There's quite a few old financial companies running on smalltalk systems built by gemstone. Unfortunately, much of Smalltalk's history has been closed-source. Even the GPL Squeak was late to the game (1997). Fortunately, smalltalk is a pretty simple language so it's actually relatively easy to get a very good stable VM implementation in a short time.

  6. Great Ruby news by Santana · · Score: 5, Informative

    Maglev is the long awaited (by Rubyists at least) Ruby VM (virtual machine) developed by Gemstone, who also develop an OODB (use Wikipedia for this one, you can do it).

    Railsconf is a good opportunity for Gemstone to show off their object persistence, since it would benefit Ruby on Rails (which uses O/RM that may not be necessary any more.)

    --
    The best way to predict the future is to invent it
  7. Talk really did wow the conference by stockmaster · · Score: 5, Informative

    This talk was one of the highlights of the conference. At the talk, they showed performance benchmarks that included running several things as much as 117x as fast as the default Ruby interpreter that is in use by most Rails installations today. The fact that it's built on this commercial-grade Gemstone platform that has been used for years for high-performance production Smalltalk applications just adds to its credibility.

    One of the reasons this is exciting is that many Ruby/Rails programmers have suffered from the criticism that their platform is elegant and fast to develop in, but that it doesn't scale well. MagLev sure looked like it could go a long way toward addressing those concerns. And since it hits Ruby right at the VM level, it is potentially useful to anyone running any kind of Ruby app whether on Rails or not.

    Of course, we'll see when it's done...

    1. Re:Talk really did wow the conference by Standard+User+79 · · Score: 2, Interesting

      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.

  8. Ruby Shootout by cryptoluddite · · Score: 5, Interesting

    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.
    1. Re:Ruby Shootout by cryptoluddite · · Score: 3, Interesting

      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.

  9. Re:Sounds cool, but not open by tshawkins · · Score: 4, Informative

    its a single data cloud instance on a distributed data system, in that respect its similar to products like Amazons SDB and Google's BigTable systems. The data is virtualised across a number of data stores. A lot of telecos use gemstone, its used a lot in financials. Its a True OODBMS which is exactly the model that the ORM layers in frameworks like rails are attempting to simulate on a relational database. OODBMS systems match the datamodel of modern web frameworks closer than any relational system every will do. Other Commercial OODBMS systems are system such as ObjectStore, POET, there a few opensource ones such as GOODS

  10. Video of Avi Bryant talk from 2007 by OldManAndTheC++ · · Score: 3, Informative

    Avi Bryant gave a fascinating talk about bringing technology developed for Smalltalk into the Ruby world at RailsConf 2007. Apropos of nothing, he bears an uncanny resemblance to Jeremy Davies (Daniel Faraday on "Lost").

    Basically he's saying that many of the performance issues with the much-maligned Ruby VM were solved years ago in Smalltalk implementations, and that Ruby ought to incorporate those ideas. Maglev is a big step in this direction.

    --
    Soylent Green is peoplicious!
  11. This is getting sillly. by MrMista_B · · Score: 3, Funny

    From Wikipedia (yeah it's not a source that's reliable at all, but this is the internet): http://en.wikipedia.org/wiki/Maglev

    "Magnetic levitation, maglev, or magnetic suspension is a method by which an object is suspended with no support other than magnetic fields. The electromagnetic force is used to counteract the effects of the gravitational force."

    If they're doing *that* with code, I'll be hell of impressed. If not, that's a pretty strange way to brand your project/product/language/whatever that is. Seriously, I'm sure it's awesome, but what is it with all these things (MagLev, Ruby, etc) trying to sound cool by appropriating names of other, already well-established 'things'?

    Or next am I going to be using "Ice-cream, Santa Claus on Purple Monkey OODB with Cowboy Hat and Kitchen Fork to PWN the OMGWTFBBQ on the MBA with the XKCD in the Ballroom with the Candlestick"?

    Seriously, these names are getting silly.

    Not that 'Linux' or 'Ubuntu' or 'MySQL' sound any less silly to people not familiar with them, but at least they're not likely to be confusing or confused for something else.

    */minirant*

    1. Re:This is getting sillly. by Sique · · Score: 2, Funny

      With regular trains reaching 575 km/h (357 mph) and the world record for MagLevs being 581 km/h (361 mph), there is really no difference in speed for both technologies.

      --
      .sig: Sique *sigh*
  12. OODB, oh oh by Tablizer · · Score: 2, Interesting

    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?

    --
    Table-ized A.I.
    1. Re:OODB, oh oh by Ed+Avis · · Score: 2, Interesting

      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?

      --
      -- Ed Avis ed@membled.com
    2. Re:OODB, oh oh by Tablizer · · Score: 2, Insightful

      What are those "problematic ideas" you are taling about and how does an RDBMS help us with analyzing large tree and/or graph datasets, knowledge bases and other forms of data that does not fit the relational model?

      It is possible to add declarative tree/graph traversal to a query language, and Oracle does a little bit of this. Plus, "node hopping", if needed, can be done in a relational database just as well as a non-relational one. Its just that existing implementations are not optimized for them. But thats an implementation limit, not a flaw in relational theory itself.

      I will agree there may be places where relational may not work so smooth, but the claims by many OODBMS proponents is that OODBMS should *replace* RDBMS, not merely fill in the side-niches where relational has difficulties. If you are a "side nicher", then we can come to a truce.

      --
      Table-ized A.I.
    3. Re:OODB, oh oh by __aavljf5849 · · Score: 2, Interesting

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

  13. Re:Sounds cool, but not open by rossifer · · Score: 2, Insightful

    Its a True OODBMS which is exactly the model that the ORM layers in frameworks like rails are attempting to simulate on a relational database.
    That's a very silly statement.

    I don't use an ORM to simulate an OODBMS. I use an ORM so that I have a system with both Object Oriented and Relational programming models and can use either one when appropriate. There are a lot of people who don't understand the value of Relational programming, and they think that those of us using RDBMS's would really prefer OODBMS's if only we could see the light...

    Drink the kool-aid is more like.

    I have yet to see a problem simple enough that I would choose to use an OODBMS over an RDBMS while simultaneously being interesting enough that I would bother working on it in the first place.

    But maybe I'm just being grumpy. Bah.
  14. Re:Sounds cool, but not open by WeirdJohn · · Score: 2, Interesting

    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.

  15. news that matters? by nguy · · Score: 5, Insightful

    Gemstone is a proprietary implementation of Smalltalk and an associated object database. Who does it matter to whether they incorporate a RubyVM into their system or not?

    Gemstone also stands for the failure of a particular kind of business model. These people (and others) had a mature OO programming language that was orders of magnitude faster than Ruby, had object persistence, had a great IDE, and supported distributed programming over 15 years ago, and they pissed it all away by making it too expensive and too proprietary.

    Because the Smalltalk vendors were greedy and squabbling among themselves, modern OOP arrived more than a decade later in in much poorer form.

    I suppose hiding their Smalltalk heritage by calling their system "Gemstone/S" and being forced to incorporate Ruby in order to make their platform attractive is the ultimate indignity.

    1. Re:news that matters? by angdraug · · Score: 3, Insightful

      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. Nowhere near good enough. $7000 a year is the exact outrage the previous poster was talking about. And 2 gigs is not much if you consider that it has to hold all your objects and their fleas. Not to mention that it's not really free (as in freedom) until it can be found in Debian/main.
    2. Re:news that matters? by nguy · · Score: 2, Interesting

      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.

  16. Re:Sounds cool, but not open by rossifer · · Score: 2, Interesting

    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.