What's the go with the GC these days?

H. S. Teoh hsteoh at quickfur.ath.cx
Sun Jan 6 05:58:27 UTC 2019


On Sat, Jan 05, 2019 at 08:38:34PM -0700, Jonathan M Davis via Digitalmars-d wrote:
[...]
> But that doesn't mean that D's GC can't be improved. Work has been
> done on that - e.g. Martin Nowak was going to do a talk at dconf 2015
> about the improvements to the GC that he had done, but he missed his
> plane, so we unfortunately didn't get to hear that talk. Other work
> has been done towards GC improvements, some of which has been merged,
> and some of which hasn't.  For instance, IIRC, Rainer made
> improvements to how precise the GC was a year or two back (though I
> don't think that it's yet fully precise, and I don't know how possible
> it is make it fully precise). Also, destructors now get called for
> structs on the heap in many cases, whereas before, that pretty much
> never happened.

Yeah, glancing over druntime's git history, it appears that since around
May last year, there's been a slow but steady trickle of fixes /
improvements committed to the GC.  So work *is* happening, just perhaps
not at the rate people might want, but the GC *has* improved over the
years.


> Other work has been done towards more radical changes to the GC,
> though I don't think that any of that has made it in (e.g. the forking
> GC that Sociomantic worked on which significantly reduced how long the
> world got stopped - but AFAIK, no one has yet figured out how to make
> that work on Windows, so none of that work has made it into druntime).

I wonder if we could just make that forking GC a plugin available on
Linux / Posix?  IIRC improvements have been made over recent years to
better encapsulate the GC API, so drop-in replacements should be
possible, at least in theory.

OTOH, the last time I heard about it the codebase of the forking GC was
too tied down to the (very) old version of druntime it was originally
based on, and it may have been Tango-specific as well, so a lot of work
would have to be put it to make it work with the modern druntime.  As
long as nobody is willing to put in the effort, nothing will
materialize.


[...]
> And really, for the most part, it's just folks saying that the GC is a
> problem without any real evidence to back it up, whereas there are a
> number of cases of folks in this newsgroup talking about how they used
> the GC for stuff that was highly performance sensitive, and all they
> had to do was avoid having it be used in some particular piece of code
> in order to make it so that their programs were quite performant.

Indeed.  One particular project of mine -- which may be an atypical
workload, depending on what you usually work with -- involves a
batch-processing of an extremely CPU-intensive computation which stores
data in an AA that grows to very large sizes, along with a couple of
arrays and other simple structures.  To maximize throughput, I used a
profiler.  After optimizing the few hotspots that were found, I started
seeing GC collection cycles show up at the top of the profiler output,
so I set about investigating what could be done to improve it.

After some experiments, I found that collections were taking place
frequently, and took a long time each time.  Since the AA only ever grew
(nothing gets deleted from it), frequent collections were not really
necessary, so settled on the simple strategy of calling GC.disable at
the beginning of the program, and scheduling GC.collect calls myself at
a lower frequency.  I managed to cut total running times by about 40-50%
just by tweaking the frequency of the collection cycles.

Then after that, closer investigation revealed a very frequent
reallocation of a small array inside an inner loop, which was causing a
lot of GC pressure.  Refactoring the code to reuse previous arrays where
possible, I reduced GC pressure sufficiently that I could scale back the
collection cycle frequency even more -- I managed to reduce total
running time by about another 10-20% or so.

These are all rather simple, localized code changes -- I'm quite certain
even more improvements can be made were I to spend the time to refactor
the code more.


[...]
> But for the most part, what we have to go on is just anecdotal
> evidence. There isn't much in the way of actual performance
> comparisons with the GC (at least not that get made public), and it's
> just a common assumption that D's GC is bad and hurts performance. How
> true that really is in practice is an open question.
[...]

Well, then what about doing some actual measurements with a well-known D
codebase?  Let's get an actual profiling of GC performance of an actual
project and see how the numbers look.  Maybe compare it with equivalent
Java code or something with a known "advanced" GC.  Or compare against
different workloads to see how the GC does.

Then post the results on the wiki or something, with concrete
measurements that we can point people to when they complain about the
GC.


T

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. -- Brian W. Kernighan


More information about the Digitalmars-d mailing list