Re: More recent work on GC
On Wed, Jan 14, 2015 at 08:07:37PM +, deadalnix via Digitalmars-d wrote: On Wednesday, 14 January 2015 at 18:01:22 UTC, H. S. Teoh via Digitalmars-d wrote: Recently in one of my projects I found that I can gain a huge performance improvement just by calling GC.disable() at the beginning of the program and never calling GC.enable() again, but instead manually calling GC.collect() at strategic points in the code. Obviously, YMMV, but I managed to get a 40% performance improvement, which is pretty big for such a relatively simple change. Interesting that you need to disable to get the effect. That mean our heuristic for the GC collection to kick in sucks quite badly. Well, I'm not sure what the real cause is, but what happened was that I was working on optimizing performance, and gprof indicated that a lot of time was spent in the GC collection cycle. That led me to a lot of needless GC allocations that, after I eliminated them, netted me a huge performance boost. However, I noticed that there was still a lot of time spent in the GC collection cycle -- less than before, but still a big chunk of my running times. So as an experiment I decided to turn off the GC completely to see what happens -- found that running times improved by 40-50%, which is pretty huge! Of course, that also meant I was leaking memory and the program was soaking up too much RAM, so the second thought I had was to still run the GC collection cycles, but at a much reduced frequency. This is specific to my program's memory usage patterns (an ever-increasing amount of allocations that remain live until the end of the program, plus a comparatively much smaller number of temporary allocations that need to get cleaned up every now and then to keep total memory use under control); I'm not sure how generally applicable it is. In my particular case, one of the major factors in poor GC performance was the increasing bulk of allocations that are known to remain live until the end of the program, that the GC must scan every collection cycle because it doesn't know that most of them are going to remain live for a long time. Consequently, collection cycles become slower and slower as the program progresses, with most of the work being unnecessary since the growing bulk of allocations aren't going away anytime soon. This problem would be instantly solved by a generational GC, since after a few cycles most of the bulk of the long-lived allocations will get pushed to the oldest generations and the young collection cycles won't be bogged down scanning them unnecessarily. I'm not holding my breath for D to get a generational GC, though. :-P Alternatively, since I already know exactly which allocations are going to persist until the end, I could just use malloc instead. However this is a bit annoying to implement since these allocations are coming from a (very large) AA that I'm adding stuff to (nothing is ever removed). But since I'm already working on replacing this AA with something else with better cache-friendliness (and also disk-cacheability to transcend current memory limitations), there's no point trying to improve AA performance at this time. T -- Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson
Re: More recent work on GC
On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/immix-pldi-2008.pdf (this has been mentioned before) Andrei These are probably worth re-mentioning since the 2014 paper builds upon them: http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf They've been mentioned here before.
Re: More recent work on GC
On Wednesday, 14 January 2015 at 18:01:22 UTC, H. S. Teoh via Digitalmars-d wrote: Recently in one of my projects I found that I can gain a huge performance improvement just by calling GC.disable() at the beginning of the program and never calling GC.enable() again, but instead manually calling GC.collect() at strategic points in the code. Obviously, YMMV, but I managed to get a 40% performance improvement, which is pretty big for such a relatively simple change. Interesting that you need to disable to get the effect. That mean our heuristic for the GC collection to kick in sucks quite badly.
Re: More recent work on GC
On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf Interesting. non-exact GC but with about the same performance. The bad part for D would be, that this GC collects periodically, so even if you don't use GC'ed memory it will be invoked :-/ On the other hand it stops the world more often, but only for much shorter time - at least in interactive programms a better choice I think.
Re: More recent work on GC
On Wed, Jan 14, 2015 at 05:37:41PM +, John Colvin via Digitalmars-d wrote: On Wednesday, 14 January 2015 at 16:09:06 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf Fascinating! This paper seems to be describing a *partially* compacting/copying GC. That's a very clever way of circumventing the constraints imposed by a conservative GC, which D can't around with due to interfacing with C. IOW, if a D program just so happens to have no unambiguous references, then the GC will effectively become a fully compacting/copying GC. If there are some ambiguous references, then it gracefully degrades into a non-compacting/copying conservative GC. Looking forward to see what will come of this! Interesting. non-exact GC but with about the same performance. The bad part for D would be, that this GC collects periodically, so even if you don't use GC'ed memory it will be invoked :-/ You could still GC.disable(); /* realtime work here */ GC.enable(); of course Recently in one of my projects I found that I can gain a huge performance improvement just by calling GC.disable() at the beginning of the program and never calling GC.enable() again, but instead manually calling GC.collect() at strategic points in the code. Obviously, YMMV, but I managed to get a 40% performance improvement, which is pretty big for such a relatively simple change. T -- What do you call optometrist jokes? Vitreous humor.
Re: More recent work on GC
On Wednesday, 14 January 2015 at 16:09:06 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf Interesting. non-exact GC but with about the same performance. The bad part for D would be, that this GC collects periodically, so even if you don't use GC'ed memory it will be invoked :-/ You could still GC.disable(); /* realtime work here */ GC.enable(); of course
Re: More recent work on GC
On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/immix-pldi-2008.pdf (this has been mentioned before) Andrei Thanks for the heads up.
More recent work on GC
On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/immix-pldi-2008.pdf (this has been mentioned before) Andrei
