Author: Mridul Muralidharan
Date: 08:19:46 01/20/06
Go up one level in this thread
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 ... >>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.