7 ms·

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

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?

jon_dahl 16y ago
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.
- nkassis 16y ago
  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.
  - GrandMasterBirt 16y ago
    Better question: What happens if companies like google start eyeballing it and putting some real money behind it.
    - jemfinch 16y ago
      You mean the same Google where Python beat Ruby years ago?
      - GrandMasterBirt 16y 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.
        steveklabnik 16y ago
        > 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?
        jamesbritt 16y ago
        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."
        crazydiamond 16y ago
        > 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
        riffraff 16y ago
        appengine runs jruby, that is good enough :)
sreque 16y ago
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.
- evanphx 16y ago
  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.
  - kemiller 16y ago
    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.
    - evanphx 16y ago
      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.
ezmobius 16y ago
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.

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?

jon_dahl 16y ago

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.

nkassis 16y ago
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.
- GrandMasterBirt 16y ago
  Better question: What happens if companies like google start eyeballing it and putting some real money behind it.
  - jemfinch 16y ago
    You mean the same Google where Python beat Ruby years ago?
    - GrandMasterBirt 16y 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.
      - steveklabnik 16y ago
        > 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?
        jamesbritt 16y ago
        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."
        crazydiamond 16y ago
        > 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
      - riffraff 16y ago
        appengine runs jruby, that is good enough :)

sreque 16y ago

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.

evanphx 16y ago
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.
- kemiller 16y ago
  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.
  - evanphx 16y ago
    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.

ezmobius 16y ago

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.