At 8:33 PM +0100 3/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 7:00 PM +0100 3/22/04, Leopold Toetsch wrote:

 D'oh! (I should edit this all out but, well...) If we go with a one
 frame stack chunk then we don't have to bother with COW-ing
 *anything* with the stack. Which makes the differentiation between a
 return continuation and a regular continuation irrelevant, as they'd
 be identical.

Ok. BTW:


$ parrot tools/dev/bench_op.imc --times=1000000  'new P10, .PerlInt'
Time for 1M ins: 0.314813

$ parrot tools/dev/bench_op.imc --times=1000000  'new P10, .RetContinuation'
Time for 1M ins: 1.679647

Wow. Not a bad difference at all. (Yes, I know, factor of five, but there's a good chunk of memcopying going on there too :)


I estimate a special Fat Continuation PMC at around 1 sec per Meg.

So avoiding the creation of (Ret)?Continuations at all is still a very
valuable goal IMHO.

Sure, it's a great goal. I'm just not sure it's a feasable one. The other constraints on the system make it dodgy to go reuse these things. Lets first see where a separate continuation pool takes us and we can go from there.


>>What about other sub PMCs: Sub, Closure, Coroutine, Exception_Handler?

 Dunno if they're allocated often enough to warrant any extra work.
 Maybe exception handlers.

Exception handlers are derived from Continuations. All these share some code - not much though.

Let's worry about them later. For now, we'll concentrate on continuations, and look into the rest after that.
--
Dan


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to