D
Daniel
GSV said:I've got some code sitting here which ought be able to soak up however
many cores I can afford to throw at it - one thread for the display
(rate limited by how fast the user flies &/or the availability of frame
buffers), one for the UI (may be mostly idle), and 1-N threads (1 per
frame) doing the calculation, (allowing as how you may have to dump
future frames if the user decides to scroll sideways). All one process,
although nobody gets to play with anyone else's frame buffer until it is
'done', and there is no interaction between frame<N> and frame <N+1>
during the calculation phase. Actually there isn't any interaction
between each scan line and the next one IIRC, so I could actually toss
1024 cores at =each= frame buffer (but it isn't coded that way).
Chess plays pretty well on multi-CPU systems of course, an I don't see
why an X2 is going to be any different from a two CPU workstation in
that regard - Fritz<n> should be able to handle it right out of the box.
Not that I'm very excited by that, except for analysis - I already can't
beat Fritz on an XP3000+.
Time for a link:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377&p=4
Quoting Tim Sweeny:
"Writing multithreaded software is very hard; it's about as unnatural to
support multithreading in C++ as it was to write object-oriented
software in assembly language. The whole industry is starting to do it
now, but it's pretty clear that a new programming model is needed if
we're going to scale to ever more parallel architectures. I have been
doing a lot of R&D along these lines, but it's going slowly."
I would say Tim Sweeny knows a bit more about game programming than
either of us.