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.

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

Phil