Author: Vasik Rajlich
Date: 08:03:36 01/21/06
Go up one level in this thread
On January 20, 2006 at 11:19:46, Mridul Muralidharan wrote: > >Hi Tord, > > Please see inline. > >Regards, >Mridul > >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! :-) >> > >Hehe , thanks ! >Actually I added that line after I wrote the post (and just before posting) >before heading off to work - my post seemed a bit long ... and personally I dont >like reading long posts :-) > >>> 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. >> > >Neither do I now ... but I got the permission from Nalimov to use it long time >ago ... and support for it does popup in some of my engines from time to time. > >>>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? > >The first time I tried parallel search , I had started off trying it in linux >and then moved it to windows. >This time around , it was the reverse. >There is no direct 1 to 1 mapping of syscalls between unix and windows - but >there are manageable ways to handle the issues. >The only problem which requires special handling is 'fork()'. >Instead of doing it the traditional way of fork() followed by status check and >proceeding as per pid directly to relevent functions , what I do is >* fork() >* check for retstatus and if in child (retval == 0) , then I exec the same >process with an additional cli param. >The reason for doing this is so that I handle the case of unix and windows >uniformly (you do a start process in windows). >Maybe there is a better way to achieve same codepath in both platforms - but >from my limited expierences , this works. > >> >>>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. >> > >Ah ok. >I was always impressed by the ideas you seem to have in Gothmog :) >I do keep asking Dieter also to make yace parallel - but he never seems to have >enough time to get around this task ! >The more the parallel engines, the merrier ;-) > >>>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. :-) >> > >Indeed ! >Took me 3 weeks of parttime work during weekdays and nearly fulltime weekends >(ignoring timeoff to meet friends I guess) to get it working bugfree (from what >I see). >But the fun was intense and the bugs so so irritating that they make you cry >when you fix them (sometimes they can be so so trivial !). >Whatever happens - whether you suceed or not , you will have loads of fun , I >promise you that much ! > >>>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. :-) > >WOW ! >That is some serious piece of hardware :-) > >> >>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. >> > >Heh , I do the reverse - prototype as soon as possible to identify issues I miss >, etc and rarely : very rarely , write it on paper and make sure of its >theoretical accuracy and rigour. >In chess the problem is that most of these prototypes require a lot of support >stuff in place to test the main idea ... > Tord - I am really disappointed :) Personally, when it's time to do something, I first hack it up in the ugliest way imaginable, spraying my code with all sorts of nested #ifdefs and ridiculous logic and global data (so that it doesn't need to be passed around). Next, I hack around some more to try to get some actual performance. Then, usually I throw it all away, no matter how sure I was that it would work. In the rare case that I keep it, there comes a final stage a few weeks or even months later, when I get fed up with the mess and finally clean it up. This is the only way to end up with decent code IMHO :) Vas >>>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 > >All the best ! >On your dual box , you should get very close to 2x speedup for perft - search as >such will be different (initially) though. > >Regards, >Mridul
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.