[ODE] Multi-threading

[Tyler Streeter]

Well said, Matthew.

I was thinking long-term in my original post.  I should have explained that.

Tyler

On 8/19/05, Matthew Harmon <matt at ev-interactive.com> wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>