PCC reordering idea (and probably branch)

Luben Karavelov karavelov at spnet.net
Thu Mar 15 12:15:31 UTC 2012


 On Thu, 15 Mar 2012 21:17:08 +1100, Vasily Chekalkin <bacek at bacek.com> 
 wrote:
> Hello.
>
> I have some idea about reordering of how PCC works with CallContexts.
> At the moment CallContext created by Parrot_pcc_build_signature on
> caller side and stored inside current CallContext. This is most
> unnatural way of calling Subs and lead as to quite few issues:
>
> 1. We don't always need fresh CallContext on callee side. For example
> C functions/methods doesn't have to have any.
> 2. Corollary of 1 is increased pressure on GC.
> 3. Corollary of 1 that Sub PMC (and inherited PMCs such as Coroutine,
> Continuation, etc) can create CallContext and storage for registers 
> in
> single call. Which is "suboptimal" (i.e. crappy slow).
>
> I want to change it other way around:
> 1. Caller fills params in current CallContext.
> 2. Callee creates new CallContext (if needed).
> 3. Callee unpacks params from parent CallContext.
>
> After implementing this we can optimize CallContext creation to
> allocate storage for registers in single call.
>
> All of this should give us
> 1. Some small performance boost (about 5% I think).
> 2. Will definitely speed up C METHODs calls. Which will help with
> something like 6model.
> 3. But most important will make PCC much more sensible in terms of
> allocating stuff. Which lead us to various optimizations like "Scheme
> style" CallContext stack allocations with trivial bump pointer
> allocation and bit of magic for capturing CallContext for
> Continuations
>
> Any comments, objections, volunteers to help with it?

 Right now calling and returning from sub are symmetric - callee fills
 the return values in callContext and jumps to return address. Then the
 caller unpacks return values. How the proposed change would affect
 this?

 Best regards

-- 
 Luben Karavelov


More information about the parrot-dev mailing list