From: george.marrows@... (George Marrows)
Date: 2002-04-04T17:51:17+09:00
Subject: Re: About efficiency

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.

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

-- George