What's the go with the GC these days?
Radu
void at null.pt
Mon Jan 7 08:10:24 UTC 2019
On Saturday, 5 January 2019 at 22:05:19 UTC, Manu wrote:
> I'm somewhere between a light GC user and a @nogc user, and I
> don't really know much about where we're at, or much about
> start-of-the-art GC in general.
>
> I read comments like this:
> https://www.reddit.com/r/programming/comments/acsg61/version_20840_of_dmd_the_d_reference_compiler_has/edbhgzi
>
> """
> And so we do nothing and D continues to languish as every
> thread is
> filled with discussion about a poor implementation of a sorely
> outdated GC? Other languages in this domain get by just fine -
> Go and
> Nim to name some off the top of my head (with the full
> disclosure that
> the former isn't quite D performance and Nim uses a
> thread-local GC).
> There are C / C++ libraries that provide a better GC. D's
> tradeoff is
> basically having one of the worst GCs of any language I've used
> this
> century to avoid a write barrier that causes a, what, 5%
> nigh-deterministic overall reduction in performance (assuming
> we use
> fast barriers out of a cycle).
>
> And if a reasonably performant GC is fundamentally incompatible
> and
> you think it will always be this way, then maybe D as a
> language needs
> to make serious re-evaluations? D keeps saying "Don't Fear the
> Reaper", but D is one of the only languages where I actually do.
> """
>
> How much truth is in here?
> What is this business about write barriers making the GC fast?
> Is that
> actually fact, or are there other hurdles?
>
> Is the claim that write-barriers generally slow your runtime
> performance significant? And if it is, is it
> possible/reasonable to
> control the places where they are emit?
> Can @nogc be used to inhibit write barriers in code that we know
> doesn't interact with the GC, such that we have control over
> that loss
> of perf?
>
> It's obvious that the quality of the GC implementation is a
> mental barrier to entry for many... and D has a GC, which is
> *attractive* to some users. Despite the fact that I don't care
> about the GC much personally, we do need to care about this as
> a group, and nobody seems to be making substantial progress.
>
> Is progress possible, or is the hard reality that the language
> is just designed such to be resistant to a quality GC, while
> the ecosystem sadly tends to rely on it?
>
> Where's the ARC stuff? What happened to opAddRef/opRelease?
There is this article [1] which covers some of the details and
opportunities to get the D GC in a better shape.
For a while improvements on GC front were slow, I see that lately
Rainer has submitted some PRs [2] for getting various GC issues
sorted. My favorite one is the new precise GC [3].
I think a big improvement would be the use of thread local heaps
and GC. But this requires a rethink of `shared`, which would be
nice to be done anyhow.
1 -
https://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
2 -
https://github.com/dlang/druntime/commits?author=rainers&since=2018-12-1&until=2019-01-07
3 - https://github.com/dlang/druntime/pull/2418
More information about the Digitalmars-d
mailing list