manual memory management

[Paulo Pinto]

Am 08.01.2013 17:12, schrieb 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
>

Without dismissing your experience in game development, I think that 
your experience was spoiled by D's GC quality.

After all, there are Java VMs driving missiles and ship battle systems, 
which have even higher timer requirements.

--
Paulo