manual memory management

deadalnix deadalnix at gmail.com
Wed Jan 9 02:31:50 PST 2013


On Wednesday, 9 January 2013 at 10:19:24 UTC, Mehrdad wrote:
> Yes I did, but I didn't realize you were talking about a 
> background GC, sorry.
>
> Yeah, if you can have a background GC that can keep up with 
> your needs, then the world is great. Trouble is, I don't see 
> how that can be true for a intensive applications like games.

You are changing the subject discussed every 2 posts. I'm loosing 
my time here, that will be my last answer to you.

For a game, latency is more important than actual performance. 
You prefers very much to guarantee 60fps than to have 100fps but 
with some frame that may take 200ms to compute.

At this game, stop the world GC and reference counting are very 
bad as both causes large pauses.

A concurrent GC is a viable option, granteed you don't generate 
an insane amount of garbage (which is problematic whatever the 
memory management used anyway). It is even a good way to increase 
parralelism in the program and to better exploit the resource of 
a multicore machine.

In fact, most code critical in video games avoid memory 
allocation altogether.


More information about the Digitalmars-d mailing list