Author: Vincent Diepeveen
Date: 08:13:11 05/03/04
Go up one level in this thread
On May 03, 2004 at 10:53:19, Robert Hyatt wrote: >On May 03, 2004 at 10:19:46, Sune Fischer wrote: > >> >>>I don't see any at 8. I don't personally have access to a 16-way box yet so I >>>can't say anything there. But there is nothing that really makes null-move hurt >>>parallel search... >> >>Couldn't it be, that nullmove hurts scalability in much the same way alpha-beta >>"hurts" parallel search compared to minimax? > >I don't see how. It might make _some_ positions more unstable, and unstable >positions hurt parallel search. But it also makes other positions more stable. What a nonsense. "i don't see how." it is very clearly proven. For everyone doing parallel research it is *trivial* that more unstable trees are harder to split. Note that in old issues of ICGA it is already mentionned for example by Jonathan Schaeffer. Further you must wait *longer* now to split because you first nullmove and must search another move before splitting. All issues contributing to the hard fact that getting a good speedup with nullmove is a lot harder than when searching fullwidth. But keep denying it. Just like a few years ago you claimed fullwidth to be better than searching with nullmove in chess. >> >>I wouldn't be surprised if a more selective program was harder to parallelize in >>general. Nullmove gets done *before* you can apply YBW, which has been proven by nearly everyone to be the best way to split the tree. So nullmove has the earlier mentionned effects. It's hard to compare nullmove in that respect with other forms of forward pruning which happen while you already parallel search. >I don't see why, unless you form the hypothesis of "forward pruning makes move >ordering _worse_." That's the only wat this could happen... > >There are obviously "issues". Forward pruning tosses moves out. So at any node >you will have fewer branches to search than in a normal (non-pruning) program. >But if you don't require that all processors always work at the same node, this >should not be a problem. IE Crafty searches endgames just as efficiently as it >searches complex middlegames, from an SMP perspective... In endgames you search in general bigger depths. So on average the trees that are there after you split are bigger. Bigger depthleft means less overhead and more efficient parallel search. You wrote that down even in your own DTS article. It seems the real selectivity here is in your memory! > > >> >>Perhaps at some point the benefit of nullmove is even lost to parallel >>inefficiency and the disadvantages of nullmove begins to outweigh the savings? >>That might make an interesting experiment :) >> >>Of course I don't know anything about it, only guessing. >> >>-S.
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.