On Tue, Dec 1, 2009 at 4:07 PM, chromatic <[email protected]> wrote: > On Tuesday 01 December 2009 at 12:33, chromatic wrote: > >> If ~80% of all PMCs created in the system are only there to account for >> internal data structures for calling functions (and they are), and >> if there's no complex control flow such as continuations and coroutines which >> necessitate keeping sub-graphs of the call graph alive (and in this >> benchmark, there aren't), then I'm very confident that PCC is expensive here. > > For further review, I annotated the GC with printf() calls to track PMC > destruction during GC. The attached log shows how many PMCs of which type get > recycled during every GC run, as well as the percentage of PMCs (Context, > CallSig, RetCallSig, FIA) I believe to be PCC-related. > > At least two out of three PMCs recycled in every run are PCC-related.
Thanks for this, c. It's very informative. So I won't doubt anymore that PCC is expensive! I make a few observations from this: 1) We go through 15 GC runs before we ever find any trash. Suggests to me that we are allocating a lot of things at startup. When we try to allocate a new PMC at startup and there are none in the free list, we first do a GC mark/sweep and then we allocate a new arena. This suggests to me that we need to significantly increase the initialize size of our pools to prevent this. Or else, we need to use heuristics to prevent GC runs from occurring so early in the execution cycle. 2) High number of String PMCs is a little troublesome, and you're probably right that most of those are autoboxed S registered for PCC calls. I think CallSignature needs to be made much more intelligent about this and avoid unnecessary autoboxing. STRINGs do have a flag set in the PObj flags field, so we should be able to lazily box these only when an S is passed and a P is needed. But, the numbers for this are comparatively small. 3) Seems like there are huge gains to be had if we can merge CallSignature/Context/CallSignatureReturns together. I think the VTABLE interface of the resulting PMC will be sufficiently clumsy, though maybe we can reuse the same object and just replace the VTABLE* for it when it's being used in call or return mode. 4) It seems like we are making ~4000-8000 CallSignatures and Contexts between most GC runs, which implies that we're making that many function calls between GC runs. So, I don't think GC is running too often, but when it is running it is very expensive. Of course, there are a comparatively small number of RetContinuation PMCs collected, so it seems the vast majority of expenses come from calling NCI functions. This seems like a case that we should be able to optimize further. I also seem to remember you saying a while back that Capture.mark() was eating up a huge amount of execution time, is this a true recollection? --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
