This is nonsense. Ruby's MRI interpreter can be beaten by an unusually wide margin because it is unusually slow for an interpreter of a language like Ruby. Go look at the benchmarks on http://shootout.alioth.debian.org/ -- on many benchmarks, fast implementations of similar dynamic languages like Python, Scheme, and (tellingly) Smalltalk beat Ruby's MRI by ~10x.
Is there a section that benchmarks interpreters within the same language against one another?
I think the point of this article was to see how realistic the promises of MagLev are compared to the fruits of labor of other teams building specifically Ruby interpreters for the last couple of years.
The question whether it is possible to make Ruby faster is very close to how fast can we make other similar languages. If we can make a system run Smalltalk much faster than the same system can run the best Ruby implementation, we know something in the Ruby implementation is very wrong.
Every language in this league solves very similar problems. It's the techniques people use to solve them that make the difference in performance.
While not as good as directly comparing different Ruby implementations, the results of comparing similar languages lend some credibility to the Maglev claims.
So, I've read this a couple of times now, and I honestly can't see this as being anything other than someone being intentionally contrarian.
As far as I can tell, this guy was not at the presentation, and is basing his opinions on snippets that he's read elsewhere on the net. Additionally, as far as I can tell, this guy hasn't produced anything of merit to the programming community.
I'm not a rails apologist, and have never actually done anything in Ruby, but to me this guy comes off as a gas bag who thinks he knows better than everyone else; all based on hearsay.
Now I wasn't at the conference either, but you have to admit that this whole thing smells like pure hype. As they say, "if it sounds too good to be true, it probably is".
Well, it _is_ pure hype until such time as they ship. That being said, it doesn't sound too good to be true, it sounds like they are trying to drag Ruby up to the state-of-the-art for dynamic language performance circa 1990 or so.
=My equally uninformed windbaggish douchebaggery guess is that there will be some serious compromises to be made if you want 10x-50+x performance. For example, what if you need a pragma to turn eval and method_missing off for a section of code to obtain the highest performance?
In that case, it won't run every Ruby program at hyper speed, but I bet a lot of people will ask themselves if they need those two difficult-to-optimize features for 100% of their code, or whether they can turn them off here or there or even forgo them entirely.
I guess what I am trying to say is that it probably isn't as good as it sounds in some respects but it may still have plenty of room to be a game-changer.
You don't need to turn off the equivalents of eval and method_missing to get full performance in Smalltalk. Not using them might be advisable in performance critical code in either language, however.
Also, the commercial Smalltalk JIT VMs are generally quite a bit ahead of the 1990's in terms of performance. Don't be also guilty of using "common sense."
Maybe it's just his tone that rubbed the wrong way. The entire article reminded me of some superbowl commercial where everyone's posteriors were dispensing advice.
He basically has a thousand words about MagLev being bullshit, but he has no credentials or proof to back it up.
I guess I just trust Avi Bryant's opinion over some random blogger's.
Not only that, but he's revealing his ignorance of how the VMs in question differ. The 1.8 Matz VM traverses a partial Abstract Syntax Tree to interpret. The Gemstone VM is JIT-ing. On top of that, it has better GC.
Oh, this is really rich: "However, it seems to me that Smalltalk is far less flexible than Ruby, while being semantically much more machine-friendly." (From the comments.)
From my comments:
"Oh, and “Smalltalk is less flexible than Ruby?” Uh, no. Any serious language maven will tell you that they are almost identical in many respects, but that Smalltalk wins because you can not only modify the entire library, you can refactor base classes completely out of existence, and you can arbitrarily change the grammar. (And there’s even more!) This is precisely why it’s relatively easy to put Ruby on top of the Smalltalk VM. If you can bootstrap a Ruby parser into a Smalltalk image, the Smalltalk image can incrementally morph itself into Ruby.
(And another goal of the Rubinius project is to give Ruby the same level of meta-capabilities already present in Smalltalk!)"
PWNED!
EDIT: Okay, Sho has changed his tone in his latest comments. I think he just blogged off the cuff and didn't realize how widely read his blog post might be. He even says he's going to check out Smalltalk.
