Le Mercredi 8 Mars 2006 08:21, Arend Bayer a écrit :
[...]
> This needs more discussion.
>
> Arend
>
So here is one point of vue.
- Alain
---------------------------------------------------------------
There are different scales and granularity in gnugo, which
give different possible interfaces:
- A trunk = examine_position, 50% of the cpu use.
= the elements, (and a static analysis ?)
= one first-guess interface
Detect zones of interest where it is worth digging?
- The head(s) = value_moves+review_move_reason the other 50% cpu
= the dynamic / logic / strategic
= an interface with move_reasons
(the twin uses one Black head, and one White, so another 50% more.)
- Find_best_move: reduces all to one single numerical_value. (slightly modified
by the twin)
TODO:Ideas:
* A strategic module that identifies high-level goals and then gives
these goals to the rest of the engine. says something high level can be done
here
- The whole-engine as a black-box like in SlugGo.
These different scales seems to correspond to different kind of parallelism
- the trunk of the engine, is at the level of multi-core/SMP
- the heads at level of multi-core/SMP
- the whole engine as a black-box : SMP/ NUMA Clusters / distributed.net :)
From SlugGo papers, we know that currently distributed.net is useless.
-----------------------------------------------------------------------------
_______________________________________________
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
