Author: Tord Romstad
Date: 01:46:40 01/20/06
Go up one level in this thread
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. >And dont worry , there is an unjust perception that writing parallel engine with >good speedup is tough - it is not really that tough from my expierences :) It looks difficult enough to be fun, but easy enough to be managable. :-) >PS : >Simplest way to kickstart a parallel engine ? >1) Get/borrow a parallel box - atleast a dual core. Already done: I've ordered one of the new Dual Core iMacs, and expect to receive it some time next week. :-) Unfortunately I don't think I will have the chance to do much programming before the summer, though. >2) Design a parallel search on paper which can scale upto say 16 or 32 (forget >that you might never run on it anytime soon) - it is better to have something >which can potentially scale higher than having to rework code after a couple of >years. (zappa , diep , sjeng , crafty , etc) Of course. I do all my programming on paper, anyway. The computer is just for the tedious work of running and debugging programs. >3) The way I started 3 weeks ago was to write basic make/unmake move , movegen , >etc and a parallel perft and make this work. Then build on top of it. >This can be easily validated for correctness and yet should give you nearly >linear perfect 'time to solution' scaling. Good idea; a parallel perft search looks like the ideal first exercise. Tord
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.