From: Josef W. <jw...@ra...> - 2014-03-11 09:31:11
|
On Tue, Mar 11, 2014 at 09:54:02AM +0200, Nikodemus Siivola wrote: > Other ways of keeping GC in check: > - Use DYNAMIC-EXTENT a lot -- ie. stack allocate. With appropriate > declarations SBCL can stack allocate pretty much any closure, vector, > cons, or structure-object you care to create. (Still, sometimes > surprisingly simple things can prevent it (mostly due to the compiler > still not being sufficiently smart), which is why code that really > relies on stack allocation happening should have unit tests that > verify that.) Hmm, I'd rather use dynamic storage only when it makes sense semantically. > - Use unboxed storage: pack your data into eg. vectors of > unsigned-byte 8 or 32. Then even when you heap-allocate unboxed data > causes *way* less GC pressure. (Less to scavenge.) Well, I actually use (make-array size :element-type '(unsigned-byte 8))) and DISPLACED-TO for the bulk data. But I don't want to do too much optimizations of this type in this early stage of the project. > - Avoid dirtying old objects with pointers in them. It may be more > efficient re. GC to cons up a whole new structure than to modify a > slot in an old one as there are less dirty old pages to scavenge. > Sure, if you need to change a slot all the time, then it is probably > not feasible. Can you elaborate on this? I don't really get what you are trying to say here. > - ...which brings us to the worst trick of them all. If you have say > 10M objects that are going to be subject to intense allocation > intensive algorithm, but aside from object identities everything could > live in unboxed storage? Have a large vector of those objects, and > refer to them by index instead of identity (fetching the real object > when necessary) -- ie. take a loan of storage and indirection to pay > off the GC cost of scavenging lots and lots of stuff. If I understand this suggestion correctly, then I have already done this type of optimization in the C implementation. The storage (once allocated) would never be freed. Instead the data structures were reused. So after an initial phase, the storage can be assumed to be static. The question is, whether the GC (once triggered by some other event) will have to inspect those structures every time it runs? Or is there some sort of optimization to process only structures where the reference counter has be reduced or something like that? -- Josef Wolf jw...@ra... |