On Sun, Aug 01, 2021 at 08:54:05AM +0000, Kirill via Digitalmars-d wrote:
> It's interesting to hear do you use D's GC? Or do you use your own custom memory management structure?
> 
> How performant is GC?
> 
> The reason I'm asking is I'm planning to dive into 3D game dev with D as a hobby in an attempt to create a game I dreamed of since I was a kid. I'd like to know if GC is worth using at all, or should I go with 100% manual memory management.
[...]

My approach to D's GC is:

(1) Use it by default until it starts showing up as a bottleneck in your
profiler.

(2) When it does show up as a bottleneck, the fix is often simple and yields good benefits. E.g., in one of my projects, after the GC showed up as a bottleneck, I quickly pinpointed the problem to a function in an inner loop that was allocating a new array every iteration.  Fixing that to reuse a previously-allocated array (maybe about 5 lines' change) immediately gave me 20-30% performance boost.  There were a couple of other similar small code changes to reduce GC pressure, and replace some small bits of GC code in inner loops where performance matters the most.

(3) If performance is still not good enough, there are other ways of controlling the GC. In the aforementioned project, for example, after the array optimization I found that GC collections were taking place too often. So I added GC.stop to the start of my program, and scheduled my own calls to GC.collect at a lower frequency, and got about another 20-30% performance improvement.

Overall, I think I got about 50-60% performance improvement just by several small code changes to an essentially GC-centric codebase.  By writing GC code I saved countless days of writing code for manually managing memory (and weeks of pulling out my hair to debug said code). Only in actual hotspots where the GC becomes a hindrance, I spent some focused effort to either optimize GC usage, or replace small parts of the code (in inner loops and other bottlenecks) with manually-managed memory.  Much faster development time than if I had written *everything* to be @nogc.  Most of that effort would have been wasted on code that doesn't even lie in the bottleneck and therefore doesn't actually matter to performance.

tl;dr: don't fear the GC, just use it freely until your profiler has actually identified the GC as the bottleneck. Then strategically optimize those hotspots, optionally replace them with @nogc code, etc., with much less effort than writing your entire application with @nogc.


T

-- 
"Hi." "'Lo."

On 8/3/21 7:34 AM, Steven Schveighoffer wrote:

> Is that repro case doing what you think it is doing? It appears to keep adding more and more larger allocations to the mix.
You didn't reply in the bug thread. ;)

Ali

On 8/3/21 9:31 AM, H. S. Teoh wrote:

> (1) Use it by default until it starts showing up as a bottleneck in your
> profiler.
>
> (2) When it does show up as a bottleneck, [...]

That's engineering! :)

However, dmd's -profile=gc switch seems to have a bug reported by multiple people where one may get a segmentation fault (or was it -profile?). Even though I've seen it as well, it is not clear whether it's my own code causing errors in a destructor.

> Overall, I think I got about 50-60% performance improvement just by
> several small code changes to an essentially GC-centric codebase.

Same here.

One surprising pessimization which I have not mentioned publicly before was with assigning to the .length property of a buffer. Was it supposed to allocate? I had the following function:

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  buffer.length = length;
}

My idea was I would blindly assign and even if the length was reduced, the *capacity* would not change and memory would *not* be allocated by a later assignment.

Unfortunately, that function was causing GC allocations at least with 2.084.1 perhaps in the presence of other slices to the same elements in my program. Changing it to the following more sensible approach reduced the allocations a lot:

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  if (buffer.length < length) {
    buffer.length = length;
  }
}

I can't be sure now whether it was related to the presence of other slices. Possible... Anyway, that quick fix was a huge improvement.

Ali

On 8/3/21 11:18 AM, Steven Schveighoffer wrote:

> In order for a length change to *not* reallocate, you have to call
> `assumeSafeAppend` on that adjusted buffer, to let the runtime know that
> we don't care about any existing data that might be referenced by others.

Makes sense. Yes, I use assumeSafeAppend mostly on function-local-static buffers. (Similarly, Appender.clear() for appenders.)

Ali