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 s.th. 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 thread-safe. Paul _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
