At 04:44 PM 10/29/2001 -0500, Ken Fox wrote:
>Well, I've tuned things up a bit. It's now
>hitting 56 mops with the mops.pasm example. Parrot
>turns in 24 mops on the same machine with the same
>compiler options.
Damn. I hate it when things outside my comfort zone end up being faster. :)
>This is not a fair comparison
>because the Parrot dispatcher isn't optimal, but it
>shows I'm not hand waving about the architecture
>any more... ;)
I didn't think you were, unfortunately. (for me, at least) A SS
architecture skips a level of indirection, and that'll end up being faster
generally.
What sort of dispatch was your version using, and what sort was parrot
using in your test?
>One thing I learned is that it's not necessary (or
>desirable) to do enter/exit scope ops.
Don't forget that you'll need those for higher-level constructs. For
example, this code:
{
my Dog $spot is color('brindle'):breed('welsh corgi');
}
will need to call Dog's constructor and attribute setting code every time
you enter that scope.
You also potentially need to allocate a new scope object every time you
enter a scope so you can remember it properly if any closures are created.
>I implemented
>"sync_scope" which takes a scope id as an operand
>and switches the VM into that scope, adjusting
>the current lexical environment as necessary.
How does this handle nested copies of a single scope? That's the spot a SS
architecture needs to switch to indirect access from direct, otherwise you
can only have a single instance of a particular scope active at any one
time, and that won't work.
I'm curious as to whether the current bytecode could be translated on load
to something a SS interpreter could handle.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
