[Top][All Lists]

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

Re: [Bug-gnubg] redesign gnubg to master/slave

From: Holger
Subject: Re: [Bug-gnubg] redesign gnubg to master/slave
Date: Mon, 22 Dec 2003 18:18:09 +0100

At 20:54 21.12.2003, Joern Thyssen wrote:
One of the recent topics has been multi-threading. Instead of
multi-threading Jim suggested splitting gnubg into a GUI (master) and an
engine (slave) which communicates over sockets.

Besides avoiding the problem of making the engine of gnubg thread-safe
it also follows the Unix design principles

I would like to start a discussion on how to do this.

As I already mentioned some days ago Olivier Baur has implemented all these things already in the branch-multi branch. See http://mapage.noos.fr/gnubgosx/procunits.html . This works very well with the CLI version, but even has an easy to use GUI frontend. "help" will tell you the necessary commands. On this page only the setup through the GUI is described.

How should the split be? Should the slave only be capable of doing
evaluations and rollouts, or should it implement match-analysis as well?
Without much prior thought I'd say only evaluations and rollouts, but
I'm a bit worried about the overhead for a 0-ply match analysis. Also,
what about move analysis?

Imho the tasks (remote or local) should be "big" enough that the protocol overhead is neglectable, but "small" enough so that the machines/processors are equally supplied with tasks and all tasks have a similar execution time. So a 0-ply analysis of one single move/cube decision is no candidate, but 2-ply could already be. This could even be set with a user definable filter.

I guess the best is a stateless interface, e.g., an example could be:
evaluation 4HPwATDgc/ABMA cIkUAAAAAAAA 2-ply cubeful
which replies
evaluation-result 0.519 0.148 0.006 0.128 0.005 +0.060 +0.077

I think something along these lines is done, but probably on a slightly lower level.

Btw, in case this CVS branch is not accessible I could send you a copy of the latest checkout.



reply via email to

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