Hi, I'm new to language and games.
Many people say that GC is bad and can slow down your project in some moments.
What can happen if I create a game using D without worrying with memory management?
(using full GC)

On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
> Hi, I'm new to language and games.
> Many people say that GC is bad and can slow down your project in some moments.
> What can happen if I create a game using D without worrying with memory management?
> (using full GC)

What do you think will happen? Anytime you delegate power to something else what can go wrong? Nothing is perfect.

The GC exists to automate a job. The job it does is not the problem... It does it well. The issue is when it does it. It's like the noisy garbage man coming in as 3AM to get your trash... are you ok with that? Some people are.

On Friday, February 23, 2018 01:54:07 Leonardo via Digitalmars-d-learn wrote:
> Hi, I'm new to language and games.
> Many people say that GC is bad and can slow down your project in
> some moments.
> What can happen if I create a game using D without worrying with
> memory management?
> (using full GC)

The GC won't slow down your code in general (in fact, it will probably speed it up in comparison to reference counting), but whenever the GC does a collection, that means that it stops all threads that it manages. So, you could suddenly have everything stop for 100ms (the actual length of a collection is going to depend on how much memory the GC has to scan, and I don't know what the typical length of a collection is; that will depend on the program). For programs that can afford to occasionally stop like that, that's not a problem. For a game that's trying to maintain 60fps, that's likely a really big deal.

There are a number of ways to handle it, though the biggest is to simply minimize how much you allocate on the GC heap and how much memory has to be scanned for pointers that refer to GC-allocated memory. Other stuff includes disabling the GC while critical pieces of code are running and having critical threads not be managed by the GC or use GC-allocated memory.

I would suggest that you read this series of articles on the official D blog:

https://dlang.org/blog/the-gc-series/

- Jonathan M Davis

On Friday, 23 February 2018 at 02:02:12 UTC, StickYourLeftFootIn wrote:
> On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
>> Hi, I'm new to language and games.
>> Many people say that GC is bad and can slow down your project in some moments.
>> What can happen if I create a game using D without worrying with memory management?
>> (using full GC)
>
> What do you think will happen? Anytime you delegate power to something else what can go wrong? Nothing is perfect.
>
> The GC exists to automate a job. The job it does is not the problem... It does it well. The issue is when it does it. It's like the noisy garbage man coming in as 3AM to get your trash... are you ok with that? Some people are.

I understand, I'm not saying GC is bad, but I want to know if it would be slow to the point of being noticeable in a game. If so, what is the best way to do this? Placing @nogc everywhere? Thanks.

On Friday, 23 February 2018 at 02:16:38 UTC, Jonathan M Davis wrote:
> The GC won't slow down your code in general (in fact, it will probably speed it up in comparison to reference counting), but whenever the GC does a collection, that means that it stops all threads that it manages. So, you could suddenly have everything stop for 100ms (the actual length of a collection is going to depend on how much memory the GC has to scan, and I don't know what the typical length of a collection is; that will depend on the program). For programs that can afford to occasionally stop like that, that's not a problem. For a game that's trying to maintain 60fps, that's likely a really big deal.

> - Jonathan M Davis

That's what I thought for a game, but probably no one tested yet to see the impact. Thanks, I'll read on.

On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
> What can happen if I create a game using D without worrying with memory management?
> (using full GC)

It depends what kind of game it is and how sloppy your code is in general.

Every game I have written in D i don't think about it, and it is fine. But I also prefer to do simpler games (think 80's or 90's style more than the modern stuff) anyway.

On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
> Hi, I'm new to language and games.
> Many people say that GC is bad and can slow down your project in some moments.
> What can happen if I create a game using D without worrying with memory management?
> (using full GC)

Don't let the GC prevent you from writing a game in D.  D is the most flexible language I have ever used; you just need to learn how to deal with the GC in your game.

Jonathan M. Davis gave you some good advice and explained the fundamental problem with the GC in real time games (the potential for pauses during reclamation).  You can avoid that in a number of ways like temporarily disabling the GC during the real-time part of your game, just to name one.  More can be found in the resources below.

https://wiki.dlang.org/Memory_Management
http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread

automem (https://github.com/atilaneves/automem) also gives you reference counting in D (C++ style), if that will work better for your use case.

Mike

On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
> Hi, I'm new to language and games.
> Many people say that GC is bad and can slow down your project in some moments.
> What can happen if I create a game using D without worrying with memory management?
> (using full GC)

Have a look at https://github.com/gecko0307/atrium and see how memory is handled there.

TBH though every game I've written I have not worried about the GC and just code it up. This works fine for 2d games, platformers etc. If it ever does bite you can always schedule the pauses (they are deterministic in the sense a collect will occur on allocation) or do pretty much what every game does in C++/C and allocate in pools.

Cheers,
Norm

On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
> Hi, I'm new to language and games.
> Many people say that GC is bad and can slow down your project in some moments.
> What can happen if I create a game using D without worrying with memory management?
> (using full GC)

Most people who say GC isn't suitable for games are overreacting. D gives you some ways to avoid GC in many cases. People make games in languages like Java, where you can't avoid GC for even the smallest allocations. Especially for 2D games, which just don't have much going on on the screen, you won't be bothered by GC.

Even for 3D, as long as you're not making the next Call of Duty, GC shouldn't be a blocker for you. However, you might want to avoid too many allocations, just as you'd do in any other GC language (and non-GC ones too actually). For example, when doing particle emitters, allocating thousands of particles per frame is a bad idea, you'd rather want to use an object pool pattern ( http://www.gameprogrammingpatterns.com/object-pool.html ) - for example preallocate an array of 1000 particles, and when a particle dies, instead of allocating a new one, just reset the values of the one that died with the new one.

On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:
> What can happen if I create a game using D without worrying with memory management?
> (using full GC)

If you do not worry about memory management at all, it will probably lead to a need to redesign your game. And that's regardless whether you allocate manually, via GC or using reference counting.

You should laways make sure you do not have to continuously allocate in a tight loop. By tight I mean somthing thats executed hundreds or thousands of times per second. I do not mean that you should not allocate there, but make sure you can easily move the allocation out such a loop if necessary.

GC is most likely a good option, as others have said. It does use more memory than RC or manual management, and leads to short pauses, but is almost as fast as manual management on average. You can:

1: Time the garbage collecions manually so that they happen when responsiveness isn't important.  It's likely something like 100ms so even a short such moment will do. For example, when a racing car comes to stop or gets airborne, so that input wouldn't matter anyway.

2: If you have long intervals without such pauses, you can recycle the all the memory you have freed to make sure the program does not accumulate so much that it needs to collect. This is hard, so I recommend it only if 1. isn't feasible or you want to challege yourself.

If neither of these are possible, or you think your game will be at limits of the RAM capacity no matter the optimizations (shouldn't happen for an indie game), then you should consider avoiding garbage collection from get-go.