Author: Vincent Diepeveen
Date: 11:10:34 05/03/04
Go up one level in this thread
On May 03, 2004 at 13:03:16, Sune Fischer wrote: >On May 03, 2004 at 11:13:11, Vincent Diepeveen wrote: > >>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. > >Yes I think that is trivial too, but what is not so trivial is if nullmove >causes these unstable search trees. > >>Further you must wait *longer* now to split because you first nullmove and must >>search another move before splitting. > >Yes, but wouldn't this result in some processors running idle? It sure will. So there is 2 possible explanations why it is not performing the same. there is hard data that there is a signficant difference measured in a scientific correct way. And from the results we know that crafty definitely doesn't lineairly scale in speedup going from 1 to n, like his article in journal of ICCA/ICGA suggests. Also him denying that there is shitzero difference in speedup between using nullmove and not using it (and searching fullwidth) is clearly not true. >>>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. > >That sounds logical, but I think splitting overhead << parallel search overhead, >so there must be another explanation too. > >I seem to recall some numbers from Crafty, that a split is basicly a copy of a >few kilobytes and a split happens a few thousand times a minute. This would >accumulate to 1 second CPU time? It has an exponential effect of course. The more cpu's the more it hurts. >-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.