Author: Robert Hyatt
Date: 17:28:10 07/30/98
Go up one level in this thread
On July 30, 1998 at 17:17:05, Tom Kerrigan wrote: >Memory isn't fast enough to divide up processors by function (e.g., move >generation, etc.). It wouldn't make the program any faster. > >Cheers, >Tom actually it is. In fact, this is how "hitech" works... one processor per chess board square in fact. And others have played with generating moves in parallel, evaluating in parallel, etc. Where it breaks down is once you pass 4 or 8 processors. IE generating moves with 512 processors would be problematic since there are *never* 512 moves to generate, for example. Scalability becomes a serious drawback when you try what is commonly called "horizontal multiprocessing" (assuming the tree is a vertical entity, horizontal means dividing a single node up into pieces, rather than splitting the tree into "vertical slices" and searching each part in parallal as I do). On July 30, 1998 at 16:39:00, Danniel Corbit wrote: > >>On July 30, 1998 at 14:46:46, Tom Kerrigan wrote: >> >>>I was just thinking, what if a chess engine was contained in a C++ class? >>>It would have a function that starts a little loop that waits for work. When it >>>gets work, it starts searching. >>>To use it, you make a thread out of this function. >>>Then, when you want to write an MP program, you make several copies of this >>>class and several threads running the respective loops. >>>The threads, being contained in the classes, don't bother each other, except to >>>request work. >>>Comments? Suggestions? >>I think it is a very good idea, but I might scale it down a bit. For instance, >>make the class be a move generator. Make another class that is a position >>evaluator. The hardest part will be to write the coordinator so that no work is >>duplicated and so that resultsare properly synchronized.
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.