Author: Andrew Dados
Date: 01:49:08 12/30/01
Go up one level in this thread
On December 29, 2001 at 14:20:18, Severi Salminen wrote: >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 There are other trick then simply arbitrary limiting qsearch at given depth. My long time inactive proggy usually ran full qsearch including up to 2 consecutive non-capture checks up to some qsearch depth (I tried 2-6), then limited _its side to move_ qsearch to one of options (eg SEE only; recapture only, no checks, imagine other possibilities), which made it play 'tactically safe' chess against opponents better tactically. Trick was to allow 'all' for opponent, 'prune more' for my side starting at some qsearch depth. Option I found appealing most was 'recapture only' from depth <-4, but including checks (this for 'my side to move'). Such qsearch will not fail for tricks like exchanges which would delay main threat below some arbitrary qsearch depth limit including mate threat from my side. Interestingly none of versions of 'limited qsearch' would limit qsearch node percentage singnificantly - I rather experimented with making 'safer' qsearch. Some would run up to 15% faster, though. -Andrew-
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.