[computer-go] Pay-as-you-go cluster?

[Chrilly]

>
> So, basically, the master node feeds the simulation nodes with positions 
> from which to run simulations, and collects the results later. This avoids 
> the burden of having to share the hash table over the network, at the 
> price of a delay between the time when a simulation is asked and when its 
> result is known.
In Hydra I use the very primitive idea of replication of Hashtables. The 64 
processor cluster has 32 Dual nodes. There are 32 replicated hashtables. Its 
not an exact replication. First of all the entries of a given hashtable are 
only distributed in buckets of at least 15 entries. This has to do with MPI. 
The time and overhead for sending 1 or 15 entries is almost the same. 
Sending buckets reduces the message passing overhead almost by the size of 
the bucket. This bucket concept has the effect, that an entry in the "home" 
table is only distributed after some delay. But in Alpha-Beta there is no 
need for exact replication. Its sufficient to have a high hit rate. Secondly 
the entries must have a minimum depth (currently 4 Plies). Only the more 
valuable entries are replicated.

This very primitive method works in Hydra much better than a complicated 
distributed hash-concept used in other massive parallel chess programms 
(e.g. Zugzwang). The Hydra search is in comparison to the message latency 
much too fast. For subtrees of depth < 7 the remote answer would practically 
always arrive after the search has been already done locally. Ulf Lorenz, 
the parallel expert of the Hydra-team, intially claimed that it works only 
for 8 processors (4 tables). It works still for 64 satiesfactory. But 64 
seems to be an upper bound.
The main reason I have choosen this method is: It is very simple to 
programm. An asynchron mechanism is always nasty. One has to relate the 
incoming answer to an event/position some time before.
There is no guarantee that when one sends request A to processor X and then 
request B to processor Y, that the answer for A arrives before the answer to 
B. The result can also be already obsolete.
Doing a hash-bucket broadcast and entering the bucket at the destination 
into the hashtable is in contrast trivial.

Chrilly