3 ms·
Although this is what should happen, it doesn't quite seem to be the case. Pretty much every other ruby implementation destroys Rubinius in terms of performance
by randy 18y ago
Although this is what should happen, it doesn't quite seem to be the case. Pretty much every other ruby implementation destroys Rubinius in terms of performance. It's also worthwhile to note that 1.9/YARV, which is bytecoded, destroys every other ruby implementation and should actually be a major boost to Rails once the compatibility issues are worked out (Matz released 1.9 during Christmas of 2007, but it's just the developer version). You can see benchmarks here:
http://antoniocangiano.com/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal/ http://antoniocangiano.com/2007/02/19/ruby-implementations-s...
You can also see how 1.9 fares against 1.86 directly in the code shootout:
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t...
Rubinius seems to offer some nice support in terms of running reliable ruby (http://en.wikipedia.org/wiki/Rubinius http://en.wikipedia.org/wiki/Rubinius), but in terms of performance and actual usability, it has a long way to go.
- kingkongrevenge 18y agoParrot ftw. Why should there be so much redundant effort on so many dynamic language VMs? They will all run best on Parrot soon enough. The languages will easily share libraries, too.
- jamesbritt 18y agoOr Ruby 1.9 for FTW.sooner, if you are mainly concerned with Ruby. Or JRuby, FTW.now, as amazing progress is made daily, and I expect that interaction of libraries from other J* languages will be all part of the JVM wonderland.