A Perspective on D from game industry

[Brian Rogoff via Digitalmars-d]

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.

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