Author: Uri Blass
Date: 04:19:05 01/20/06
Go up one level in this thread
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
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.