tylerstreeter at gmail.com
Fri Aug 19 15:35:56 MST 2005
Well said, Matthew.
I was thinking long-term in my original post. I should have explained that.
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
> 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
> 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.
> * See the picture here: http://www.linux-mag.com/content/view/1556/2082/
> ODE mailing list
> ODE at q12.org
> ODE mailing list
> ODE at q12.org
More information about the ODE