August 04, 2021
On Wed, Aug 04, 2021 at 09:58:58PM +0000, Brian Tiffin via Digitalmars-d wrote:
> On Tuesday, 3 August 2021 at 19:33:27 UTC, Walter Bright wrote:
> > BTW, regardless of what language you use, or use GC or not, there's no way to write a high performance program without being cognizant of its memory consumption patterns.
> Hear, hear.
> There have been others, but this one hit me like lightning.
> I'm now talking to you, and about you to everyone else, Walter.  :)
> I'm still fairly new here.  Does anyone have a Walter's Wisdoms file? Add this one.  An ageless wisdom, well spoken.

Here the ones I've added to my own quotes file:

	I've been around long enough to have seen an endless parade of
	magic new techniques du jour, most of which purport to remove
	the necessity of thought about your programming problem.  In the
	end they wind up contributing one or two pieces to the
	collective wisdom, and fade away in the rearview mirror. --
	Walter Bright

	Making non-nullable pointers is just plugging one hole in a
	cheese grater. -- Walter Bright

Here's a funny one:

	My father told me I wasn't at all afraid of hard work. I could
	lie down right next to it and go to sleep. -- Walter Bright


This is a tpyo.
August 05, 2021
On Wednesday, 4 August 2021 at 22:42:56 UTC, H. S. Teoh wrote:
> Here the ones I've added to my own quotes file:
> [..]

Ok, let's not get too OT here. Subject is still about the GC and if you use it in games for example.

August 14, 2021

On Tuesday, 3 August 2021 at 14:34:19 UTC, Steven Schveighoffer wrote:


On 8/3/21 5:15 AM, Gregor Mückl wrote:


The D garbage collector seems reasonable for applications with small (object sized) allocations. But that changes when you allocate large blocks of memory: due to a bug internal to the tracking of allocated pages, performance gradually degrades over time. So if you have to allocate large(ish) buffers regularly, it'll show over time. I reported that bug here with a repro case, but it didn't get any attention yet:

I haven't managed to understand thag part of the GC enough to submit a patch myself :(.

Is that repro case doing what you think it is doing? It appears to keep adding more and more larger allocations to the mix.

It seems you are calculating a size variable and never using it.

I think possibly you meant to use size * 1024 * 1024 instead of i * 1024 * 1024.

In regards to the conservative nature of the GC, the larger the blocks get, the more chances they get "accidentally" pointed at by the stack (or some other culprit). 64-bit memory space should alleviate a lot of this, but I think there are still cases where it can pin data unintentionally.


I apologize for not replying earlier. I was very busy with real life stuff since I posted this.

Also, I feel REALLY embarrassed. You are right. I am sorry for wasting time with this. I was 100% certain that my code was right when I opened the bug report and I am sure that I checked it multiple times. But going back to the example program I have locally, it clearly contains this stupid bug.

I fixed the allocation size as you said and now I can't reproduce the behavior I remember. I've checked several dmd builds between 2.088 and 2.096 again and it doesn't show.

So the GC is just fine after all - and I've made an idiot of myself. Again.

August 14, 2021

Don't feel bad, we've ALL done something like this!



1 2 3 4 5 6
Next ›   Last »