Rakudo *Needs* Register Allocation

Andrew Whitworth wknight8111 at gmail.com
Sun Jun 27 23:33:42 UTC 2010

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

More information about the parrot-dev mailing list