Author: Walter Faxon
Date: 05:21:39 01/20/06
Go up one level in this thread
On January 20, 2006 at 07:19:05, Uri Blass wrote: >On January 20, 2006 at 04:46:40, Tord Romstad wrote: > >>Hi Mridul, >> >>Thanks for this valuable advice! Some comments scattered below: >> >>On January 19, 2006 at 22:10:05, Mridul Muralidharan wrote: >> >>>Hi Tord, all, >>> >>> First off , potential boring blurb ... in which case , please ignore :) >> >>Boring? This was the best post I have read here since along time! :-) >> >>> In general for chess , my personal preference is to use processes than threads >>>from KISS perspective. I am going to ignore the contentious issues of >>>performance , cache locality issues , etc debates here and just advocate based >>>on this one point ;-) >> >>I agree that the KISS principle is by far the most important factor. I am >>sure performance would be good enough (at least for my purposes) with >>processes. If I end up deciding that using processes is simpler and cleaner >>(I have to think a bit more before I am sure), I will certainly use that >>approach. >> >>> From my expierence , having very well defined and explict points of >>>interaction between the processes through the shared memory and mutexes really >>>really helps. >>>More like having clearly defined interfaces (through data though) - there are >>>sufficiently high number of race conditions already possible (esp initially when >>>you start off) without introducing additional possibilities if you are trying >>>out DTS , etc :-) >>> >>>It could be argued that parallelisation can be effeciently done with threads and >>>it can be - but you do incur a more stack based approach of shuffling >>>intermeadiate variables around and need to be very very careful. >>> >>>Example : >>>In eval , typically I have an attack_table[2][64] initialised at begining (now I >>>have increamental attacktable - but idea is the same I would guess) and use it >>>everywhere else , ditto for other forms of info like attack_patterns , >>>king_safety , pawn_defects , etc. >>>Simialrly , my pawn tables , eval hash tables , etc should also need to be >>>lockless or assuming more complex/larger info storage in the tables - gated. >>> >>>If you are using threads , either you would use a stack based approach and pass >>>these around , or you will put them in a 'this_proc' and use it from there (so >>>an extra indirection for nearly everything : this_proc->attack_table[] , etc) >> >>I currently don't think this will be a major problem to me. Except for hash >>tables (which have to be shared anyway), I don't think I have any global, >>non-constant data. >> >>>One possible downside is that egtb probing will be incurring higher penality >>>(from what I remember - I could be wrong here) since you will not be using the >>>advantage of the caching done by Eugene Nalimov across the varios processes ... >>>this will be per process. >>>Maybe someday this will be shared memory and remove that penality ! >> >>Fortunately I don't have to worry about this. I don't use EGTBs, and probably >>never will. >> >>>Ofcourse , at the end of the day , it is just how you think about the problem >>>and your solutions to tackle them - there are no HUGE drawbacks of either >>>approaches unless they are specific to some platforms. >>>And the problems you solve IMO are pretty similar in both approaches. >>>Amd dont forget - we should have fun solving these problems :) so use an >>>approach which suits you. >> >>Portability is one of my concerns. I know almost nothing about non-Unix >>operating systems. Are processes and threads equally simple to port to >>Windows? >> >>>Would be great to see a parallel Gothmog or Glaurung version out there ! >> >>There will never be a parallel Gothmog, but there will almost certainly >>be a parallel Glaurung sooner or later. > >If your target is to improve glaurung's playing strength then it is possible >that using ths same effort for improving the playing strength of it in a single >processor is better as long as glaurung is significantly weaker than >Rybka(single processor). > >There is a good chance that I will never have parallel movei because I prefer to >invest the limited time that I spend on programming on the engine. > >I even did not start to learn about parallel search but the subject does not >seem interesting to me when better evaluation or better search tricks seem to be >more interesting for me. > >Uri Hello, Uri. How has the advent of Rybka inspired you to re-think your approach to chess programming? If you do not intend to eventually go commercial you can divulge your secrets without fear of economic loss -- and possibly get some useful feedback from other chess program experimenters. In fact, more openness on the part of a prominent programmer like yourself might encourage others to give up their secrets, leading to a general improvement of all engines akin to that produced by the original Fruit. Someone has to go first! If this idea interests you please respond by starting a new thread. -Walter
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.