Hacker News Reader

Comment by dmix | Hacker News Reader

Could someone explain what this is to a Rails guy?

So, you know how like Rails runs on Ruby, which is kinda slow. As you may or may not know, Ruby isn't compiled into any sort of machine code, or even bytecode. It is compiled down into a tree-representation (like all languages i think), but instead of taking this tree representation into bytecode or native machine code, they just leave it. This makes ruby extra slow and hard to optimize. Rubinus (as far as I know) takes the tree and makes bytecode which is then executed on a VM. This should make it much faster.

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-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?t...

Rubinius seems to offer some nice support in terms of running reliable ruby (http://en.wikipedia.org/wiki/Rubinius), but in terms of performance and actual usability, it has a long way to go.

Parrot 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.

Or 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.

Arg, how can you be a rails guy if you need this explained?

Reply on news.ycombinator.com