[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] multi-board branch

From: Paul Pogonyshev
Subject: Re: [gnugo-devel] multi-board branch
Date: Thu, 21 Apr 2005 22:10:05 +0300
User-agent: KMail/1.4.3

Arend wrote:
> On Mon, 18 Apr 2005, Paul Pogonyshev wrote:
> > I wrote:
> > > OK, another huge patch makes multi-board GNU Go pass `reading.tst'
> > > without unexpected results and with exactly the same node counter as
> > > original.  Phew...  Had to convert a large number of files just for
> > > this.
> >
> > And now also `connect.tst'.
> The obvious question: How big is the performance penalty?
> That's of course we need to take into account when discussing
> whether we want this in mainline.

I don't know, because I cannot run "real" tests yet: they depend on all
the GNU Go at once and I still haven't converted owl and `value_moves.c'.
I don't expect the performance hit to be over 3% though.

Another (small) gain is that we can spawn new gobans for certain side-
tasks, like `analyze_eyegraph'.

> Can you say a little more about your general motivation for doing this?
> Do you plan to make GNU Go mulit-threaded?

Yes.  I have a plan on how to do this without much work.  For the
beginning, we could simply delegate intensive stackp==0 computations
(like owl stuff) to different threads.

> I certainly don't mind paying 1% or so in performance penalty on
> uni-processor ssystem for having GNU Go being able to use multple CPUs
> where they are available. On the other hand, paying 10% for a project that
> will never get completed... :)

As I mentioned, I'm close to make it all into working state.  Not thread-
safe yet, though, as I have only wrapped up the board-related variables.
Different caches and miscellaneous variables are still global and thus not


reply via email to

[Prev in Thread] Current Thread [Next in Thread]