Author: ArturoDiDonna
Date: 11:47:28 01/21/06
Go up one level in this thread
On January 21, 2006 at 11:03:36, Vasik Rajlich wrote: >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.