Author: Robert Hyatt
Date: 13:26:08 01/26/00
Go up one level in this thread
On January 26, 2000 at 14:02:02, Ernst A. Heinz wrote: >On January 26, 2000 at 00:31:06, Peter W. Gillgasch wrote: >> >>On January 25, 2000 at 23:57:33, Ernst A. Heinz wrote: >> >>>> In a one by one setting it does not matter at all. >>> >>>Still not convinced: a quiescence node that produces a direct >>>"stand pat" cutoff obviously generates less work than one >>>which fails to do so -- even in hardware! *** QED *** >> >>Which is the same as saying that EVAL is faster than EVAL plus >>some other work. >> >>>Or am I missing something? >> >>Yes. A "stand pat" cutoff does not interact with the behaviour >>of the parent with regard to spinning off siblings since it is >>from the view of the parent just a fail low, which is the reason >>why you can safely prune away that move. Maybe you should read >>a book about futility pruning 8^) > >Unfortunately, futility pruning is unable to lift *all* possible >"stand pat" cutoffs to the parent nodes. > >>If you do not analyze the timing behaviour of both the parent and the >>child you do not analyze the timing behaviour of moves and >>hence you do not even analyze nodes. Your view reduced the >>object of your analysis (a tree) to one node. From a node no tree >>can be constructed hence nothing can be concluded about a tree search >>or their nodal rate... > >I thought we were talking about "nodes per second" here, right?! >Your seem to measure something else, IMO. > >The gross percentage of cheap nodes definitely influences the >overall search speed as measured in "nodes per second" -- even in >hardware! This gross percentage certainly varies in different >positions. Thus, the overall search speed as measured in "nodes >per second" ought to vary too unless the speed variance was totally >offset by an according speed variance in other nodes -- which is >highly unlikely and unproven as of yet. > >But I happily await your proof while maybe writing some more stuff >about futility pruning. :-) > >=Ernst= I'm not following this very well. Are we talking about the _size_ of the tree being searched? Or the size of the tree divided by the time needed to search it? If the latter, I don't see what futility has to do with anything since almost all the tree is done in hardware and everything has a fixed cost no matter what. This stuff will change the node count, but for every node deleted by futility, the corresponding 10 clock cycles to process that node are deleted as well. It would seem to be a constant ratio... This would change if some of this stuff backs up into the software part of the search, of course... But we seem to be talking only about the q-search as implemented in hardware, and every node saved is N nanoseconds saved, period. (N is roughly 500, exactly 500 for the 20mhz processors, a little less for the 24mhz processors).
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.