Author: Daniel Clausen
Date: 06:53:02 07/09/04
Go up one level in this thread
On July 09, 2004 at 09:47:36, Tord Romstad 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. > >Yes, threads is what I intend to use. > >>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 as far as I can see, I would be forced to pass an extra pointer to most >of the chess-related functions (search(), evaluate(), generate_moves(), >make_move() etc.). A bit ugly, but I suppose I could live with that. What do you mean with ugly here? To me, functions which work on exactly the arguments they get and maybe return something are much clearer than functions which work on data that is cluttered all over the place. :) Sargon
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.