Rakudo *Needs* Register Allocation

Will Coleda will at coleda.com
Mon Jun 28 01:33:50 UTC 2010

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

Note that doing it in POST means that anyone NOT using POST doesn't
get this benefit, which I think includes winxed, lua, and old-school

Will "Coke" Coleda

More information about the parrot-dev mailing list