Terry:
>>Several on this list have experimented with concurrent processing -
>>can you share any overall summary of your results? How well does
>> the problem scale? Any advice?
Sylvain:
>The results I have so far are very simple. I have a very (very)
> simple concurrent implementation of UCT. With 4 processors,
> the lost time is about 10% (the speed is *
3.6 with 4 processors).
> Comparing with the same number of simulations per move,
> the strength is the same (no [loss] by the fact that it is no more a
> "real" UCT as several threads can take the same path).
That level of concurrency is excellent! So it should be possible to do
about 3.6 times as many simulations per move in the same time,
memory permitting? From previous discussion, it seems that doubling
from 35,000 to 70,000 simulations was quite beneficial, so 3.6 times
35,000 should perhaps be even stronger.
>4 processors is very few, so this can be different with 32 processors
> for example. My guess is that with a very little work, it should work
> well even with 32 processors. So I don't see any problem to benefit
> from the future multiple cores :).
Within the year, quad-core and eight-core systems should be
readily available. One might even try the Sun Ultrasparc T2000, currently
available with 8 cores, each capable of running 4
concurrent threads, designed to make maximum use of memory
bandwidth by firing up a new thread whenever another thread
is stalled waiting for memory. Today's exotic multiprocessor
system is tomorrow's commodity chip.
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
