Author: Tom Kerrigan
Date: 10:18:47 08/02/98
Go up one level in this thread
I don't know what you're talking about. I thought we were talking about spawning a process to generate moves and another for making the moves and that sort of multiprocessing. With that sort of program, you're going to have a lot of processors all working with the same memory, which means there's an amazing amount of work going into figuring out which processor owns which cache line, etc. This may have been practical when processors didn't have cache or even when the bus speed was the same as the processor speed, but it seems like this approach on modern computers would just stall the processors most of the time. Cheers, Tom On July 31, 1998 at 16:53:55, Robert Hyatt wrote: >On July 31, 1998 at 08:05:04, Tom Kerrigan wrote: > >>Would this work on modern computers? >>IE, 400 MHz processors with lots of cache? >>Seems to me like cache coherency would be a big deal. >> >>-Tom > >remember... it is already being done. I've been chatting with a guy up at >SGI who is getting this to run on a 256 processor machine... There are lots >of ways to handle cache coherency issues, from bus snooping (on bus >architectures) to dedicated busses for cache controller communication only... >non-trivial and non-cheap, but solutions. :) IE think about my ALR with 4 >processors... same issue with L2 a L1 caches for each cpu... > > > > >> >>On July 30, 1998 at 20:28:10, Robert Hyatt wrote: >> >>>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.