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.
