[gameprogrammer] Re: What do the new processors mean for game programming?
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Wed, 2 Mar 2005 04:27:17 +0100
On Wednesday 02 March 2005 03.49, Bob Pendleton wrote:
> On Tue, 2005-03-01 at 22:46 +0000, Robert Chafer wrote:
> > Very interesting question, and not only for games programming. Not
> > only is thread programming poorly understood (generally) and ...
> > difficult.
>
> Yes!
>
> > Also, the multi-core technologies will allow threading
> > models that are really completely different to current ones. The
close
> > coupling of the cores will mean very (very) fast signalling and
> > sharing of information.
>
> Very interesting point. You are correct, due to being on the same
> chip and perhaps sharing a common cache interprocessor signaling
> times will drop to an all time low. Hmmm, what does that mean? I
> think it means that it will be practical to use threads for very
> fine grained tasks.
...provided there isn't a general purpose OS in the way, ruining
everything by trying to enforce "fair sharing", as is usually the
case. :-/
Maybe HT is best left alone on the OS level (no support beyond
saving/restoring state properly; the OS views HT CPUs as single CPUs
with extensions), and provided as an acceleration feature for
applications, pretty much like the various SIMD extensions?
I mean, HT is really just the next step beyond SIMD and deep
pipelining. Deeper, more flexible and potentially more parallel.
If it's intended to boost raw processing power, rather than being a
cheap way to get 1.5 CPUs instead of a real dual CPU SMP box, this
low level "CPU extension" type of view makes more sense. We have
already concluded long ago that SMP is of little use to normal people
(though that is part because of crappy scheduling in widely available
OSes) running normal applications (such as games) - so why does it
seem like we're intended to abuse this new technology to emulate real
SMP?
How about this:
int do_heavy_number_crunching()
{
for(lots of data)
{
/* Grab some data */
...
switch(ht_split(2))
{
case 0:
/* Do some work */
...
break;
case 1:
/* Do some other work */
...
break;
case -1:
/* We don't have that many cores! */
return FAILURE; /* Or do it in one thread... */
}
ht_join();
/* Combine results from the two threads */
...
}
}
Basically sending work off to threads on the function call level,
rather than on the module/engine/daemon level.
With some compiler support, one could have functions execute in
parallel automatically when doing stuff like:
do_stuff(get_data(), get_more_data());
(The get_*data() functions would run in parallel if possible, and
provided they can't interfere.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
