Author: Vincent Diepeveen
Date: 04:04:30 09/01/01
Go up one level in this thread
On August 31, 2001 at 10:24:41, Robert Hyatt wrote: >On August 31, 2001 at 09:06:42, Vincent Diepeveen wrote: > >>On August 30, 2001 at 23:21:58, Robert Hyatt wrote: >> >>>On August 30, 2001 at 20:48:30, Vincent Diepeveen wrote: >>> >>>>On August 30, 2001 at 14:43:00, Robert Hyatt wrote: >>>> >>>>>On August 30, 2001 at 14:25:39, Scott Gasch wrote: >>>>> >>>>>>On August 30, 2001 at 14:07:50, Dann Corbit wrote: >>>>>> >>>>>>> >>>>>>>Dumb question: >>>>>>>Why not let them all have their own move generator and just share the hash >>>>>>>table? >>>>>> >>>>>>I guess that's one approach -- run them as seperate processes in seperate >>>>>>virtual address spaces and simply share the hash table. I was planning on using >>>>>>simple threads in the same address space though. Not sure why, seems more >>>>>>straightforward to me... >>>>> >>>>> >>>>>One reason is that there are other things to share. Killer moves. History >>>>>move counts. move lists (you need to share a move list at a ply where more >>>>>than one processor is searching) and so forth... >>>> >>>>No you don't want to share killer moves. History moves do not give >>>>a speedup if you write a bunch of extra rules to order moves. >>> >>>Sure you do, if you do it right. I share them. And history moves are better >>>than random, and work fine for everyone that has tried them. >> >>You don't want to share killermoves, as each processor searches its >>own tree, though there might be transpositions, the most important thing >>are the killermoves which gets updated each time. The second killer in >>my killermove list is hardly of any statistical significance in DIEP. > >Try using the ply-2 killers at ply, as we did in Cray Blitz. _then_ you >will want to share the earlier killers. I'm not talking about a set of >killer moves that is common to all threads. I am talking about separate >lists of killers for each thread, but they have common moves prior to split >plies. I already tried it bob and it doesn't work for me the global killers. i use for the current killers ply+2, ply-2 , ply+4 and such. However, the global killer in general doesn't work for me as well as making a bit more code to order moves. now that's pretty hard to do in crafty as it hardly as any form of ordering. I agree with you that if your option is random ordering, that what you do now is very smart. In diep i have written loads of extra code to order moves and that's all non-general, so not usable in other games than chess. > > >> >>So a killer which kills this line is interesting. >> >>Suppose now that in parallel 2 processes are writing into a killer list, >>both having a complete different position at their board, that's quite >>silly isn't it? > >If that was what I was talking about, yes. But notice we are discussing what >to put in a structure that is unique for each thread, but which can have common >data for plies prior to a split point. You talk about global killers here. Those do not speed me up. Interesting for me to know are killers which just happened in this position and now i make 1 move and then they are going to work for me too! Note that the global killerlist for each process are about the same, so there is no need. The search produces such huge amount of new killermoves, that sharing it for a global killer is nonsense whereas the speedup for the new temporary killers is huge to not share it. Note sharing a killerlist is a pretty trivial thing for me as i already share many datastructures, but it didn't speed me up, in contradiction it slowed me down. Later you then find the explanation for it, which is very plausible. General ways to order moves hardly work in short. - hashtable move gives *some* (but not much) improvement in move ordering - current killers (+2 -2 +4 whatever) work quite well The rest already hardly works. History heuristic would let me search up to a ply less deeply. > >> >>>There's dozens of things that need to be shared. I can dump my shared structure >>>here if needed to show what I share. >>> >>>It is pretty large however.
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.