Rakudo *Needs* Register Allocation

Vasily Chekalkin bacek at bacek.com
Sun Jun 27 23:46:47 UTC 2010


For the record. I'm going to replace current POST with PIRATE's POST
"really soon". And PIRATE already has VanillaAllocator which can be
easily replaced with more sophisticated one.


On Mon, Jun 28, 2010 at 9:33 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> Better register allocation will likely lead to some performance
> improvement, if only because each context will need to allocate less
> storage space for contexts. It probably won't be huge though.
> Doing it in IMCC is intractable I think. It's probably okay if basic
> PIR doesn't get too fancy with register allocation, though there's no
> reason why it shouldn't be added in to POST. Do you think it should be
> part of normal POST operation, or added as an optional optimization
> step? I ask because we might want multiple pluggable/selectable
> allocators, and we may want to turn off the fancier ones entirelywhere
> speed is an issue.
> --Andrew Whitworth
> On Sun, Jun 27, 2010 at 5:21 PM, chromatic <chromatic at wgz.org> wrote:
>> Hello C hackers,
>> I added some temporary debugging output to CallContext's mark VTABLE to see
>> what's happening in the GC when Rakudo runs.  Look at src/gen/core.pir in the
>> Rakudo directory, and especially the first PIR function (it's _block67 for me).
>> This function has 1425 PMC registers and 76 STRING registers.
>> Other interesting functions:
>>        105P/0S (!class_init_1134)
>>        120P/0S (!class_init_722)
>>        1448P/0S (-unknown-)
>>        151P/0S (_block27227)
>>        181P/0S (!class_init_1070)
>>        187P/0S (!class_init_1449)
>>        297P/0S (_block13)
>>        301P/0S (_block16799)
>>        324P/0S (_block14638)
>>        395P/0S (_block13)
>> Several other functions have 60+ registers.  While sometimes that's necessary,
>> even eyeball lifetime analysis of _block67 in particular reveals that Parrot
>> could get by with far, far fewer registers.  Very few Rakudo calls use more
>> than a handful of S registers, if any.
>> I won't *guarantee* that there's a huge runtime speed improvement here (though
>> iterating over dozens of registers in mark won't be fast), but we could cut
>> runtime memory use significantly.  As well, if Parrot could reuse registers
>> after lifetime analysis proved that their contents were unused, we might be
>> able to collect more garbage--especially of locally created GCables which
>> won't escape the function.
>> I'm not sure we can save the register allocator in IMCC, nor should we.
>> We may be able to add a register allocation step to POST.
>> Ideas?
>> -- c
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev

More information about the parrot-dev mailing list