From: Dan Sugalski <dan@...>
Date: 2002-04-06T03:04:29+09:00
Subject: Re: About efficiency

At 5:51 PM +0900 4/4/02, George Marrows wrote:
>Sean Middleditch <elanthis@awesomeplay.com> wrote in message 
>news:<1017865258.16579.67.camel@smiddle>...
>
>>  Again, as I said in my other post - there are two are three speed
>>  advantages to bytecode.  First, less memory usage, and memory allocation
>>  takes time.  Second, cache coherency, because RAM is very slow, and
>>  having to jump around memory to execute a simple block is slow.  And
>>  third, you encounter what needs to be evaluated first, not reverse order
>>  like a tree.
>
>There's also the meta-speed-up that I think someone (Dan Sugalski?)
>mentioned on this list: with a tree interpreter, there's the risk of
>having too tight a coupling between the parse and the execution phases
>- both have got to be aware of the other's needs and so it's hard to
>optimise them. The coupling can also make it harder to understand the
>structure of the interpreter, which also makes it harder to apply
>optimisations. (Not that Ruby necessarily suffers from either of these
>problems, of course).

>With a bytecode interpreter, you've probably got three phases: parse,
>compile and execute, with a clearer distinction between them. You can
>hack on one without breaking the others (too much), and each phase can
>be simpler, which makes it easier for people to figure out how to add
>optimisations.

I'm pretty sure I said something like that.

It's not tree-structured interpreters per se--they're fine, and we've 
done well with them over the decades. They also map well onto a stack 
based system. At this point, though, I'm pretty convinced that a 
register-style engine is where the ultimate speed advantage lies, 
even discounting all the work done on optimizing for a register 
environment. (Which get you a bigger win) I may be a little biased 
there, though :)

The conceptual separation is in some ways the biggest win of all, though.

Speaking from experience, designing an interpreter is hard. Designing 
a language is hard. Designing a good library of code is hard. You 
also need different sets of skills for each of them. Finding someone 
with one set of skills is tough, let alone someone with two, or 
three, sets.

That Matz, and Larry, and Guido have done what they've done, and that 
things work as well as they do, amazes me. I know, from personal 
experience, that as a language designer I really stink. :) The nice 
thing about the separation of the pieces, though, is that I don't 
have to worry about it. My job is to do the interpreter, and nothing 
else. That's all semantics and capabilities and, while it's a 
full-time job, I can do that. In perl 6's case, it frees Larry up for 
the hard job of doing language design, which is also a full-time job.

-- 
                                         Dan

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