Author: Robert Hyatt
Date: 10:23:15 08/30/01
Go up one level in this thread
On August 30, 2001 at 12:37:34, Frank Schneider wrote: >On August 30, 2001 at 09:59:57, Robert Hyatt wrote: > >>On August 30, 2001 at 05:58:01, Dan Andersson wrote: >> >>>One really simple parallel search algorithm is to have two searches working >>>independently. Only one search communicate with the output. But both share the >>>same hash table and thus work together. If you are lucky, that can result in a >>>good speedup. To increase the efficience of this algorithm, use ETC to get >>>better use of the hash table, this won't strain bandwidth in the bulk of the >>>search. >>> >>>MvH Dan Andersson >> >> >>I don't see how this will perform reasonably when it is probable that both >>processors will search the same tree at the same time, > >The idea is to detect all-nodes and let n-1 processors search the moves >in a different (e.g. random) order. > >However, didn't work too well for Gromit so far :-( > >Frank > My off-the-cuff analysis says that as you use more processors, this is going to work worse and worse. A normal tree-splitting search seems to me to be the right way to do this. Although I realize it is a lot of work with some complex data structures and timing issues. The "easy way out" is generally not very good overall. >> and hashing won't stop >>that from happening. This might be better than nothing. As might the ABBADA >>idea, but good old intentionally deliberate parallel searching has to be >>better than these "uncoordinated approaches". >> >>The shared hash table with the "exclusive bit" is a big problem on most >>machines. Locking hash entries is a performance killer, and they have to be >>locked if such a bit is used.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.