Computer Chess Club Archives


Search

Terms

Messages

Subject: About limiting Qsearch, again...

Author: Severi Salminen

Date: 11:20:18 12/29/01


Hi!

I made a run with Requiem on position (1.e4 e5 2.d4 d5)

[d] rnbqkbnr/ppp2ppp/8/3pp3/3PP3/8/PPP2PPP/RNBQKBNR w KQkq - 0 1

I let the engine increment a counter every time it called qsearch() at certain
depth. The numbers include only 10 ply search, not previous iterations. I want
to emphasize that this "experiment" only applies to this particular (allthough
quite typical) position. This was the output (the interesting part is at the
end):

Requiem v0.50, Copyright (C) 2001 Severi Salminen
All rights reserved.

rnbqkbnr
ppp..ppp
........
...pp...
...PP...
........
PPP..PPP
RNBQKBNR

CW: 129 CB: 129 EP: 0

 Time  Depth  Score     Nodes PV
 0.00    1     0.00         8 dxe5
 0.00    1     0.03        30 h3
 0.00    1     0.06        48 g3
 0.00    1     0.07       100 Nf3
 0.00    1     0.12       121 Be2
 0.00   (1)               144
 0.00    2     0.03       307 Be2 Be7
 0.00    2     0.05      1060 Bb5+ Bd7 Nc3
 0.00   (2)              1299
 0.00    3     0.05      2544 Bb5+ c6 Be2 Nf6
 0.06    3     0.14      4113 dxe5 dxe4 Bc4
 0.06   (3)              4519
 0.06    4     0.15      5974 dxe5 dxe4 Qxd8+ Kxd8 Be2
 0.11   (4)              9590
 0.16    5     0.11     14031 dxe5 dxe4 Qxd8+ Kxd8 Bc4 Bb4+ Bd2
 0.38   (5)             28645
 0.49    6     0.17     39164 dxe5 dxe4 Qxd8+ Kxd8 Bc4 Nc6 Bxf7
 0.82   (6)             62199
 1.21    7     0.17     91852 dxe5 dxe4 Qxd8+ Kxd8 Nc3 Bb4 Bg5+ f6 Rd1+ Bd7
 2.97   (7)            213308
 4.61    8     0.21    335261 dxe5 dxe4 Qxd8+ Kxd8 Bc4 Nc6 Bf4 Nh6 Bxh6
 8.68   (8)            660117
13.62    9     0.24   1075397 dxe5 dxe4 Qxd8+ Kxd8 Bg5+ f6 exf6 gxf6 Bd2 Be6 Bb5
27.02   (9)           2055337
41.08    10     0.36   3179248 dxe5 dxe4 Qxd8+ Kxd8 Nc3 Nc6 Bg5+ Ke8 Bb5 h6
Bxc6+ bxc6 Be3
68.27   (10)           5121547

Eval:  0.36, time: 68.27, nps: 75019
Nodes: 5121547, (qnodes: 3506216, leaves: 2790857)
Futile moves: 2783942, ordering: 96.2%

Ply: 8, count: 258910
Ply: 9, count: 453813
Ply: 10, count: 345434
Ply: 11, count: 281178
Ply: 12, count: 246945
Ply: 13, count: 176222
Ply: 14, count: 77837
Ply: 15, count: 32984
Ply: 16, count: 11041
Ply: 17, count: 3329
Ply: 18, count: 1219
Ply: 19, count: 399
Ply: 20, count: 105
Ply: 21, count: 39
Ply: 22, count: 7
Ply: 23, count: 3
Ply: 24, count: 1

Total: 1889466 (manually counted)

What can be seen, is that 97.4% of qnodes remain below ply 14 (0=root). The
reason for qnodes at ply=8 and ply=9 is of course null moves. So performance
wise you won't get much by limiting qsearch depth. On the other hand by limiting
qsearch and returning static score would have allways resulted totally wrong
score. I don't know if that would have affected PV or something else but there
is a great risk. This was with SEE, I don't know how SEEless engine would do,
probably the distribution would be wider and longer.

I made a few games between version with limiting and one without. Limiting to 1
and 2 resulted horrible tactical mistakes. At 3 the "handicapped" version played
more securely but lost. It would have definitely played worse without SEE
because SEE still gives you allmost accurate scores for every capture (pins, for
example, will affect this) even if you don't actually search them: with SEE you
can prune seemingly losing captures easily. If I have time I'll test with a
SEEless version to see how it affects. One other drawback in limiting is
additional instructions when decreasing some depth variable and testing it.

Severi



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.