Re: [gnugo-devel] Parallelizing GNU Go

[Dave Denholm]

Evan Berggren Daniel <address@hidden> writes:

> On Fri, 4 Apr 2003, Dave Denholm wrote:
> 
> > Paul Pogonyshev <address@hidden> writes:
> >
> > > Dave Denholm wrote:
> >
> > > > Depending on what happens with hyper-threading...
> > > > Also depends on whether gnugo is cpmpute bound or memory bound.
> > >
> > > i believe it's mostly memory-bound, but who knows :) hyper-threading might
> > > become a good reason for going threaded but it is not at the moment 
> > > certainly.
> > >
> >
> > Hmm - if it really is memory bound, then running two threads might
> > be *slower* than one thread on a multi-cpu machine : memory
> > thrashing may dominate.
> >
> > ie if there is not enough memory bandwidth to satisfy one cpu, then
> > making two cpus fight over the same bus is doomed !
> 
> My guess would be that GNU Go is bound by memory latency, not CPU cycles
> or memory bandwidth.  Therefore, running it on an SMP machine would work
> fine, and it might even get a noticeable improvement from a HyperThreading
> machine.
> 


Hmm - I've been meaning for *ages* to looking into pre-fetching
tricks to try to improve latency.

But x86 is superscalar, and does micro-instruction re-ordering internally,
so it can in principle overlap compute and memory fetch to a small extent.


Back on the subject of globals vs env pts, one benefit of using
a structure is that we can force the memory ordering of things.

So eg could make a global instance of a structure containing all
the really important globals. This forces them to appear together
physically in memory, which must be good for cache behaviour.



dd
-- 
address@hidden          http://www.insignia.com