On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:
They're not acceptable for a systems programming language as
they require you to pay for something that you might not use.
According to our resident GC maintainer (among many other
things), they would cause a 1%-5% slow down in the language:
https://github.com/dlang/druntime/pull/1081#issuecomment-69151660
Well I’m not sure about the 5% (MS says their write barrier
overhead is comparable to the cost of a simple method call,
namely 6.4ns:
https://msdn.microsoft.com/en-us/library/ms973852.aspx), but
yeah, there’s some tradeoff, for having a good GC.
By the way, Go implemented those barriers in version 1.5 a year
ago: https://blog.golang.org/go15gc
May I point out that you do not seem to have any kind of
experience
of D's GC? Try it and see for yourself wether it actually stops
you
or not. It's right that not everyone is pleased with the current
GC
but those users have specific expectations and I'm not certain at
all that they would find C# or Go's GC acceptable either.
The point is, D doesn't have to have a GC. Not using it is way
easier
than in most other languages because all the tools to help you
profile it and avoid it are provided by the compiler. Go without a
good GC is a dead language. D without a good GC is just not as
good
as it could be. And btw we're generally faster than Go ;-)
The point is: while a better GC is a work in progress we'll
*never*
have a GC that can fit all needs, but it's not as critical as it
is
in Go or in C# because we provide other ways to manage memory when
limitations arise.
