[ODE] Multi-threading

[Matthew Harmon]

It is a cool and complex concept, here's what I can squeeze into my little
brain...

Given we are not waiting on any hardware, then on a single core a single
thread will always be fastest.  The classic update-draw-repeat loop.

Once a handful of cores become available, the plot thickens (deeply!)  A
simple approach would be two threads.  Game on core A, and physics on core
B.  Both run at full bore with Game (core A) using the latest snapshot from
Physics (core B).

A more complex approach would be to have a big handful of threads and a
kernel that distributes them among the cores, somehow trying to keep
everybody busy.  This is cool, but VERY complex in practice.  You now need
to schedule how much CPU you want for each operation and figure out what
balance gives the user the best result.  You also have to be sure everything
can synchronize or "snapshot" data for the next frame.  IMHO, this is
complex - although we'll get there.

Once you have many, many cores, something like OpenMP (as I understand it)
becomes more useful as a common operation can be spread among oodles of
cores.  This seems to have been the promise of the CELL cpu... we'll see
what happens.  Of course, if OpenMP is smart enough to NOT thread at all on
a single core...

My guess (just a guess) is that we will be working with the "simple" model
for at least the next console generation.  That is, breaking up our work
into big, logical chunks, and handing them off to different CPUs.  I.E.
doing all the physics on one core as opposed to doing a little bit of
physics on each core.  This may even prove to be better/faster than
sophisticated scheduling.  Interlocks, memory bandwidth and sheer programmer
confusion may limit how we use multiple cores for a while.

-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org] On Behalf Of Tyler
Streeter
Sent: Friday, August 19, 2005 2:53 PM
To: ode at q12.org
Subject: Re: [ODE] Multi-threading

> >I think OpenMP is not the right solution for PC architectures and game 
> 
> algorithms.< 
> 
>   
> 
> Agreed.  As cool as OpenMP is, PC and console developers need much finer
> control over how, when and why threads are created.  ...
> 

> ...My personal opinion is that for a game
> you only need multiple threads per core if you are exploiting some sort of
> hardware parallelism (hard drive, network card, etc.) 
> 

It seems to me that most of these arguments (i.e. referring to "finer
control") are referring to functional parallelism, though, not data
parallelism (which I think is the case with parallel physics/collision
detection).  As long as the problem can be broken into a bunch of
small chunks, each being processed in exactly the same way, we have
data parallelism, and that's what OpenMP is good for.  I don't know
how practical this solution is in the near future, but later when we
have lot of cores to use on standard machiens, it might be.

I thought of OpenMP first because of what I heard at the GDC earlier
this year.  There were multiple talks about OpenMP in games.  Also,
when Ageia gave their presentation (using a multi-core Pentium chip,
not the PhysX chip; I'm guessing it wasn't quite ready for a public
demo), they used a "fork and join" model* that closely matches what
OpenMP does.

Tyler

* See the picture here: http://www.linux-mag.com/content/view/1556/2082/

_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode