manual memory management

[Benjamin Thaut]

Am 08.01.2013 16:25, schrieb H. S. Teoh:
> On Tue, Jan 08, 2013 at 10:29:26AM +0100, Paulo Pinto wrote:
>> On Monday, 7 January 2013 at 23:13:13 UTC, H. S. Teoh wrote:
>>> ...
>>>
>>> Crippling the language to cater to the 10% crowd who want to squeeze
>>> every last drop of performance from the hardware is the wrong
>>> approach IMO.
> [...]
>> Agreed.
>>
>> Having used GC languages for the last decade, I think the cases
>> where manual memory management is really required are very few.
>>
>> Even if one is forced to do manual memory management over GC, it is
>> still better to have the GC around than do everything manually.
>
> Yes, hence my idea of splitting up the performance-critical core of a
> game engine vs. the higher-level application stuff (like scripting,
> etc.) that aren't as performance-critical. The latter would be greatly
> helped by a GC -- it makes it easier for scripting people to use,
> whereas writing GC-less code demands a certain level of rigor and
> certainly requires more effort and care than is necessary for the most
> part.
>
>
>> But this is based on my experience doing business applications,
>> desktop and server side or services/daemons.
> [...]
>
> Well, business applications and server-side stuff (I assume it's
> web-based stuff) are exactly the kind of applications that benefit the
> most from a GC. In my mind, they are just modern incarnations of batch
> processing applications, where instant response isn't critical, and so
> the occasional GC pause is acceptable and, indeed, mostly unnoticeable.
>
> Game engines, OTOH, are a step away from hard real-time applications,
> where pause-the-world GCs are unacceptable. While it isn't fatal for a
> game engine to pause every now and then, it is very noticeable, and
> detrimental to the players' experience, so game devs generally shy away
> from anything that needs to pause the world. For real-time apps, though,
> it's not only noticeable, it can mean the difference between life and
> death (e.g., in controllers for medical equipment -- pausing for 1/2
> seconds while the GC runs can mean that the laser burns off stuff that
> shouldn't be burned off the patient's body).
>
> But then again, considering the bulk of all software being written
> today, how much code is actually mission-critical real-time apps or game
> engine cores? I suspect real-time apps are <5% of all software, and
> while games are a rapidly growing market, I daresay less than 30-40% of
> game code actually needs to be pauseless (mainly just video-rendering
> code -- code that handles monster AI, for example, wouldn't fail
> horribly if it had to take a few extra frames to decide what to do next
> -- in fact, it may even be more realistic that way). Which, in my
> estimation, probably doesn't account for more than 10% of all software
> out there. The bulk of software being written today don't really need to
> be GC-less.
>
>
> T
>

So how much experience do you have with game engine programming to make 
such statements?

Kind Regards
Benjamin Thaut