[gameprogrammer] Re: What do the new processors mean for game programming?
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Wed, 2 Mar 2005 00:18:36 +0100
On Tuesday 01 March 2005 22.46, Bob Pendleton wrote:
[...]
> It seems to me that most programming languages currently in use have
> little to no built in support for multithreaded programming. Java is
> the only one I can think of.
One problem is that certain mainstream platforms just don't handle=20
threading very well, whether or not there is more than one CPU or=20
core. This causes major trouble when doing any kind of real time=20
processing involving more than one thread.
=46or example, applications using ReWire (a solution for integrating=20
real time audio applications) on Windows almost exclusively use the=20
in-process model, where the real time DSP parts of all applications=20
involved is loaded into and executed in the audio thread of a single=20
application. (Whereas on Linux and Mac OS X, similar solutions work=20
just fine with applications doing their processing in their own=20
processes, using IPC to sync up.)
This seems to have improved a little in the latest versions of XP,=20
though. You still get much higher latencies with multiple processes,=20
but at least, it's usable...
That said, keep in mind that games usually deal with around 100 fps,=20
whereas audio applications are expected to handle around 1000=20
buffers/s. So, if it works *at all* for real time audio, it should=20
work just fine for video, at least in theory.
> Are you folks thinking about how to=20
> make use of multiple processors in your games?
To some extent, but one problem is that most multimedia libs (like=20
SDL) don't support it, and the other, more serious problem is the=20
threading performance issues on some platforms.
I would hate to do all the work to use multiple threads for rendering=20
or something, only to find out that on some platforms, most of the=20
speedup is lost in IPC overhead and fumbled away waiting for data to=20
arrive...
That said, work that doesn't have to be done on a frame-by-frame basis=20
is a completely different matter. Just the other day, I hacked up an=20
engine that could benefit a great deal from having a background=20
thread running on another CPU (*) that generates some data every now=20
and then. There is heavy work to be done, but it's not strictly=20
coupled to the "game frame rate" rendering.
(*) Actually, even running it on the same CPU would help, as
the work isn't trivially divided into "some per frame" in
any other way. More fine grained asynchronous processing
would only make it more efficient and reduce the risk of
data arriving late, so even with the pure overhead that
threading results in on a single CPU, it could be a win.
> What approaches are you using? What=20
> libraries? Are any libraries really designed to help?
So far, I've pretty much only done raw processing (DSP and stuff) in=20
any extra threads, so I don't have much experience with actually=20
mixing libs and threads.
> It just seems to me that this is a big change and that it isn't
> being discussed anywhere. I have this horrible feeling that a lot of
> people are going to buy brand new hyperthreading multicore
> motherboards and then wonder why their favorite game doesn't run any
> faster than it used to.
>=20
> In fact, it is so completely ignored that I find many people with HT
> Pentium 4s have hyperthreading turned off.
One reason for that, in the specific case of HT, might be that it's=20
different from SMP, and operating systems don't support it all that=20
well yet.
=46rom what I hear, it's quite common to actually see a *slowdown* when=20
enabling HT, at lesat with certain applications. This is apparently a=20
result of the OS being unaware of threads are doing, and the fact=20
that a HT CPU has the cores fighting for the same FPU and some other=20
shared units. If you have a pair of threads that fight for the same=20
units most of the time, you may be better off just running them one=20
at a time, it seems. The OS should pair integer heavy threads with=20
=46PU heavy threads - but I guess that's pretty much impossible to do,=20
unless the OS can make use of hardware profiling features to tell=20
which threads to what and adjust accordingly.
//David Olofson - Programmer, Composer, Open Source Advocate
=2E- 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:
