Computer Chess Club Archives




Subject: Re: DB NPS (anyone know the position used)?

Author: Peter W. Gillgasch

Date: 18:57:18 01/26/00

Go up one level in this thread

On January 26, 2000 at 21:11:25, Ernst A. Heinz wrote:

>On January 26, 2000 at 20:03:56, Peter W. Gillgasch wrote:
>>On January 26, 2000 at 16:26:08, Robert Hyatt wrote:
>>>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,
>>Bob I really hate it when we share the same opinion 8^)
>No, we are not only talking about the quiescence search. We are talking
>about the last full-width plies (without hash tables!) plus the quiescence
>search. I do not really know how good the move ordering can be in this

Funny that you mention this. It can be absolutely terrific without
trans / ref and other memory intensive dynamic re-ordering means. I
have a program that can be compiled to work without any trans/ref
stuff and with the notable exception of endgames there is basically
no difference in terms of the branching factor or depth reached. I
was totally amazed by that. If they did things right the gains of
a trans/ref are really modest, especially if you consider the
vast cost of them. You can pick a position, turn null moves and
extended futility pruning of, activate the #STATISTICS switch or
whatever it is called now and report B for comparision if you want :)

>In his IEEE Micro article Hsu mentions an average cycle count of 10 per

Hm, this is exactly in line with my 8 clocks for tree traversal plus
the 2 clocks I estimated for the fast eval and the cutoff decision :)

>He times the "slow" part of the evaluation at an additional 11 cycles
>overall with a 3-cycle latency per column. It does not look like the "slow"
>part of the evaluation is further overlapped with other stuff. So it
>definitely hurts the NPS rate.

This doesn´t say anything about your argument that the fail low nodes
matter. A "fast" fail low node costs 10 cycles to be traversed and
rejected, a "slow" fail low node costs 21 cycles if your information
is correct. If 20% of the nodes are of that nature and if I give you
the benefit of the doubt that there are some root positions in which
all nodes of that nature are "slow" and other positions where all nodes
of that nature are "fast" then the difference in terms of nodal rate
is in the 10 % range in this worst case scenario since 20 % of the
nodes roughly double in execution time. If there is a flux of 50 %
between "fast" and "slow" evals at those nodes we are at 5 %, which
means that the average time to process a node would raise from 10
clock cycles to 10.5 clock cycles. I would call that pretty much
constant and "hurts" is probably too strong a word for that

-- Peter

This page took 0.03 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.