D on next-gen consoles and for game development

Manu turkeyman at gmail.com
Thu May 23 16:34:41 PDT 2013


On 24 May 2013 05:37, Kiith-Sa <kiithsacmp at gmail.com> wrote:

> On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
>
>> While there hasn't been anything official, I think it's a safe bet to say
>> that D is being used for a major title, Remedy's Quantum Break, featured
>> prominently during the announcement of Xbox One. Quantum Break doesn't come
>> out until 2014 so the timeline seems about right (Remedy doesn't appear to
>> work on more than one game at a time from what I can tell).
>>
>>
>> That's pretty huge news.
>>
>>
>> Now I'm wondering what can be done to foster this newly acquired
>> credibility in games.  By far the biggest issue I hear about when it comes
>> to people working on games in D is the garbage collector.  You can work
>> around the GC without too much difficulty as Manu's experience shared in
>> his DConf talk shows but a lot of people new to D don't know how to do
>> that.  We could also use some tools and guides to help people identify and
>> avoid GC use when necessary.
>>
>> @nogc comes to mind (I believe Andrei mentioned it during one of the
>> talks released). [1][2]
>>
>> Johannes Pfau's work in progress -vgc command line option [3] would be
>> another great tool that would help people identify GC allocations.  This or
>> something similar could also be used to document throughout phobos when GC
>> allocations can happen (and help eliminate it where it makes sense to).
>>
>> There was a lot of interesting stuff in Benjamin Thaut's article about GC
>> versus manual memory management in a game [4] and the discussion about it
>> on the forums [5].  A lot of this collective knowledge built up on manual
>> memory management techniques specific to D should probably be formalized
>> and added to the official documentation.  There is a Memory Management [6]
>> page in the documentation but it appears to be rather dated at this point
>> and not particularly applicable to modern D2 (no mention of emplace or
>> scoped and it talks about using delete and scope classes).
>>
>> Game development is one place D can really get a foothold but all too
>> often the GC is held over D's head because people taking their first look
>> at D don't know how to avoid using it and often don't realize you can avoid
>> using it entirely. This is easily the most common issue raised by newcomers
>> to D with a C or C++ background that I see in the #d IRC channel (many of
>> which are interested in game dev but concerned the GC will kill their
>> game's performance).
>>
>>
>> 1: http://d.puremagic.com/issues/**show_bug.cgi?id=5219<http://d.puremagic.com/issues/show_bug.cgi?id=5219>
>> 2: http://wiki.dlang.org/DIP18
>> 3: https://github.com/D-**Programming-Language/dmd/pull/**1886<https://github.com/D-Programming-Language/dmd/pull/1886>
>> 4: http://3d.benjamin-thaut.de/?**p=20#more-20<http://3d.benjamin-thaut.de/?p=20#more-20>
>> 5: http://forum.dlang.org/post/**k27bh7$t7f$1@digitalmars.com<http://forum.dlang.org/post/k27bh7$t7f$1@digitalmars.com>
>> 6: http://dlang.org/memory.html
>>
>
>
> Without official confirmation, I think it's rather early to assume D's
> being used in Quantum Break. D might compile on the new consoles, but
> what about druntime/phobos/etc ?
>
> That said, I support this idea.
>
> When I get time I'll try looking at Phobos if there is some low-hanging
> fruit with regards to GC usage and submit pull requests (I didn't make any
> non-doc contribution to Phobos yet, but I have a general idea of how its
> source looks).
>
> I also think that many people overreact about GC too much. @nogc is
> certainly a good idea, but I think strategically using malloc,
> disabling/reenabling GC, using GC.free and even just using standard GC
> features *while taking care to
> avoid unnecessary allocations* is vastly better than outright removing GC.
>

Just to be clear, while I've hard many have, I've NEVER argued for removing
the GC. I think that's a hallmark of a modern language. I want to use the
GC in games, but it needs to have performance characteristics that are
applicable to realtime and embedded use.
Those are:
1. Can't stop the world.
2. Needs tight controls, enable/disable, and the allocators interface so
alternative memory sources can be used in mane places.
3. Needs to (somehow) run incrementally. I'm happy to budget a few hundred
µs per frame, but not a millisecond every 10 frames, or 1 second every 1000.
    It can have 1-2% of overall frame time each frame, but it can't have
10-100% of random frames here and there. This results in framerate spikes.

The GC its self can be much less efficient than the existing GC if it
want's, it's only important that it can be halted at fine grained
intervals, and that it will eventually complete its collect cycle over the
long-term.
I know that an incremental GC like this is very complex, but I've never
heard of any real experiments, so maybe it's not impossible?

It'd be good to have an easy-to-use way to manually allocate
> classes/structs in Phobos (higher-level than emplace, something close in
> usability to C++ new/delete), preferably with a way to override the
> allocation mechanism (I assume the fabled "allocators" have something to do
> with this? Maybe we'll get them once DNF is released... ... ...)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130524/7b241319/attachment.html>


More information about the Digitalmars-d mailing list