On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
Errr, well, 1ms is about 7% of the frame, that's quite a long
time.
I'd be feeling pretty uneasy about any library that claimed to
want 7% of
the whole game time, and didn't offer any visual/gameplay
benefits...
Maybe if the GC happened to render some sweet water effects, or
perform
some awesome cloth physics or something while it was at it ;)
I'd say 7% is too much for many developers.
I think 2% sacrifice for simplifying memory management would
probably get
through without much argument.
That's ~300µs... a few hundred microseconds seems reasonable.
Maybe a
little more if targeting 30fps.
If it stuck to that strictly, I'd possibly even grant it
permission to stop
the world...
That is kind of biased, as you'll generally win on other aspects.
You don't free anymore, you don't need to count reference (which
can become qui te costly in multithreaded code), etc . . .
Generally, I think what is needed for games is a concurrent GC.
This incurs a memory usage overhead (floating garbage), and a tax
on pointers write, but eliminate pause.
That is a easy way to export a part of the load in another
thread, improving concurrency in the application with little
effort.
With real time constraint, a memory overhead is better than a
pause.
One important detail to consider for realtime usage, is that
it's very
unconventional to allocate at runtime at all...
Perhaps a couple of short lived temp buffers each frame, and
the occasional
change in resources as you progress through a world (which are
probably not
allocated in GC memory anyway).
Surely the relatively high temporal consistency of the heap
across cycles
can be leveraged here somehow to help?
That is good because it means not a lot of floating garbage.
