From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:55:21 -0500
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableIntegerArray, where we allocate
> > arrays of Stack_Chunk entries and manage them that way, instead of
> > a separate allocation per element in the stack.
That would make the implementation of the continuation classes
unnecessarily difficult. These classes need to be able to point to
individual dynamic_env entries in order to restore the dynamic
environment precisely. Using arrays opens the possibility of
overwriting slots, which would destroy dynamic state that some
continuation may depend upon. (And if slots are *not* overwritten, then
you probably lose the benefit of the optimization.)
On Mon, Apr 21, 2008 at 08:48:10PM +0100, Klaas-Jan Stol wrote:
> what about actually using a ResizableIntegerArray for this purpose?
> (or PMC, if Integer is not suitable for storing addresses)
> Or is this a really dumb idea?
I looked at this possibility, and while it can work, the values that
need to be stored are actually pointers, not integers. We could do
some casting there, but I think it'd be a slight step sideways, when
we can do much better (in an area that needs to be as good as we
can make it).
ResizablePMCArray is probably even farther afield, since the things
being stored aren't at all PMCs.
Not all of them, anyway.
But truthfully I'm thinking I can eliminate much of the existing
stack_* code altogether. At the moment the stack_* functions are
trying to manage a stack that contains integers, floats, strings,
pmcs, and addresses. I'm thinking that if we eliminate the user_stack
ops, then we just need a stack of addresses, which means we can
rip out a metric ton of existing code.
Pm
Don't forget the other dynamic_env uses for error handling, actions, and
marks. A lot of simplification would indeed be possible, but even then
it would not be "just a stack of addresses."
There is another solution that ought to speed up "bsr" dramatically:
Give the "bsr" return addresses their own stack. Currently, it is only
possible to "ret" to an address in the same context, so we could add a
stack to the Parrot_Context structure, and the first "bsr" in a given
context could create a dedicated array to use as a stack. The addresses
all point into bytecode, so this would not need to be visible to the GC.
The dynamic_env stack can continue to operate as it does now, with
(as Patrick points out) much simplification in the underlying support
code. Most dynamic_env operations are relatively infrequent, so
performance tuning is not critical there.
The fly in the ointment is that continuations also need to capture
the TOS of the to_context. That's comparatively easy, but has the same
slot-overwriting issue as an arraylike dynamic_env would. We could
finesse this by saying that "Continuations do not restore bsr/ret
state," but that may be unpalatable. On the other hand, the speedup may
be worth it.
(FWIW, this idea had been mooted before, though I forget when. But
it was not pursued because it wasn't believed to be of much benefit.)
-- Bob Rogers
http://rgrjr.dyndns.org/
