Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Let's talk about fraud.

Author: Sune Fischer

Date: 10:03:16 05/03/04

Go up one level in this thread


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?

>>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?

-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.