Rakudo *Needs* Register Allocation
stefanor at cox.net
Sun Jun 27 23:50:18 UTC 2010
On Sun, Jun 27, 2010 at 02:21:17PM -0700, chromatic 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.
A cheap half-way solution would be to add code to PAST::Compiler to null
temporaries when they are no longer needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the parrot-dev