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.