From: avi@...4.com (Avi Bryant) Date: 2002-07-03T08:12:33+09:00 Subject: Re: REXML in C Sean Russell 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