Author: Robert Hyatt
Date: 07:50:39 07/09/04
Go up one level in this thread
On July 09, 2004 at 10:30:29, Andreas Guettinger wrote: >On July 09, 2004 at 09:43:32, Robert Hyatt wrote: > >>On July 09, 2004 at 09:30:56, Andreas Guettinger wrote: >> >>>On July 09, 2004 at 09:13:31, Robert Hyatt wrote: >>> >>>>On July 09, 2004 at 08:38:31, Tord Romstad wrote: >>>> >>>>>I am currently writing a chess engine. Parallel search is not among my main >>>>>interests at the moment, but it is not entirely impossible that I will give it >>>>>a try some time in the future. >>>>> >>>>>In order to keep everything as flexible as possible, I would like to design >>>>>my algorithms and data structures in such a way that adding parallel search >>>>>at a later stage is feasible. I understand that I should remove most of my >>>>>global variables and replace them with huge structs containing the same data, >>>>>and use one such struct for each thread. Is there anything else which is >>>>>important to keep in mind? >>>>> >>>>>Tord >>>> >>>> >>>>That's the main issue assuming you are going to use lightweight processes >>>>(threads) which I believe is the best approach. The most thread-specific data >>>>you have, which means less global data, will help performance (modified global >>>>data is not cache-friendly on a SMP box) and simplify testing (since modified >>>>global data requires atomic locks to avoid interleaved update problems). >>> >>>But crafty is using a global copy of the tree strcut (local[CPU]) per thread in >>>parallel mode, isn't it? >>> >>>regards >>>Andy >> >> >>That's the idea. if you look, each "copy" of the tree struct is allocated >>locally for NUMA boxes, so that it is on the actual processor where the thread >>executes. >> >>But I think you are mixing terms. "local vs global" to a compiler person refers >>to when the data "exists". IE global data exists when the program starts, while >>local data is allocated on the stack and freed as needed. >> >>Here the idea is local data is only modified by a single thread, where global >>data is modified by all. So it is not the same as when discussing the scope of >>a variable in the context of a programming language. For parallel search it >>doesn't matter whether the data is global, local, or malloc()'ed or whatever. >>What matters is can my processor keep my data in its local cache without it >>becoming invalidated due to another processor modifying it in its cache. If >>that happens, the data is global/shared and is a problem. If that doesn't >>happen, then it doesn't matter whether the data is local or global, it is not >>shared and to the thread, it is local since it will exist in only one cache. > > >Thanks, I have to think about that some more when I arrive at home. >Still, the threads have to access the tree structs of other threads, i.e. when >arriving at a split point. On the other hand each tree can be easily protected >using a mutex. > >regards >Andy Correct. At a "split point" you have to at least share a move list to avoid searching the same move twice on two different threads. But that is a tiny part of the whole search that each thread will do. I doubt you can even measure that small amount of time where they are accessing/modifying something that is shared... if it is done right.
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.