On Wednesday, 24 December 2014 at 23:14:53 UTC, Delirious wrote:
On Saturday, 20 December 2014 at 22:11:35 UTC, Xinok wrote:
(2) Furthermore, we need to improve the performance of the
garbage collector.
"Performance" is a complex issue in the case of GCs. There is
not "highest performance GC", only GCs optimally tuned for
certain scenarios. While a simple, imprecise, mark-and-sweep
collector like the one used by D right now is not that
complicated, modern, industrial GCs are very complex.
There are many decisions to be made and there is no single
"right" answer.
A simple philosophy to follow is to "optimize for the common
case". As I stated, I'm not expecting an optimal solution within
the next year, just something that's "good enough". There's lots
of details to work out, but that's not a problem. It's not
uncommon for discussions here to go beyond 200+ posts, so I have
no doubt decisions will be made.
At this point I would like to quote a post about the evolution
of the Go garbage collector because Go originally had a
primitive GC too but is now far head of D's by any standard:
...
All the more reason why this issue needs resolution. D was first
released 13 years ago whereas Go is only five years old and
already has a far superior garbage collector. I know it's to be
expected as Google has billions of dollars at it's disposal, but
all most people see is what they're given.
That's possibly the greatest challenge of D, the fact that it's a
community-developed language. If you can't get the community to
agree on specific goals and deadlines, then people will work on
whatever interests them and it becomes a disorganized mess.
Replacing the GC with a different one is controversial, for
example:
except for very large heaps, it is unclear whether a
generational GC would be faster overall
package "unsafe" makes it hard to implement fully precise
GC and compacting GC
I'm not saying we need to replace the GC altogether, and that's
probably an unrealistic goal to achieve within the next year
anyways. For example, making the GC precise would add a bit of
overhead but it would also benefit by scanning less memory
overall (no need to scan ubyte[] for pointers). Furthermore, if
we stick to the stop-the-world model we have now, there's no
reason we can't implement a concurrent sweep like Go has. ;-)
