Sean Russell <ser / germane-software.com> wrote in message news:<3d1fe947 / news.mhogaming.com>...

> That said, I'd really like a Ruby-to-native compiler, because interpreted 
> languages are great for RAD, but tend to suck (relatively) on execution.  
> Even Java, which is pretty fast, still gets nailed on the speed thing.  Try 
> Xalan vs. xsltproc sometime.  Having native binaries is really handy.

Sigh.  There is a common misconception that compiling to native code
will result in some kind of magical speed increase.  It doesn't work
that way; it's not the interpreter that makes Ruby (or Java) slower
than C, it's the semantics.  That is, it's precisely the things you
like about Ruby - dynamic method dispatch, dynamic typing, blocks,
runtime code definition, garbage collection, bounds checking, etc, etc
- that make it slower than well tuned C code.  Translating Ruby into C
or ASM isn't going to help; conversely, a C program that used the same
techniques as Ruby programs would run just as slow.  There is a
fundamental trade-off there that you're not going to sidestep simply
by throwing GCC into the mix.  Yes, the Ruby interpreter could be made
faster, but there's no reason to think a native code compiler is the
best way to do that; personally, I'd much rather see a bytecode VM. 
In fact, on modern machines a JITted bytecode interpreter can
outperform compiled code (by modifying code on the fly to take
advantage of branch prediction).  Thus, a good Java or Smalltalk VM
can have *faster* method dispatch than C++.

To illustrate my point, here are some benchmarks on the GCJ project,
which provides exactly what you're proposing - a GCC frontend - for
Java instead of Ruby.  Not surprisingly, the best Java VMs almost
always perform better than the native code: 
http://www.shudo.net/jit/perf/

Compared to Ruby, Java is a fairly static language; I'm pretty sure
you wouldn't get results even that good with a hypothetical GCR
compiler.  If you want to see the kind of speed Ruby can (somewhat)
realistically hope to obtain, the current state of the art for an
equivalently dynamic language is probably Cincom's VisualWorks
Smalltalk - which, by the way, doesn't use native code.  You could
also look at David Simmons' SmallScript, but it's currently
Windows-only.

Cheers,
Avi