Hello. 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.
-- Bacek. On Mon, Jun 28, 2010 at 9:33 AM, Andrew Whitworth <[email protected]> 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 <[email protected]> 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 > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
