From: Sean Middleditch <elanthis@...>
Date: 2002-04-05T00:45:53+09:00
Subject: Re: About efficiency

On Thu, 2002-04-04 at 03:51, 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).

I'm not sure I follow - the way I see it, the parser/compiler just
builds the tree, totally separate from the execution phase.  Then, once
the tree is built, it can be executed.  You could, theoretically, have
two different parsers and two different evaluators - so long as they
store things in the same data structures, they should be interoperable.

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

Hmm.  That is an idea... my code merges the parse and compile phases (as
it encounters the tokens, it pushes the values and operators onto the
byte-code buffer).  It has made some of the more sane optimizations
difficult (i.e., converting -123 from "the value 123, handed to the
negate operator" to "negative 123").

> 
> Mmm .. Dan (or whoever it was) said this better, but I can't find the
> post..
> 
> -- George