At 4:42 PM +0200 8/16/02, Peter Gibbs wrote:
>For purely academic purposes, I have re-synchronised some of my
>forbidden code with the latest CVS version of Parrot. All tests pass
>without gc debug; and with gc_debug plus Steve Fink's patch.
>Benchmarks follow, on a 166MHz Pentium running linux 2.2.18.
>
> Parrot African Grey
>life (5000 generations) 172 seconds 81 seconds
>reverse <core_ops.c >/dev/null 193 seconds 130 seconds
>hanoi 14 >/dev/null 51 seconds 37 seconds
How much of the speed win is from the cycle count instead of stack
walking? Unless you've solved the problem of recursive interpreter
calls and setjmp, it's not a valid solution, no matter what the speed
win might be.
>The differences between the two versions are:
>1) Use of the interpreter cycle-counter instead of stack walking.
This still dies in the face of setjmp/longjmp and recursive
interpreter calls. Which, since it's how we're doing exceptions and
parrot-code vtable entries, is kind of problematic.
>2) Linked lists of buffer headers sorted by bufstart
IIRC, this required another pointer per buffer. I really, *really*
don't want to do it, but given the speed wins I'm willing. We chew up
altogether too much memory per internal structure as it is, which is
bad. Suppose we can make that up elsewhere somehow.
>3) COW-supporting code in GC (for all buffer objects)
>4) Implementation of COW for string_copy and string_substr
>
>Items 1 and 2 use techniques that have been specifically banned,
>and items 3 and 4 depend on item 2, so none of this code is
>usable in Parrot (which is why I haven't attached any patches)
Well, all banned things can be unbanned if they work and are faster.
Neither 3 nor 4 fundamentally require 1 or 2,
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
