OSNews thread here degenerates into GC vs not

[Steve Horne]

On Tue, 21 Nov 2006 10:31:10 +0900, Bill Baxter
<dnewsgroup at billbaxter.com> wrote:

>Basically I think the kind of games that would need custom memory 
>management with D are probably the same kinds of games that would need 
>it under C/C++ as well.  Poor floating point performance may be a bigger 
>issue for fancy 3D games than GC, when it comes down to it.

Is floating point performance in D a problem?

I realise that most 3D work would probably use single precision
floats, since higher precision would mostly be overkill and slow
things down a bit by increasing the needed memory bandwidth for arrays
of vectors. And of course D tends does all calculations in extended
precision, but that shouldn't be a problem. The FPU takes as long to
multiply two single precision floats as it does to multiply two double
precision floats, etc etc.

The only thing I can think of is failure to exploit SIMD and similar
explicitly parallel instruction sets, but I didn't think that 'just
happened' by standard in existing compilers (barring possibly the
intel one) anyway.

In any case, I thought most games (on Windows, at least) exploited
SIMD etc more-or-less by accident, by using the matrix and vector
operations in DirectX. In fact, there is supposed to be a trend toward
offloading all the viewpoint transformations etc onto the graphics
card anyway.

Of course I'm at the "I've read some books and played with DirectX and
some 3D engines" stage with games programming. That is, I know next to
nothing beyond the theory and what's obvious to anyone whos done some
real time work.

I'm just a bit surprised and curious, is all. If anyone asked me if D
was good for games, I'd have thought first about COM support (for
DirectX) and any possible issues in calling OpenGL, and then I'd have
thought about memory and resource management, and then I'd have
expressed some slight concern that the DMD optimiser is probably less
sophisticated than those in some other compilers, but I'd figure that
the cost from this is probably very small - the important
optimisations are usually design-level optimisations (algorithms and
data structures).

As for memory management, I'd have thought GC would be fine in a game,
provided that objects are only allocated at key points such as when
moving to another level - the same applying to malloc and free. But I
would want a way to trigger a full garbage collection - preferably
with another thread using fully preallocated memory keeping some level
of updates running - once those key points were completed.

That is, you don't want a garbage collection cycle to cause delays
while you're in the middle of a level, but do you care about GC delays
when you're loading the next level? So long as the between-level music
and visuals keep running, probably not. So why not keep the GC
benefits for these non-realtime jobs?

-- 
Remove 'wants' and 'nospam' from e-mail.