Rakudo *Needs* Register Allocation

[Will Coleda]

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
partcl.


-- 
Will "Coke" Coleda