From: Sean Middleditch <elanthis@...>
Date: 2002-04-04T05:22:31+09:00
Subject: Re: About efficiency

On Wed, 2002-04-03 at 14:50, Phil Tomson wrote:
> In article <85644AC8-471C-11D6-AC9B-000393040AA2@cjack.com>,
> Chris Thomas  <cjack@cjack.com> 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?
> 
> If you consider the case of Perl, most of the time people don't bother to 
> save the 'bytecode' so the code is always parsed and converted to bytecode 
> each time the program is run.

Well, consider Python then, where it by default stores the bytecode to
disk.  (.pyc files)

> 
> >
> >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.
> >
> >(I ask because it doesn't seem logical to me that interpreting bytecode 
> >should be inherently faster than interpreting tree nodes.)
> 
> I have to agree.  Perhaps a bytecode VM can be faster when JIT is 
> introduced, but otherwise I don't see where the advantage lies.

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.

All of these coupled together, along with some other optimizations that
I couldn't get to work reliably (easily) in a tree situation, make
bytecode really great.  My implementation is actually only
psuedo-bytecode (in Scriptix), and I think I can pull off even more
performance when I get around to finishing the conversion (which I need
for true multi-threading in a single OS thread, where the application
can regain full control between context switches, without fear of
running out of stack space).

> 
> Phil