Mike Capp wrote:
> Sean Kelly wrote:
> 
>> That sounds like bad program design rather than
>> bad GC design.  Were the app written using
>> conventional allocation it would either be visibly
>> slow or leak like a sieve.
> 
> Probably. And I suspect the codebase we use it on is larger than usual. But then,
> you could offer the same retort to any reported "for real" GC problem.
> 

One thing I've learned during my years with Java is that most "GC problems" are really programmer problems. Such issues can be avoided by "coding to the GC." Unfortunately, this is something that too many developers just don't get. Still there are problems that can't be worked around in obvious ways in code. To eliminate those, Sun goes the extra mile via Java's tools to analyze GC behavior and the command line parameters to fine-tune it, even allowing you to select between several different implementations. That will take care of all but the rare border case.

I've not worked with C# more than in passing, so I don't know what sort of tools or options are available to tune the GC. It would be great to have such capabilities in D. I haven't used D extensively enough to know what "coding to the GC" means for the current implementations, but developers who do understand it should be able to avoid the lion's share of issues.

Mike Parker wrote:
> I haven't used D extensively enough to know what "coding to the GC" means for the current implementations, but developers who do understand it should be able to avoid the lion's share of issues.

FWIW, the worst I've run into with the D GC was by aggressive use of opCat:

uint[] arr;
for(uint i=0; i<65535; i++){
  arr ~= i;
}

Code like this was causing a good amount of memory to be allocated, and then subsequently abandoned - a very small fraction of the heap was actually in use.  After I had some help with the guys out on #D to try and track this down, we found that the internal array allocator that was the culprit.

The "heap bloat" was easily circumvented with a struct that pretends to be an array, and uses a more conservative re-allocation algorithm by way of using a less conservative *pre*-allocation algorithm.  It wasn't rocket-science or anything - anyone who understands what CoW means could hardly call it surprising.

So in short: In my experience, GC issues in D aren't uncommon, but then "coding to the GC" is pretty easy to do with some very rudimentary analysis.  IMO, wise use of smart datatypes, scope() and delete pretty much cover the rest of the places where the GC is too lazy/slow/dumb to do the job. :)

-- 
- EricAnderton at yahoo

On Tue, 21 Nov 2006 10:31:10 +0900, Bill Baxter <dnewsgroup@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.

Steve Horne wrote:
> On Tue, 21 Nov 2006 10:31:10 +0900, Bill Baxter
> <dnewsgroup@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?

It is slow, but the issue is the optimiser in DMD (and also DMC) does very little optimisation of FP code. So at present it's necessary to code inner loops in asm.
(Actually, AFAIK, no compilers are very good at optimising x87 code).

Steve Horne wrote:
> 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).

I haven't done any work in 3d games, but what I hear from every single programmer that has is that they will gladly trade some performance for productivity.

I was so shocked when I browsed the C++ CIV4 SDK, I always thought these professional programmers had a tight and clear codebase for such large applications, well they don't.
But they are on a tight schedule too and it must be a complex ordeal. I image doing something like this in D saves so much time and complexity, that alone might enable developers to implement higher performance applications. For the most annoying problems with performance in the games I play are due to 'bugs' or design-level bottlenecks it seems, and they are usually patched some months after the release - if you're lucky.

== Quote from Lutger (lutger.blijdestijn@gmail.com)'s article
> I was so shocked when I browsed the C++ CIV4 SDK, I always thought these professional programmers had a tight and clear codebase for such large applications, well they don't.

If you meant Civilization IV, then I agree: it performs so badly I can't play it on my old computer or laptop. I think they used Python for game scripting, which is sloooowww.

Lutger wrote:
> I haven't done any work in 3d games, but what I hear from every single programmer that has is that they will gladly trade some performance for productivity.
> 
> I was so shocked when I browsed the C++ CIV4 SDK, I always thought these professional programmers had a tight and clear codebase for such large applications, well they don't.
> But they are on a tight schedule too and it must be a complex ordeal. I image doing something like this in D saves so much time and complexity, that alone might enable developers to implement higher performance applications. For the most annoying problems with performance in the games I play are due to 'bugs' or design-level bottlenecks it seems, and they are usually patched some months after the release - if you're lucky.

With a tight schedule, a good strategy is to not waste time optimizing any one particular thing until you *know* it is a bottleneck.  Game developers tend to be pretty ruthless in applying this principle.  For the Civ4 SDK, something that will only be used directly by a tiny fraction of Civ4 users, there's just not a lot of bottom line justification for putting resources there, when compared to say fixing a crash bug that 10% of players are likely to encounter.

So yeh, that's why folks like the Civ team and the folks behind Eve Online are willing to go with Python.  For most things Python is fast enough, and gets the job done much more quickly than C++.  For the small fracton of the code where it's not fast enough, you can always re-write those bits in C and call it from Python.

--bb

Don Clugston wrote:

> > Is floating point performance in D a problem?
> It is slow, but the issue is the optimiser in DMD (and also DMC) does very little optimisation of FP code. So at present it's necessary to code inner loops in asm.

I don't see why this need be an issue. For the kind of functionality you're talking about it's probably easier to write the math library in C or Fortran and link it in. It's not as if you need D's advanced features to multiply a bunch of floats.

Bill Baxter wrote:
> 
> So yeh, that's why folks like the Civ team and the folks behind Eve Online are willing to go with Python.  For most things Python is fast enough, and gets the job done much more quickly than C++.  For the small fracton of the code where it's not fast enough, you can always re-write those bits in C and call it from Python.

The Civ4 post mortem was an interesting read.  Even the dev team was surprised at what a good choice Python turned out to be.  I think they initially had only planned to write a very small portion of the game in Python and instead ended up writing almost the entire thing in Python.


Sean

Bill Baxter wrote:
 > With a tight schedule, a good strategy is to not waste time optimizing
> any one particular thing until you *know* it is a bottleneck.  Game developers tend to be pretty ruthless in applying this principle.  For the Civ4 SDK, something that will only be used directly by a tiny fraction of Civ4 users, there's just not a lot of bottom line justification for putting resources there, when compared to say fixing a crash bug that 10% of players are likely to encounter.
> 
> So yeh, that's why folks like the Civ team and the folks behind Eve Online are willing to go with Python.  For most things Python is fast enough, and gets the job done much more quickly than C++.  For the small fracton of the code where it's not fast enough, you can always re-write those bits in C and call it from Python.
> 
> --bb

Civilization 4 is structured in roughly 4 layers:
1. core engine build on gamebryo (C++) - closed source
2. core game logic (120K LoC, a C++ DLL) - open source
3. python scripting (game logic, ui, terrain generation, etc.)
4. xml data (static data)

The C++ SDK is layer 2, so this affects all users. I don't know where bottlenecks lie here, but I suspect it is in 1 or 2.

I'm not sure (nobody is as it hasn't happened yet), but I wouldn't be surprised that if these parts of a large game are written in D performance will go up instead of down, even if the D compiler doesn't optimize as well as a good C++ compiler. For this kind of application I can't believe a little slower floating point calculation will matter as much as ease of high level design and maintenance optimizations.