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
