Hacker News Reader

Comment by GrandMasterBirt | Hacker News Reader

Cool. Is Rubinius faster than 1.8.6 or even 1.9? Was that the goal? Or is it just a 1.0 milestone where the project is compatible enough to meet the 1.8.6 ruby language spec and native libs?

View on HN

The biggest goal, at least a few years ago, was to have a Ruby that is substantially implemented in Ruby, as opposed to being a hundred thousand lines of C under the hood. Paradoxically, this can result in speedups, since it's easier to optimize expressive, well-written code. Avi Bryant gave a talk at RailsConf a few years ago about how Smalltalk contains all the "features" of Ruby that are usually blamed for its performance woes, but still managed to be pretty fast. It's not the language features that keeps Ruby slow; it's the opaque implementation.

I think they are on the right track. Given that this is a 3 year old project, I don't think we can compare it to smalltalk implementation with years of development. I wonder how well it would compare to something like pypy and other similar projects.

Better question: What happens if companies like google start eyeballing it and putting some real money behind it.

You mean the same Google where Python beat Ruby years ago?

Can't blame them, even a year or two ago Ruby and RoR were much inferior to today. And wait till RoR3 hits the shelves full steam. Granted I hope ActiveRecord3 will include everything by default like DataMapper does but whatever...

Ruby is still in infancy stages, Python is quite old. Hell Python was the inspiration for Ruby.

I mean look at what is happening in the Javascript space. If Ruby and JRuby implementations get really f-ing fast, we will get some major backings. The problem is that instead of improving Ruby, Twitter decided to ditch it. Maybe they really didn't have the people Google has when it comes to language builders. Since google app engine runs python it is in direct google interest to make it fast. Once it starts running ruby, vuala! So don't worry, they'll get to it.

> Granted I hope ActiveRecord3 will include everything by default like DataMapper does but whatever...

I'm not sure exactly what you mean by this, but Rails 3 will still be a full stack framework. Something will be chosen for everything by default.

You'll be able to fully switch out ActiveRecord for DataMapper if you wish.

> Hell Python was the inspiration for Ruby.

I've never seen this before, usually I've heard Matz saying that it's Perl. Maybe a typo?

Matz has cited a number of inspirations, including Perl, Python, Lisp, Smalltalk, Self (I think), and CLU.

He's also referred to Ruby as "Matz Lisp."

> He's also referred to Ruby as "Matz Lisp."

So when does the "enlightenment experience" Eric Raymond promised come ? Or did Matz take it all :-D

appengine runs jruby, that is good enough :)

Python was released in 1991; Ruby was released in 1995. If Ruby is significantly lagging behind Python at this point, it seems unlikely to make up the difference in the future.

I just did a quick test of 1.9 vs rubinius on the alioth pidigits and btrees benchmarks, and rubinius was 1.5 times as slow on pidigits and twice as slow on btrees. In addition, the release notes state that they are aware that several string operations in Rubinius are currently slower than their MRI 1.8 equivalents.

I'm excited that rubinius is out, but I'm not sure at the moment what it's advantages are versus MRI in terms of practical use.

This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for running Ruby code. So when you see Rubinius performing, say, 1.5x slower than MRI on a particular String method, what you're seeing is Rubinius running ruby at 1.5x slower than C code. If you compare Rubinius to MRI both running pure ruby code, you'll see Rubinius shine. It's getting the performance of the methods that MRI implements in C that we still have work to do on. This is part of the strategy of the project, because it means that we're improving the performance of all ruby code, thus raising the bar not for just one method but for the whole program.

Hi Evan,

This is perhaps a silly question, but now that you have a solid base of ruby-in-ruby is there any room to re-optimize certain critical sections (hashes, sockets...) in C? Perhaps using a custom API that preserves most or all of the flexibility that is Rubinius's hallmark?

I presume that since you still support most compiled gems that linking to C code is still possible. Just wondering if there might be a best-of-both-worlds solution out there.

We already done that, optimize out certain things into primitives, which are implemented in C++.

We support as subset of the MRI extension API, mainly we don't support anything using RBASIC(), RHASH(), or RREGXP() because those expose raw C data structures and we don't use the same data structures as MRI.

Aren't String and Array a mix of both C++ and Ruby, though? So it's a bit more like saying it's running that mix of C++ and Ruby 1.5x slower than MRI runs C, for varying percentages of Ruby and C++.

Still awesome though!

For pure ruby code you write yourself with your own classes and while loops and algorithms and whatnot, rubinius can be up to 20 times faster then MRI. But there are still some corner cases where it is slower. So micro benchmarks rubinius kicks ass over almost all the rubies. But macro is still has some spots to polish.

The reason for this is that core things like Hash and String and Array are written in pure ruby. And they are only like 1.5 times slower then the C impls in the other rubies. This means that it is optimized for running ruby code really fast, this means that once the edge cases are gone, rubinius will smoke all the other rubies hands down.

Reply on news.ycombinator.com