Author: Dieter Buerssner
Date: 16:40:39 12/05/03
Go up one level in this thread
Some more statistics, without citing any context. I was not sure, where to place
this followup best. It is meant to show some more numbers in the context of our
(Tim and me) discussion. Perhaps, it would have been better handled in email -
perhaps some other readers find the numbers interesting, too - perhaps nobody
finds them interesting. Just ignore them, then. I added another counter, to show
the nodes in "first level qsearch" (Qsfnodes). Nodes are incremented, after any
search is entered as nodes. Qsfnodes are incremented, when qsearch is called
from search. Leafnodes is incremented, at deeper levels. Only legal moves are
counted.
Two test to search depth 6. First one with probing/storing HTs at all qsearch
nodes:
176557443 8:51.5 6.19 6f. 1.Rxg8+ Qfxg8 2.Rxh6 Q5xh6 3.Qxh6 Rxb1+ 4.Kxb1
Qb7+ 5.Qhb6 Rxa3 {HT} {501}
176557443 Nodes, 98.02% Leafnodes, 1.70% Qsfnodes, 332127 Nodes/sec
htable: 155323384 store, 0 rejected, 171906912 probe, 9.9% f/p, 11.0% f/s
fail_high 141496
1 move: 138140 ratio 97.628% sum 97.628%
2 move: 2125 ratio 1.502% sum 99.130%
Meaning - there where 141496 fail highs (excluding null move) in "normal"
search, of which 97.6% succeeded in the first tried move, and 1.5% in the second
tried moves. This statistic was only sampled in normal search (not in qsearch)-
Only 0.28% (100-98.92-1.70) of all nodes (counted as explained above) where in
the "normal" search. So much lower, than what Tim's number suggest.
Note, that the times shown do not mean much. Another analysis was running at the
same time.
Without probing/storing at any qsearch level:
529724130 25:17.4 4.97 6f. 1.Rxg8+ Qfxg8 2.Qxb8 Qhxc1+ 3.Qaxc1 Qxb8 4.Bxb8
Nb3+ 5.Qdxb3 Rxb3 6.Q2xb3 Qxa5 7.Qexa5 Bxd5
{500}
529724130 Nodes, 99.43% Leafnodes, 0.49% Qsfnodes, 349079 Nodes/sec
htable: 401779 store, 0 rejected, 428011 probe, 18.5% f/p, 19.7% f/s
fail_high 120417
1 move: 115821 ratio 96.183% sum 96.183%
2 move: 2562 ratio 2.128% sum 98.311%
3 move: 617 ratio 0.512% sum 98.823%
4 move: 348 ratio 0.289% sum 99.112%
So, in either case, I get much less normal search nodes than Tim (even, if in
both cases all in all Yace search needs many more nodes). Can this be explained
by different extensions/pruning only? After depth 5, in the second example (not
using HT in qsearch) I saw a hit ratio of over 20% (earlier, I reported a much
smaller hit ratio for a quicker search under the same conditions). Still, it was
much slower, than using HTs in qsearch. I did several experiments, to compare
(in more normal positions) the performance of using and not using HTs in
qsearch. At first, I expected that for very long searches (where HTs really are
overfilled) not using HTs in qsearch should be better. But I found that using
HTs always for my engine seems better even in this case. The above example (the
one without using HT in qsearch) is not a good test case. Finishing depth 6
needed a long time, but really the whole HT was not filled.
Cheers,
Dieter
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.