Author: José Carlos
Date: 07:33:05 07/09/04
Go up one level in this thread
On July 09, 2004 at 10:18:14, Uri Blass wrote: >On July 09, 2004 at 09:53:02, Daniel Clausen wrote: > >>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 > >The ugly thing is that if I plan to add function call then I need to add a lot >of parameters. >Another problem is that if later I want to change the function to include one >more parameter then I need also to change all the places when I called the >function. > >I think that you are right that it may be clearer to understand things and it is >more important. > >Unfortunately I wanted to do some changes as fast as possible and by adding >global varaibles I saved time by not giving them as parameters to many functions >and I did not need to think exactly which varaibles are going to be changed by >every function. >The cost was a code that is badly written and later it is harder to detect bugs >in the code or think about changing things. > >Uri Ideally, you'd want to have "black boxes" that take some parameters, do the job and return something. Such a black box can be called from everywhere and you're sure you won't break data anywhere, and get the job done. But that has performance issues, and takes more time to develope for the first time. Later, changes are much easier and the project will probably be finished and debuggeed sooner with the "black box" approach. For a chess program, it's a tradeoff. Try to do that in non performance critical parts of your program. For example, the book handling. Make the book a black box that takes the current board and returns a move (or no move). The rest of the program doesn't need to know what the book code does, and the book code must be respectful with the rest of the program, and don't modify global data. José C.
This page took 0.01 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.