On Aug 25, 2004, at 4:56 AM, Don Dailey wrote:
The primary reason the code is so very slow is that we have found
a
lookahead depth of 16 works very well, and it thus takes a bit
more
than 16 times as long as GNU Go to settle on its move.
Can you explain this statement? You make it sound that your search
takes linear time. Would a 32 ply search take only twice as long?
If by ply you are referring to the number of end leaves in a branching
tree then the answer is that it would take no more than twice as long.
The time is linear in the depth of search. The width of the search
takes
virtually no wall clock time because different search paths are each
done on a different cpu in the cluster. At each branch new cpus are
brought into the calculation.
It was also my understanding that there is currently no branching
except on the first ply, that after the 1st ply the look ahead only
examine one move. There's no minimax involved yet. Is that correct? And
adding minimax would certainly be fun, but require many cpus!