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. > > Ideas?
A cheap half-way solution would be to add code to PAST::Compiler to null temporaries when they are no longer needed. -sorear
signature.asc
Description: Digital signature
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
