From: Sean Middleditch <elanthis@...>
Date: 2002-04-04T01:37:39+09:00
Subject: Re: About efficiency

On Wed, 2002-04-03 at 11:04, Chris Thomas wrote:
> 
> On Tuesday, April 2, 2002, at 05:46 PM, Sean Middleditch wrote:
> 
> >>> I have been enjoying Ruby for 2 weeks now. I am very impressed. It is
> >>> my understanding that currently the interpreter directly executes the
> >>> parse tree versus going thru some bytecode generation phase (the later
> >>> is what I did for some interpreter I wrote years ago, while at the
> >>> same time a friend of mine was going the ruby way, hence we had
> >>> opportunities to compare).
> >>
> >> Ruby VM is planned.
> >
> > VM's make things a *lot* faster.  I'm experimenting with Scriptix, and
> > taking it from the Ruby-ish nodes to a byte-code language improved the
> > speed by 1.5-3 times, depending on the test (I'm no profressional
> > benchmark writer, mind you).
> 
> I'm curious, do you know exactly where the speed gains come from in your 
> implementation? Is it from the elimination of the need to parse the code 
> every time it's run, or from something else?

Many things.  One of the biggest (on modern processors) is cache
coherency - not needing to jump around all over the place to find the
data.  Also, since you can allocate chunks of memory, you can reduce the
amount of calls to malloc.

> 
> If the gain is made by eliminating the need to parse the source, 
> presumably one could make similar gains simply by flattening the tree 
> representation.

Which is more or less what byte code is.  ^,^  A tree, the last executed
command is the first one encountered by the interpreter.  With byte, you
start with the leaves, evaluate them, then evaluate their parent, etc. 
You could fairly easily take a tree, write it out in reverse order, and
there you go - a simple, unoptimized VM. 

> 
> (I ask because it doesn't seem logical to me that interpreting bytecode 
> should be inherently faster than interpreting tree nodes.)

Well, it's surprising what does and does not make things faster,
especially when you consider compiler optimizations, and the complexity
of todays PC processors.  I've done some things in Scriptix that I
thought would really help (reducing trees, reducing comparisons, etc.)
and it actually made it slower by a good amount.

I know most of my optimization knowledge is based on the 486, so I'm
learning a good deal with how these 65million transistor
offenses-to-RISC work.  ^,^

> 
> Chris
> 
> 
> 
>