Eelco de Groot wrote:
Bluebery thinks this is about half a pawn worse than 7. exf6.
A second run with build 373, not clearing hash:
r1bqk2r/ppp1ppbp/3p1np1/4P3/2Bn4/2N5/PPP1QPPP/R1B1K1NR w KQkq -
Engine: Blueberry Beta 4 DM70 Build 373 (256 MB)
by F. Letouzey, T. Gaksch, E. de Groot
11 1:40 -0.46 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Nf3 Bf5 5.Bh6 Rg8 6.O-O-O c6 7.h3 Qa5
8.g4 (58.124.659) 578
11 1:48 -1.18 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qh4 Qd4 5.Qxd4 exd4 6.Nf3 Bg4 7.Nxd4 Rhd8
8.f3 Bh5 9.Be3 Nd5 10.Nxd5 Rxd5 (62.980.249) 578
______________________________________________________________
12 3:10 -0.44 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Nf3 Bf5 5.Bh6 Rg8 6.O-O-O c6 7.h3 b5
8.Nd4 Qb6 9.Nxf5 gxf5 (111.398.358) 583
12 3:21 -1.17 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qd2 Qxd2+ 5.Bxd2 e4 6.O-O-O Rhd8 7.Nge2 Bf5
8.h3 Nd5 9.Kb1 e3 (117.672.288) 583
______________________________________________________________
13 52:32 -0.82 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Nf3 c6 5.Bh6 Rg8 6.O-O-O Bg4 7.h3 Bxf3
8.Bxf3 Qc7 9.Kb1 a5 10.Be3 d5 11.Rhe1 O-O-O
(1.742.238.992) 586
13 130:09 -1.05 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qa4 Qd4 5.Nf3 Qxa4 6.Ng5+ Ke8 7.Nxa4 Bd5
8.O-O Rd8 9.Nc5 Rd6 10.Be3 h6 11.Nf3 Bxf3 12.gxf3
(4.577.664.317) 586
______________________________________________________________
14 130:47 -0.52 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Nf3 c6 5.Bh6 Rg8 6.O-O-O Bf5 7.Be3 d5
8.Kb1 Qa5 (4.593.136.948) 583
14 139:00 -1.11 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qh4 Qd4 5.Qxd4 exd4 6.Nf3 Bg4
7.Nxd4 c5 8.Nb3 b6 9.Bg5 h6 10.Bxf6 exf6
11.O-O Rhe8 12.Rfe1 (4.869.172.180) 583
On the basis of build 373 I made a few changes, going from null window search to PV node search there is less of a fall back in depth. Still it seems to be mostly the PV node search which has a
very high branching factor. This build seemed to do better at first but then there was a 100 minute gap again before the next iteration for 1. Bxf7+ came through...
Then I expected a PV for Bxf7 but Blueberry started to process al other moves once more and the PV came only after that, with the gap between two PVs for the main moves almost at 120 minutes at ply 14 (164 min19sec - 47min16sec).
I wish I knew what exactly causes this. There is a random factor that is probably related to the engine not finding the hash results it needs for IID but this should affect the PV node search less. The effect is much more pronounced at higher depths which makes it difficult to test things. Lack the skill to make custom output tools
just looking at Shredder GUI outputs. Anyways at least here it finds the right move, still struggling with that position from Howard Exner where Blueberry totally oversees the Bxd6 move...
Output from build 375 going almost to 17 complete iterations:
[D]r1bqk2r/ppp1ppbp/3p1np1/4P3/2Bn4/2N5/PPP1QPPP/R1B1K1NR w KQkq -
Engine: Blueberry Beta 4 DM70 Build 375 (256 MB)
by F. Letouzey, T. Gaksch, E. de Groot
10 1:36 -0.52 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Bh6 Rg8 5.O-O-O Bf5 6.Nf3 c6
7.Nd4 e5 8.Nxf5 gxf5 9.Rhg1 d5 (55.762.911) 584
10 3:48 -1.12 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qa4 Qd4 5.Nf3 Qxa4 6.Nxe5+ Ke8
7.Nxa4 Ne4 8.Nd3 Rd8 9.O-O Bd7
10.Ndc5 Nxc5 11.Nxc5 (133.352.178) 584
_____________________________________________________________
11 4:05 -0.40 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Bh6 Rg8 5.O-O-O Bd7 6.Nf3 a5
7.Ng5 Bc6 8.Bc4 e6 (144.115.316) 588
11 4:44 -1.24 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qa4 Qd4 5.Qxd4 exd4 6.Nf3 Bd7
7.Nxd4 Ng4 8.Nf3 Bxc3+ 9.bxc3 Bc6
10.Ng5+ Kf6 11.O-O (167.304.928) 588
_____________________________________________________________
12 6:04 -0.44 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Bh6 Rg8 5.O-O-O Bf5 6.Nf3 c6
7.Nd4 c5 (215.779.290) 600
12 13:11 -1.24 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qa4 Qd4 5.Qxd4 exd4 6.Nf3 Bd7
7.Nxd4 Ng4 8.Nf3 Bxc3+ 9.bxc3 Bc6
10.Ng5+ Kf6 11.O-O (475.196.263) 600
_____________________________________________________________
13 13:14 -0.52 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Bh6 Rg8 5.O-O-O Bf5 6.Nf3 c6 7.Nd4 e5 (477.094.081) 591
13 39:29 -1.10 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qa4 Qd7 5.Nf3 Qxa4 6.Nxe5+ Ke8
7.Nxa4 Ne4 8.Nd3 Rd8 9.O-O Bd7
10.Nac5 Nxc5 11.Nxc5 Bc6 (1.401.466.923) 591
_____________________________________________________________
14 47:16 -0.68 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Be3 Bf5 5.O-O-O f6 6.Nf3 d5 7.Nxd5 Kf7
8.Nxf6 Qb8 9.Nxh7 a5 10.Kb1 Rxh7
11.Bc4+ Kg7 (1.651.839.999) 579
14 164:19 -0.99 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qa4 Qd4 5.Qxd4 exd4 6.Nf3 Bd7
7.Nxd4 Ng4 8.Nf3 Bf5 9.Ng5+ Ke8
10.Nge4 Rd8 11.O-O Bxc3 12.Nxc3 Bxc2 (5.708.863.032) 579
_____________________________________________________________
15 179:21 -0.69 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Be3 Bf5 5.O-O-O f6 6.g3 e5 7.Kb1 Rd7
8.Bf3 Qb8 9.g4 Bxc2+ 10.Kxc2 d5 (6.233.394.799) 607
15 360:51 -0.94 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qh4 Qd4 5.Qg3 Nh5 6.Qf3+ Bf5 7.Nge2 e4
8.Qe3 Qxe3 9.Bxe3 Rad8 10.h3 b5 11.O-O (13.143.926.783) 607
______________________________________________________________
16 464:32 -0.69 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Bh6 Rg8 5.Nf3 c6 6.O-O-O Qa5 7.Kb1 Be6
8.Be3 Bf5 9.Ng5 Rb8 10.Nge4 g5
11.Nxg5 Bxc2+ 12.Kxc2 Qf5+ 13.Kc1 (16.587.796.696) 597
16 538:25 -1.04 1.Bxf7+ Kxf7 2.Qc4+ Be6 3.Qxd4 dxe5
4.Qa4 Qd4 5.Qxd4 exd4 6.Nf3 Bd7 7.Nxd4 Ng4
8.Nf3 h6 9.Bf4 Bc6 10.Bxc7 Bxc3+
11.bxc3 Rhc8 12.h3 Rxc7 13.hxg4 Rf8 (19.300.813.511) 597
______________________________________________________________
17 748:24 -0.73 1.exf6 Nxe2 2.fxg7 Rg8 3.Bxe2 Rxg7
4.Bh6 Rg8 5.Nf3 c6 6.O-O-O Qa5 7.Kb1 Be6
8.Be3 O-O-O 9.Nd4 Bd5 10.Bg4+ e6
11.Nxd5 cxd5 12.Bd2 b5 (26.731.489.648) 595
Difference between the two moves is less clear, and maybe the eval is very slightly going down for White after 7.exf6 but the quality of the PV node search is not actually that good, certainly not considering the number of cycles it takes. In general Blueberry's PV node search is more selective -because of the singular extensions, but there may be other factors- than the null window searches with which the other moves at the root are searched, in spite of using a much larger window! Original Fruit uses an infinite size α-β window even, for searching the first move, at every iteration. There must have been a reason for that
Sorry for incoherent output!
Eelco