MagLev, Ruby VM on Gemstone OODB, Wows RailsConf 132
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."
I'm sorry... (Score:5, Insightful)
Re:I'm sorry... (Score:5, Informative)
OODB = Object Oriented Database (possibly a OODB type of model) helps in translating that from specialist to mere geek.
Re: (Score:2)
http://www.infoq.com/news/2008/04/maglev-gemstone-builds-ruby [infoq.com]
and I'm not even a Rails developer, just a Ruby enthusiast.
OODB, oh oh (Score:3, Interesting)
Re: (Score:2)
I am way to young to have been their but I do recall the history portions of my computer science education. Hey even in engineering like disiplines those who don't know their history are doomed to repeat it. What existed before RDBs at least in the saleable world were table systems based on flat files with no integrity checking and implemented without
Re: (Score:2)
A step backwards? A fad? How exactly is designing a database capable of doing things that RDBMS cannot (or cannot do easily, that does not matter) supposed to be "a step backwards"? There are tasks for which using an RDBMS is simply inadequate, but since the problem still does not fit into memory, you still need some form of database (if we define "database" as a piece of software capable of handling a big amount of data that does not force you to think how yo store it and lets you do the creative work).
W
Re: (Score:2)
Anyway, an OODBMS can express relations just fine; they're just not usually locked in to a fixed schema. What gave Codd fits was that early OODBs didn't even have so much of a formal schema mechanism (and some still don't) so you'd have to query by following a graph and no other way. Really good OODBs have a solid meta-model you can target for queries, and thus implement
Re: (Score:1)
Re: (Score:2)
Usually by allowing to run arbitrary algorithms on the server side (or in-process, in case of embedded OODBMS), often in a natively compiled language (like Allegro Common Lisp in case of AllegroCache, which has *very* high performance), without client-to-server roundtrips, without impedance mismatches, without forcing you to express the idea with relational operators only.
If you can't express the algorithm with sorts and joins, you have to do cost
Re: (Score:2, Interesting)
Re: (Score:2, Interesting)
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 bene
Re: (Score:2, Insightful)
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 tha
Re: (Score:1)
Re: (Score:3, Informative)
And I, for one, wouldn't want to work for you for failing to understand what the GP was saying.
Re: (Score:2)
I'll be more specific. It is my understanding that the post I was referring to was expanding the acronym OODB so the summary wasn't as hard to understand. And if you're the A.C. I responded to before then...wow...
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Great Ruby news (Score:5, Informative)
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.)
Re: (Score:1)
Re: (Score:2)
There is still plenty of RoR interest, plus MagLev is just as relevant to a lot of what people leave RoR for.
Re:I'm sorry... (Score:4, Informative)
Indeed, incredibly poor summary.
Basically, GemStone, a company which has been working on large-scale object-oriented database systems [wikipedia.org] 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.
Re: (Score:1)
Re: (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 (l
Re: (Score:1)
"GemStone is still pondering a pricing model for MagLev. Bob Walker did state that there will be a free version available."
Re:I'm sorry... (Score:5, Informative)
Basically, GemStone, a company which has been working on large-scale object-oriented database systems [wikipedia.org] and a Smalltalk implementation (GemStone/S)
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.
Re: (Score:2)
The especially great thing about this is that when our Rails apps barf, the only recourse is to reboot rails. Now the clusterfuckery can be persisted!
Ruby on Rails is delightful to develop in. But deploying it across something that gets hammered a lot is a nightmare. Say what you will, but scaling up Python or PHP is way easier.
Quote of the day (actually I see this dozens of times per day): "Twitter retu
Re: (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.
Re: (Score:1)
An audience that needs ... (Score:5, Funny)
An audience that needs
a) to buy some vowels, and
b) to find significant others to get ecstatic about!
Sad . . . (Score:5, Funny)
I am sorry to hear of murphee's death, and hope that no more lives are claimed by this report's incomprehensibility.
WTF ?! (Score:1, Informative)
Shot in the dark (Score:4, Insightful)
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?
Re:Shot in the dark (Score:5, Funny)
Re: (Score:2)
Re: (Score:1)
Talk really did wow the conference (Score:5, Informative)
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...
Re: (Score:2, Interesting)
Re: (Score:2)
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.
"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" means that they're going to keep their proprietary solution to themselves and make lots of money.
Gemstone has spent a lot of time optimizing their code, are they just going to give that away for free?
Re: (Score:1, Troll)
Re: (Score:2)
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.
Well, without in any way detracting from the technical prowess of the Gemstone folks - sounds like they know their stuff with OODBs - beating the default implementation Ruby on the performance front isn't that hard. Certainly traditionally, Ruby was slow by all independent measures such as the Language Shootout [debian.org].
I suppose this does beg the questions: does the Gemstone-based system do better in the shootout benchmarks? If so, by how much? And since there's often tradeoffs between optimizations and (frequentl
Ruby Shootout (Score:5, Interesting)
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
Re: (Score:2)
Well, Matz's Ruby (or MRI) is still _the_ reference, so it makes sense to compare to it. What is really missing is how fast Maglev is. This blog post [obiefernandez.com] talks about 8x to 60x faster, which is impressive.
Re: (Score:1)
An 8x-60x faster is probably a few numerical benchmarks or possibly something like a regex implementation, and even if true won't have much impact on Ruby overall performance (since you don't use Ruby or Smalltalk for numerical work anyway).
Still, Smalltalk VMs are very advanced and the added
Re: (Score:1, Insightful)
Ruby's syntax is not better than smalltalk - it's more complicated. the only thing "better" about it, is that it sometimes vaguely resembles C syntax.
If you spent ten minute with Smalltalk's syntax you'd realise th
Re: (Score:2)
Ruby's syntax is not better than smalltalk - it's more complicated. the only thing "better" about it, is that it sometimes vaguely resembles C syntax.
Smalltalk's syntax is not complicated enough. Algol syntax has dominated for 60 years. If you think having a C-like syntax is a flaw then you are not thinking rationally.
"precedence" is not sane - it's a complicated set of exceptions that make a programing language more complicated to implement, but don't really gain anything.
So they teach math using hungarian notation in schools... where exactly? Our natural languages contain precedence and all sorts of complicated syntax that we are hardwired to understand. Smalltalk fails because it wants to be 'pure' and 'simple' in places where that is not an advantage.
Precedence Shootout (tangle trail warning) (Score:1)
After that, I started learning 6800 assembler the bottom-up way (playing with a prototyping board with a monitor/debug ROM). Wired a BASIC onto the board, but I wanted a high-level language. I took Pascal and ForTran at the same time, IIRC, at the local college, and the professor mentioned that I might be able to find a FORTH to load onto it. (He also
Polish, not Hungarian (Score:2)
Sorry for the lecture in Central-European geography, but you were thinking of Polish notation [wikipedia.org].
Hungarian [wikipedia.org] is something different altogether. You don't want to know.
Re: (Score:1)
Re:Ruby Shootout (Score:4, Interesting)
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: (Score:1)
Re: (Score:2)
Where there's a common misconception. YARV's tests were not supposed to be used for benchmarking Ruby, according to its author [grayproductions.net]:
Benchmark tests: Some people using YARV's bnechmarks I wrote. But I didn't write these codes to measure "Ruby's general benchmark test", but to measure speed-up ratio on YARV. It's means that I wrote codes what YARV optimizes. We must prep
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
I think I lost my Super Geek certificate (Score:2, Redundant)
Re: (Score:1)
Re: (Score:2)
Video of Avi Bryant talk from 2007 (Score:4, Informative)
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.
How does this compare to Zope? (Score:1)
This is getting sillly. (Score:3, Funny)
"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*
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
really could do with a penis transplant, perhaps like
cause the former really isnt that flattering to the auther is it?.. perhaps she also laughed out loud at your 'tool'?
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:3, Funny)
Re: (Score:1)
NEO
Do you always look at it
encoded?
CYPHER
Have to. The image
translators sort of work
for the construct programs
but there's way too much
information to decode the
Matrix. You get used to
it, though. Your brain
does the translating. I
don't even see the code.
All I see is blonde,
b
Re: (Score:1)
Oh, OODB in a dynamic language⦠(Score:2)
Re: (Score:2)
news that matters? (Score:5, Insightful)
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.
Re: (Score:1)
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.
That's changing.
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.
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.
They haven't incorporated ruby into GemStone/S to make it attractive; they haven't incorporated it into GemStone/S at all.
Maglev is a distinct product.
Re: (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.
Re: (Score:3, Interesting)
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
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Google is a fantastic resource to ease your ignorance.
Remember just because you haven't heard of it doesn't mean it doesn't exit.
Re: (Score:2)
Re:Sounds cool, but not open (Score:4, Informative)
Re: (Score:2)
Re: (Score:3, Insightful)
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
Re: (Score:1)
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. In particular, the use of a well designed Containers class with well designed efficient enumerators can often make what is a very complex SQL query into a fairly si
Re: (Score:2)
An OODBMS is fine for a program to use to work on a problem (possibly a "large" one) in a more efficient manner.
But an RDBMS is often more convenient to chuck the results to, so that many different entities (programs, people, etc) can _easily_ do stuff with them.
You could have a central OODBMS to do that sort of stuff - but if you're going to have to take an "overhead" hit anyway, might be preferable to use a popular RDBMS beca
Re: (Score:3, Interesting)
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
Re: (Score:1)
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.
Now this is a silly statement, and possibly shows where your viewpoint is skewed, The implication of this is that OODBMS systems are only suitable for simple systems, where the reverse is more the case, i use OODBMS systems when the datamodel gets too complex to use RDBMS systems. Think of a a drawing package, where the scene is comprised of many primitives, lines, boxes, circles, polygons, etc etc, the RDBMS approach is to create a separate table for each type, and link them via complex joins, or create a
Re: (Score:2)
Hm. I've never had that much trouble representing polymorphic class heirarchies in relational table structures.
Fowler's Patterns of Enterprise Application Architecture [amazon.com] can provide some guidance the various means of doing that if you're not clear. Actually, you did describe two of the common ways
Re: (Score:2)
You mean beyond the 17 petrabytes it supports now?
>How?
You add more instances (servers). Any modification made to any server will propogate to the other servers.
>I've never heard of any big website using gemstone.
So? Why should I care whether you have heard of something or not? Why is that relevant?
Have you ever heard of seaside? Smalltalk? Dabbledb?
>If it was open, I'd be more willing to kick
Re: (Score:1)
Re: (Score:1, Offtopic)
Re: (Score:2)
Re: (Score:1)