D on next-gen consoles and for game development

[Manu]

On 25 May 2013 03:55, deadalnix <deadalnix at gmail.com> wrote:

> 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 . . .
>

Freeing is a no-realtime-cost operation, since memory management is usually
scheduled for between-scenes, or passed to other threads.
And I've never heard of a major title that uses smart pointers, and assigns
them around the place at runtime.
I'm accustomed to memory management having a virtually zero cost at runtime.
So I don't think it's biased at all (in the sense you say), I think I'm
being quite reasonable.

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.
>

How much floating garbage? This might be acceptable... I don't know enough
about it.

That is a easy way to export a part of the load in another thread,
> improving concurrency in the application with little effort.
>

Are you saying a concurrent GC would operate exclusively in another thread?
How does it scan the stack of all other threads?

With real time constraint, a memory overhead is better than a pause.


I wouldn't necessarily agree. Depends on the magnitude of each.
What sort of magnitude are we talking?
If you had 64mb of ram, and no virtual memory, would you be happy to
sacrifice 20% of it? 5% of it?

 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.
>

Right. But what's the overhead of a scan process (that's almost entirely
redundant work)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130525/83d75d63/attachment.html>