manual memory management

[Benjamin Thaut]

Am 08.01.2013 16:46, schrieb H. S. Teoh:
>> So how much experience do you have with game engine programming to
>> make such statements?
> [...]
>
> Not much, I'll admit. So maybe I'm just totally off here. But the last
> two sentences weren't specific to game code, I was just making a
> statement about software in general. (It would be a gross
> misrepresentation to claim that only 10% of a game is performance
> critical!)
>
>
> T
>

So to give a little background about me. I'm currently doing my masters 
degree in informatics which is focused on media related programming. 
(E.g. games, applications with other visual output, mobile apps, etc).

Besides my studies I'm working at Havok, the biggest middle ware company 
in the gaming industry. I'm working there since about a year. I also 
have some contacts to people working at Crytek.

My impression so far: No one who is writing a tripple A gaming title or 
engine is only remotly interested in using a GC. Game engine programmers 
almost do anything to get better performance on a certain plattform. 
There are really elaborate taks beeing done just to get 1% more 
performance. And because of that, a GC is the very first thing every 
serious game engine programmer will kick. You have to keep in mind that 
most games run at 30 FPS. That means you only have 33 ms to do 
everything. Rendering, simulating physics, doing the game logic, 
handling network input, playing sounds, streaming data, and so on.
Some games even try to get 60 FPS which makes it even harder as you only 
have 16 ms to compute everything. Everything is performance critical if 
you try to achive that.

I also know that Crytek used Lua for game scripting in Crysis 1. It was 
one of the reasons they never managed to get it onto the Consoles (ps3, 
xbox 360). In Crysis 2 they removed all the lua game logic and wrote 
everything in C++ to get better performance.

Doing pooling with a GC enabled, still wastes a lot of time. Because 
when pooling is used almost all data will survive a collection anyway 
(because most of it is in pools). So when the GC runs, most of the work 
it does is wasted, because its running over instances that are going to 
survive anyway. Pooling is just another way of manual memory management 
and I don't find this a valid argument for using a GC.

Also my own little test case (a game I wrote for university) has shown 
that I get a 300% improvement by not using a GC. At the beginning when I 
wrote the game I was convinced that one could make a game work when 
using a GC with only a little performance impact (10%-5%). I already 
heavily optimized the game with some background knowdelge about how the 
GC works. I even did some manual memory mangement for memory blocks that 
were garantueed to not contain any pointers to GC data.
Despite all this I got a 300% performance improvement after swichting to 
pure manual memory management and removing the GC from druntime.

When D wants to get into the gaming space, there has to be a GC free 
option. Otherwise D will not even be considered when programming 
languages are evaluated.

Kind Regards
Benjamin Thaut