On Wednesday, 12 January 2022 at 16:17:02 UTC, H. S. Teoh wrote:
> On Wed, Jan 12, 2022 at 03:41:03PM +0000, Adam D Ruppe via Digitalmars-d-announce wrote:
>> On Wednesday, 12 January 2022 at 15:25:37 UTC, H. S. Teoh wrote:
>> > 	However it turns out that unless you are writing a computer
>> > 	game, a high frequency trading system, a web server
>> 
>> Most computer games and web servers use GC too.
> [...]
>
> Depends on what kind of games, I guess. If you're writing a 60fps real-time raytraced 3D FPS running at 2048x1152 resolution, then *perhaps* you might not want a GC killing your framerate every so often.
>
> (But even then, there's always GC.disable and @nogc... so it's not as if you *can't* do it in D. It's more a psychological barrier triggered by the word "GC" than anything else, IMNSHO.)
>
>
> T

Oh there is a psychological barrier for sure. On both sides of the, uh, "argument". I've said this before but I can repeat it again: time it. 4 milliseconds. That's how long a single GC.collect() takes on my machine. That's a quarter of a frame. And that's a dry run. Doesn't matter if you can GC.disable or not, eventually you'll have to collect, so you're paying that cost (more, actually, since that's not going to be a dry run). If you can afford that - you can befriend the GC. If not - GC goes out the window.

In other words, it's only acceptable if you have natural pauses (loading screens, transitions, etc.) with limited resource consumption between them OR if you can afford to e.g. halve your FPS for a while. The alternative is to collect every frame, which means sacrificing a quarter of runtime. No, thanks.

Thing is, "limited resource consumption" means you're preallocating anyway, at which point one has to question why use the GC in the first place. The majority of garbage created per frame can be trivially allocated from an arena and "deallocated" in one `mov` instruction (or a few of them). And things that can't be allocated in an arena, i.e. things with destructors - you *can't* reliably delegate to the GC anyway - which means your persistent state is more likely to be manually managed.

TLDR: it's pointless to lament on irrelevant trivia. Time it! Any counter-arguments from either side are pointless without that.

On Thursday, 13 January 2022 at 10:21:12 UTC, Stanislav Blinov wrote:
> Oh there is a psychological barrier for sure. On both sides of the, uh, "argument". I've said this before but I can repeat it again: time it. 4 milliseconds. That's how long a single GC.collect() takes on my machine. That's a quarter of a frame. And that's a dry run. Doesn't matter if you can GC.disable or not, eventually you'll have to collect, so you're paying that cost (more, actually, since that's not going to be a dry run). If you can afford that - you can befriend the GC. If not - GC goes out the window.
>

But the time it takes depends on the number of threads it has to stop and the amount of live memory of your heap. If it took 4ms regardless of these factors it wouldn't be bad, but that's not how D's GC works... And the language design of D isn't all that friendly to better GC implementation. That is the real problem here, that is why it keeps coming up.

On Wednesday, 12 January 2022 at 02:37:47 UTC, Walter Bright wrote:
> "Why I like D" is on the front page of HackerNews at the moment at number 11.
>
> https://news.ycombinator.com/news

I enjoyed reading the article.

On Thursday, 13 January 2022 at 10:21:12 UTC, Stanislav Blinov wrote:
> On Wednesday, 12 January 2022 at 16:17:02 UTC, H. S. Teoh wrote:
>> [...]
>
> Oh there is a psychological barrier for sure. On both sides of the, uh, "argument". I've said this before but I can repeat it again: time it. 4 milliseconds. That's how long a single GC.collect() takes on my machine. That's a quarter of a frame. And that's a dry run. Doesn't matter if you can GC.disable or not, eventually you'll have to collect, so you're paying that cost (more, actually, since that's not going to be a dry run). If you can afford that - you can befriend the GC. If not - GC goes out the window.
>
> In other words, it's only acceptable if you have natural pauses (loading screens, transitions, etc.) with limited resource consumption between them OR if you can afford to e.g. halve your FPS for a while. The alternative is to collect every frame, which means sacrificing a quarter of runtime. No, thanks.
>
> Thing is, "limited resource consumption" means you're preallocating anyway, at which point one has to question why use the GC in the first place. The majority of garbage created per frame can be trivially allocated from an arena and "deallocated" in one `mov` instruction (or a few of them). And things that can't be allocated in an arena, i.e. things with destructors - you *can't* reliably delegate to the GC anyway - which means your persistent state is more likely to be manually managed.
>
> TLDR: it's pointless to lament on irrelevant trivia. Time it! Any counter-arguments from either side are pointless without that.

You collect it when it matters less, like loading a level, some of them take so long that people even have written mini-games that play during loading scenes, they won't notice a couple of ms more.

Hardly any different from having an arena throw away the whole set of frame data during loading.

Unless we start talking about DirectStorage and similar.

On Thu, Jan 13, 2022 at 10:21:12AM +0000, Stanislav Blinov via Digitalmars-d-announce wrote: [...]
> Oh there is a psychological barrier for sure. On both sides of the, uh, "argument". I've said this before but I can repeat it again: time it. 4 milliseconds. That's how long a single GC.collect() takes on my machine.  That's a quarter of a frame. And that's a dry run. Doesn't matter if you can GC.disable or not, eventually you'll have to collect, so you're paying that cost (more, actually, since that's not going to be a dry run). If you can afford that - you can befriend the GC. If not - GC goes out the window.

?? That was exactly my point. If you can't afford it, you use @nogc. That's what it's there for!

And no, if you don't GC-allocate, you won't eventually have to collect 'cos there'd be nothing to collect. Nobody says you HAVE to use the GC. You use it when it fits your case; when it doesn't, you GC.disable or write @nogc, and manage your own allocations, e.g., with an arena allocator, etc..

Outside of your game loop you can still use GC allocations freely. You just collect before entering the main loop, then GC.disable or just enter @nogc code. You can even use GC memory to pre-allocate your arena allocator buffers, then run your own allocator on top of that. E.g., allocate a 500MB buffer (or however big you need it to be) before the main loop, then inside the main loop a per-frame arena allocator hands out pointers into this buffer. At the end of the frame, reset the pointer. That's a single-instruction collection.  After you exit your main loop, call GC.collect to collect the buffer itself.

This isn't Java where every allocation must come from the GC. D lets you work with raw pointers for a reason.


> In other words, it's only acceptable if you have natural pauses (loading screens, transitions, etc.) with limited resource consumption between them OR if you can afford to e.g. halve your FPS for a while. The alternative is to collect every frame, which means sacrificing a quarter of runtime. No, thanks.

Nobody says you HAVE to use the GC in your main loop.


> Thing is, "limited resource consumption" means you're preallocating anyway, at which point one has to question why use the GC in the first place.

You don't have to use the GC. You can malloc your preallocated buffers. Or GC-allocate them but call GC.disable before entering your main loop.


> The majority of garbage created per frame can be trivially
> allocated from an arena and "deallocated" in one `mov` instruction (or
> a few of them). And things that can't be allocated in an arena, i.e.
> things with destructors - you *can't* reliably delegate to the GC
> anyway - which means your persistent state is more likely to be
> manually managed.
[...]

Of course. So don't use the GC for those things. That's all. The GC is still useful for things outside the main loop, e.g., setup code, loading resources in between levels, etc..  The good thing about D is that you *can* make this choice.  It's not like Java where you're forced to use the GC whether you like it or not.  There's no reason to clamor to *remove* the GC from D, like some appear to be arguing for.


T

-- 
The only difference between male factor and malefactor is just a little emptiness inside.