A Perspective on D from game industry

[Manu via Digitalmars-d]

On 16 June 2014 09:25, Brian Rogoff via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Sunday, 15 June 2014 at 20:53:58 UTC, w0rp wrote:
>>
>> I'm going to try my hand at making a game with 2.066, because I believe
>> @nogc is a final piece in a puzzle of making doing that easy. Much like
>> writing bare metal D code without the runtime, I'm going to try my hand at
>> writing D code with the main function marked as @nogc, because I reckon it's
>> going to leave me with a saner set of syntax and semantics than either C or
>> C++ in the end, with none of the drawbracks from the stop the world effect
>> in a game loop.
>
>
> Good luck, I'm sure a lot of people are interested.
>
>
>> Having said that, I do think there's some kind of brain malfunction on the
>> part of games programmers that makes them think "is slow and can't escape
>> from" when they hear "garbage collector"
>
>
> There's a similar brain malfunction on the part of GC advocates that makes
> them think "GC programs are just as performant as non GC'ed programs at no
> cost". (**)
>
> On the Lang.Next panel, Andrei said something like
>
> "For the same payload the garbage collected program uses 3 times as much
> memory"
>
> and researcher Emery Berger writes that
>
> http://people.cs.umass.edu/~emery/plasma/emery/memory-management-studies.html
>
> "... a good GC can match the performance of a good allocator, but it takes
> 5X more space. If physical memory is tight, however, conventional garbage
> collectors suffer an order-of-magnitude performance penalty."
>
> That's not even taking into account the non-determinism of tracing GC or the
> issues of finalizers vs destructors or ...
>
> Being able to turn off GC, and having the libraries not hit the GC, are all
> important.

Thank you. I was very worried I was about to start another holy war
responding to that post ;)


>> and "makes things more complicated and slower" when they hear "template."
>> Neither of these things are true.
>
>
> D metaprogramming is a winning feature. But GC has a number of costs as well
> as a number of benefits.
>
> (**) I much prefer working in a GC'ed language with high level features that
> require a GC (full closures!) but if resources are tight I think you need to
> give up some pleasant features.

Closures are so few and infrequent, they could trivially be ARC
allocated, and the language dependence on GC would be meaningfully
reduced.