D on next-gen consoles and for game development

deadalnix deadalnix at gmail.com
Fri May 24 10:55:44 PDT 2013


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.


More information about the Digitalmars-d mailing list