At 8:41 AM +0900 7/21/02, Brad Cox wrote:
>At 8:09 AM +0900 7/21/02, Dan Sugalski wrote:
>>Speed, mainly. Going from an interpreted to a compiled form gives a 
>>number of opportunities to remove overhead. Walking optrees has 
>>some expense involved--depending on how complex the operation is, 
>>how much optimization you do, and the CPU architecture, you can see 
>>a speedup somewhere between 1.1 and 40 times going compiled.
>
>Compiling Ruby to C is a non-starter as far as I'm concerned. 
>Compiling Ruby to bytecodes (ala Parrot) makes a lot more sense to 
>me.

I agree on both points. (Though I admit to some substantial bias on 
the second) The only real reason to go to C is if someone's looking 
to prototype a direct-to-assembly conversion, though I don't think 
it's a particularly good one. Probably better to target MIX or 
something like that if someone really wanted. (C's ubiquity's one of 
the few things in its favor)

Still, cutting out the interpreter loop has a not insignificant win, 
and boring mechanical translations to C do have even more, though 
there's still the cost of maintaining the language-specific stacks 
and structures. (We've a straightforward bytecode->C translator that 
does a plain substitution of the C source for opcodes we play with 
occasionally for Parrot--letting C's optimizer chew on the resulting 
source gets a remarkably big win)

>Or for that matter, compile it to Smalltalk, Squeak (or even 
>Java??). That way you get Peter Deutch's work on on-the-fly bytecode 
>optimization, which will bring you about as close as you can get to 
>C's speed in a non-stack-based language.

Or Scheme--shouldn't forget Scheme as there's been some interesting 
work on optimizing Scheme JITs, though Scheme and Lisp both feel like 
they do things backwards, and optimizing them's rather tricky. I've 
been hearing about some interesting research in on-the-fly 
optimization of both bytecode and native machine code, though the 
references I've come across have been a bit sketchy.

Sort of a pity there's not much hardware support for the sorts of 
things that make the more dynamic languages interesting. (I'd be 
*thrilled* if there was some way to tie into a system's MMU and page 
fault mechanisms to use real hardware COW and page protection for 
stack and lexical frames)
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan / sidhe.org                         have teddy bears and even
                                       teddy bears get drunk