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

[Eduardo Sabbatella]

Hello,

Im not sure if i understood you very well.
Also, i have read the UCT paper but i never
implemented it so perhaps im wrong.


BASICALLY, the problem of distributed UCT is the
problem of a distributed hash.

Said that, if you don't split the problem in subsets,
you will be have hash bottleneck. As far i know, you
can't implement an efficient distributed hash without
segmenting it.


MC fits perfectly on parallels systems.

When i said "merge the results" is just the the merge
of transposition table/result table of "played 1000
times, 400 black wins", which i think its trivial.

Perhaps between moves you can send every transposition
table of every node to every other nodes. That looks
to make sense so the transposition table get "richer"
from others nodes "experience".


Something its important in distributed programing. (im
not expert but i did an course about it). Its about
not waiting others nodes, sometimes perhaps its better
to calc it by yourself, than to wait a node to send
you the info.

So, perhaps an approach is to do an UCT for every node
isolated, then merge all transpositions tables between
nodes at opponent time.


My 2 cents.


 --- Darren Cook <darren at dcook.org> escribió:

> Sylvain's early ideas were basically the first one's
> I thought of.
> 
> > One UCT per each CPU? then, merge results?
> 
> Yes. How about the master machine does a simple
> 2-ply minimax, and for
> the evaluation of each leaf node it calls another
> CPU (*) and that does
> the UCT monte carlo.


	
	
		
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas