Author: Peter W. Gillgasch
Date: 17:03:56 01/26/00
Go up one level in this thread
On January 26, 2000 at 16:26:08, Robert Hyatt wrote: >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? Nope. >Or the size of the tree divided by the time needed to >search it? Yes. >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 is what I think too. Even if they have still significant clock cycle difference between "cheap" and "expensive" nodes they can overlap the first FIND-AGGRESSOR / FIND-VICTIM operation with the slow eval cycle. Anyone cares to post the actual cycle counts given in IEEE micro ? Anyway, I still believe that the argument regarding the fail low q nodes is bogus because it assumes that the rate of fail low q nodes after a 10 ply full width search plus extensions and a 4 ply hardware search (is this a q search only?) multiplied with the clock cycle difference between the slow and the fast eval can differ so greatly that it is not washed out by the overhead move generation and tree traversal cycles which are probably in the order of 1,1,2,2,2 = 8 cycles for each "cheap" cutoff. The whole proposition by Ernst implies implicitly that their on chip move ordering is all messed up and their slow eval is painfully slow compared with the move generation and tree traversal clock cycles. I don´t buy that. -- Peter >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. Bob I really hate it when we share the same opinion 8^) >(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.