Author: Robert Hyatt
Date: 12:40:14 08/02/98
Go up one level in this thread
On August 02, 1998 at 13:18:47, Tom Kerrigan wrote: >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. > This is a well-known issue that most microprocessor cache controllers solve in one way or another. Yes there would be lots of potential places where the caches would have duplicate stuff and have to invalidate other cache lines as they are modified elsewhere. But that is doable for small numbers of CPUs (like my 4 processor ALR, or the soon-to-ship 8 processor Xeon boxes). But a cache coherency bus is/can be a scalability problem, to be sure... I don't like that particular approach to parallel chess, because there is no guarantee that there will be enough moves or evaluation routtines to keep a fair number of processors busy. the "vertical" approach seems best... at least to me... >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.