Different behavior with different hash sizes. (Stockfish 1.9

Discussion of chess software programming and technical issues.

Moderator: Ras

Arsha Mahdavi
Posts: 27
Joined: Fri Jan 02, 2009 9:56 am
Full name: Arsha

Different behavior with different hash sizes. (Stockfish 1.9

Post by Arsha Mahdavi »

Hi

I analyzed the following position with two different hash sizes. (128 MB and 256 MB)

6k1/3qr1p1/1pn1pr2/p5Np/1nPPQP2/2B3P1/1R4K1/4R3 b - - 0 59

Stockfish was used as analyzing engine on a single core 32-bit CPU:

Starting from depth 15, Stockfish with 256 MB hash gives different score and PV compared with 128 MB one.

Stockfish 1.9 32-bit, single CPU

Hash 128:
  • 59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.09) Depth: 10 00:00:00 95kN
    59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.25) Depth: 10 00:00:00 127kN
    59...Rh6 60.Rbe2 Qd6 61.Ra1 h4 62.Bxb4 axb4 63.Ra8+ Nd8 64.c5 h3+ 65.Nxh3 bxc5 66.dxc5
    +/- (1.13) Depth: 10 00:00:01 258kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Kg1 Qh5 63.Qg2 Nd8 64.Qa8 Rd7 65.Qc8
    +/- (1.21) Depth: 11 00:00:02 491kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.Nxe6 Rxc4
    +/- (1.25) Depth: 12 00:00:02 696kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.dxe6 Qxc4 66.Qxc4 Rxc4 67.e7
    +/- (1.33) Depth: 13 00:00:03 829kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Bxb4 Nxb4 63.d5 Rxh4 64.d6 Rd7
    +/- (1.17) Depth: 13 00:00:04 1197kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Kh8 62.Rbb1 Qb8 63.Rh1 b5 64.cxb5 Qxb5 65.Bxb4 Nxb4 66.Qa8+ Re8 67.Nf7+ Kh7 68.Qxa5 Qxa5 69.Rxa5
    +/- (1.13) Depth: 13 00:00:05 1500kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.13) Depth: 14 00:00:07 2007kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.21) Depth: 15 00:00:08 2384kN
    59...Rh6 60.Rh1 Kh8 61.Re2 Qe8 62.Ree1 Na2 63.Bb2 a4 64.Ra1
    +/- (1.29) Depth: 15 00:00:10 3042kN
    59...Rh6 60.Rbe2 h4 61.Rh1 hxg3 62.Rxh6 gxh6 63.Nxe6
    +- (1.45) Depth: 15 00:00:14 4276kN
    59...Rh6 60.Rbe2 Kf8 61.Rh1 Nd8 62.Rb1 Ndc6 63.Ra1 Qe8 64.Rh1 Kg8 65.Ree1 Qd7 66.Re2 Kh8 67.Re3 Na2 68.Bb2 Nab4 69.Ra1 Qd6 70.Nf3 Qd7
    +/- (1.33) Depth: 15 00:00:20 6547kN
    59...Rh6 60.Rbe2 Kf8 61.Qf3 Kg8 62.f5 exf5 63.d5 h4 64.dxc6 Rxe2+ 65.Rxe2 h3+ 66.Nxh3 Qxc6 67.Qxc6 Nxc6 68.Ng5
    +- (1.53) Depth: 16 00:00:27 8877kN
    59...Rh6 60.Rbe2 Qc8 61.d5 exd5 62.Qxe7 Nxe7 63.Rxe7 Qf8 64.Re8 dxc4 65.Rxf8+ Kxf8 66.Ne6+ Kf7 67.Nxg7 Nd5 68.Be5 Rh7 69.Nf5 Kg6 70.Nh4+ Kf7 71.Kf3 Rh6
    +- (1.65) Depth: 16 00:00:33 10959kN
    59...Rh6 60.Rbe2 Qc8 61.d5 exd5 62.Qxe7 Nxe7 63.Rxe7 Qf8 64.Re8 dxc4 65.Rxf8+ Kxf8 66.Ne6+ Kf7 67.f5 Nd3 68.Rb1 Nb4 69.Bxb4 axb4 70.Rxb4 Rf6 71.Rxc4 Rxf5 72.Nd4 Rc5 73.Rb4 Rd5 74.Kf3 g6 75.Ke4
    +- (1.85) Depth: 17 00:00:44 15400kN

    (, HMK 05.10.2010)
Hash 256:
  • 59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.09) Depth: 10 00:00:01 95kN
    59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.25) Depth: 10 00:00:01 127kN
    59...Rh6 60.Rbe2 Qd6 61.Ra1 h4 62.Bxb4 axb4 63.Ra8+ Nd8 64.c5 h3+ 65.Nxh3 bxc5 66.dxc5
    +/- (1.13) Depth: 10 00:00:01 258kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Kg1 Qh5 63.Qg2 Nd8 64.Qa8 Rd7 65.Qc8
    +/- (1.21) Depth: 11 00:00:02 491kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.Nxe6 Rxc4
    +/- (1.25) Depth: 12 00:00:03 696kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.dxe6 Qxc4 66.Qxc4 Rxc4 67.e7
    +/- (1.33) Depth: 13 00:00:04 829kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Bxb4 Nxb4 63.d5 Rxh4 64.d6 Rd7
    +/- (1.17) Depth: 13 00:00:06 1197kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Kh8 62.Rbb1 Qb8 63.Rh1 b5 64.cxb5 Qxb5 65.Bxb4 Nxb4 66.Qa8+ Re8 67.Nf7+ Kh7 68.Qxa5 Qxa5 69.Rxa5
    +/- (1.13) Depth: 13 00:00:06 1500kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.13) Depth: 14 00:00:07 2007kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.21) Depth: 15 00:00:08 2384kN
    59...Rh6 60.Rh1 Kh8 61.Re2 Qe8 62.Ree1 Na2 63.Bb2 a4 64.Ra1
    +/- (1.29) Depth: 15 00:00:10 3042kN
    59...Rh6 60.Rh1 Kh8 61.Re2 Qe8 62.Ree1 Na2 63.Bb2 Nab4 64.g4 h4 65.Nf3 Kg8 66.Nxh4 a4 67.Nf3 Rf7 68.Rxh6 gxh6
    +/- (1.33) Depth: 15 00:00:12 3649kN
    59...Rh6 60.Rh1 Re8 61.Re2 Re7 62.Kg1 Qc8 63.Reh2 g6 64.Rb2 Qa6 65.Qe2 Qc8 66.Kg2 h4 67.gxh4 Qd7 68.Qe4
    +/- (1.21) Depth: 16 00:00:19 6218kN
    59...Rh6 60.Rh1 Re8 61.Re2 Re7 62.Re3 Qe8 63.Bxb4 axb4 64.d5 exd5 65.Qxd5+ Kf8
    +/- (1.25) Depth: 17 00:00:34 11692kN

    (, HMK 05.10.2010)
Some other engines, however don’t change their output when hash is resized. Here is the analysis of the same position when Booot 5.0 is used:


Booot 5.0 32-bit, single CPU

Hash 128:
  • 59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 10 00:00:00 145kN
    59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 11 00:00:00 196kN
    59...g6 60.Nf3 Qb7 61.Ne5 Nxe5 62.Qxb7 Rxb7 63.fxe5 Rf8 64.Bxb4 axb4 65.Rxb4 Ra8 66.Rb2 Kg7
    +/= (0.44) Depth: 12 00:00:04 902kN
    59...g6 60.Nf3 Rf5 61.Nh4 Rf6 62.Nxg6 Rg7 63.d5 Rfxg6 64.dxc6 Rxg3+ 65.Kh1 Qxc6 66.Qxc6 Nxc6 67.Bxg7 Kxg7 68.Rxb6
    +/- (0.84) Depth: 13 00:00:11 2596kN
    59...g6 60.Nf3 Qb7 61.Ne5 Rc7 62.Nxg6 Nxd4 63.Qxb7 Rxb7 64.Ne5 Nf5 65.Bxb4 axb4 66.Rxb4 Rg7 67.Rb3 Rf8
    +/- (0.80) Depth: 14 00:00:33 8091kN
    59...g6 60.Nf3 Kh7 61.Qb1 Rf5 62.Rbe2 Qd6 63.Kh2 Kh6 64.Nh4 Rf6 65.d5 exd5 66.Bxf6 Rxe2+ 67.Rxe2 Qxf6
    +/- (0.89) Depth: 15 00:00:54 12899kN

    (, HMK 05.10.2010)
Hash 256:
  • 59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 10 00:00:00 145kN
    59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 11 00:00:00 196kN
    59...g6 60.Nf3 Qb7 61.Ne5 Nxe5 62.Qxb7 Rxb7 63.fxe5 Rf8 64.Bxb4 axb4 65.Rxb4 Ra8 66.Rb2 Kg7
    +/= (0.44) Depth: 12 00:00:04 902kN
    59...g6 60.Nf3 Rf5 61.Nh4 Rf6 62.Nxg6 Rg7 63.d5 Rfxg6 64.dxc6 Rxg3+ 65.Kh1 Qxc6 66.Qxc6 Nxc6 67.Bxg7 Kxg7 68.Rxb6
    +/- (0.84) Depth: 13 00:00:12 2596kN
    59...g6 60.Nf3 Qb7 61.Ne5 Rc7 62.Nxg6 Nxd4 63.Qxb7 Rxb7 64.Ne5 Nf5 65.Bxb4 axb4 66.Rxb4 Rg7 67.Rb3 Rf8
    +/- (0.80) Depth: 14 00:00:33 8091kN
    59...g6 60.Nf3 Kh7 61.Qb1 Rf5 62.Rbe2 Qd6 63.Kh2 Kh6 64.Nh4 Rf6 65.d5 exd5 66.Bxf6 Rxe2+ 67.Rxe2 Qxf6
    +/- (0.89) Depth: 15 00:00:53 12899kN

    (, HMK 05.10.2010)
Does engines benefit from it? I'd greatly appreciate it if someone could enlighten me around that.
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Different behavior with different hash sizes. (Stockfish

Post by bob »

This is completely normal and common behaviour for all programs that use hashing.


Arsha Mahdavi wrote:Hi

I analyzed the following position with two different hash sizes. (128 MB and 256 MB)

6k1/3qr1p1/1pn1pr2/p5Np/1nPPQP2/2B3P1/1R4K1/4R3 b - - 0 59

Stockfish was used as analyzing engine on a single core 32-bit CPU:

Starting from depth 15, Stockfish with 256 MB hash gives different score and PV compared with 128 MB one.

Stockfish 1.9 32-bit, single CPU

Hash 128:
  • 59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.09) Depth: 10 00:00:00 95kN
    59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.25) Depth: 10 00:00:00 127kN
    59...Rh6 60.Rbe2 Qd6 61.Ra1 h4 62.Bxb4 axb4 63.Ra8+ Nd8 64.c5 h3+ 65.Nxh3 bxc5 66.dxc5
    +/- (1.13) Depth: 10 00:00:01 258kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Kg1 Qh5 63.Qg2 Nd8 64.Qa8 Rd7 65.Qc8
    +/- (1.21) Depth: 11 00:00:02 491kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.Nxe6 Rxc4
    +/- (1.25) Depth: 12 00:00:02 696kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.dxe6 Qxc4 66.Qxc4 Rxc4 67.e7
    +/- (1.33) Depth: 13 00:00:03 829kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Bxb4 Nxb4 63.d5 Rxh4 64.d6 Rd7
    +/- (1.17) Depth: 13 00:00:04 1197kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Kh8 62.Rbb1 Qb8 63.Rh1 b5 64.cxb5 Qxb5 65.Bxb4 Nxb4 66.Qa8+ Re8 67.Nf7+ Kh7 68.Qxa5 Qxa5 69.Rxa5
    +/- (1.13) Depth: 13 00:00:05 1500kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.13) Depth: 14 00:00:07 2007kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.21) Depth: 15 00:00:08 2384kN
    59...Rh6 60.Rh1 Kh8 61.Re2 Qe8 62.Ree1 Na2 63.Bb2 a4 64.Ra1
    +/- (1.29) Depth: 15 00:00:10 3042kN
    59...Rh6 60.Rbe2 h4 61.Rh1 hxg3 62.Rxh6 gxh6 63.Nxe6
    +- (1.45) Depth: 15 00:00:14 4276kN
    59...Rh6 60.Rbe2 Kf8 61.Rh1 Nd8 62.Rb1 Ndc6 63.Ra1 Qe8 64.Rh1 Kg8 65.Ree1 Qd7 66.Re2 Kh8 67.Re3 Na2 68.Bb2 Nab4 69.Ra1 Qd6 70.Nf3 Qd7
    +/- (1.33) Depth: 15 00:00:20 6547kN
    59...Rh6 60.Rbe2 Kf8 61.Qf3 Kg8 62.f5 exf5 63.d5 h4 64.dxc6 Rxe2+ 65.Rxe2 h3+ 66.Nxh3 Qxc6 67.Qxc6 Nxc6 68.Ng5
    +- (1.53) Depth: 16 00:00:27 8877kN
    59...Rh6 60.Rbe2 Qc8 61.d5 exd5 62.Qxe7 Nxe7 63.Rxe7 Qf8 64.Re8 dxc4 65.Rxf8+ Kxf8 66.Ne6+ Kf7 67.Nxg7 Nd5 68.Be5 Rh7 69.Nf5 Kg6 70.Nh4+ Kf7 71.Kf3 Rh6
    +- (1.65) Depth: 16 00:00:33 10959kN
    59...Rh6 60.Rbe2 Qc8 61.d5 exd5 62.Qxe7 Nxe7 63.Rxe7 Qf8 64.Re8 dxc4 65.Rxf8+ Kxf8 66.Ne6+ Kf7 67.f5 Nd3 68.Rb1 Nb4 69.Bxb4 axb4 70.Rxb4 Rf6 71.Rxc4 Rxf5 72.Nd4 Rc5 73.Rb4 Rd5 74.Kf3 g6 75.Ke4
    +- (1.85) Depth: 17 00:00:44 15400kN

    (, HMK 05.10.2010)
Hash 256:
  • 59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.09) Depth: 10 00:00:01 95kN
    59...g6 60.Rbe2 Qd6 61.Qb1 Nxd4 62.Ne4
    +/- (1.25) Depth: 10 00:00:01 127kN
    59...Rh6 60.Rbe2 Qd6 61.Ra1 h4 62.Bxb4 axb4 63.Ra8+ Nd8 64.c5 h3+ 65.Nxh3 bxc5 66.dxc5
    +/- (1.13) Depth: 10 00:00:01 258kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Kg1 Qh5 63.Qg2 Nd8 64.Qa8 Rd7 65.Qc8
    +/- (1.21) Depth: 11 00:00:02 491kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.Nxe6 Rxc4
    +/- (1.25) Depth: 12 00:00:03 696kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qc8 62.Rh1 Qa6 63.Bxb4 Nxb4 64.d5 Rc7 65.dxe6 Qxc4 66.Qxc4 Rxc4 67.e7
    +/- (1.33) Depth: 13 00:00:04 829kN
    59...Rh6 60.Rbe2 h4 61.gxh4 Qe8 62.Bxb4 Nxb4 63.d5 Rxh4 64.d6 Rd7
    +/- (1.17) Depth: 13 00:00:06 1197kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Kh8 62.Rbb1 Qb8 63.Rh1 b5 64.cxb5 Qxb5 65.Bxb4 Nxb4 66.Qa8+ Re8 67.Nf7+ Kh7 68.Qxa5 Qxa5 69.Rxa5
    +/- (1.13) Depth: 13 00:00:06 1500kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.13) Depth: 14 00:00:07 2007kN
    59...Rh6 60.Rh1 Qb7 61.Ra1 Qc8 62.Re2 h4 63.gxh4 Qf8 64.Bxb4 Nxb4 65.d5 Rxh4 66.d6
    +/- (1.21) Depth: 15 00:00:08 2384kN
    59...Rh6 60.Rh1 Kh8 61.Re2 Qe8 62.Ree1 Na2 63.Bb2 a4 64.Ra1
    +/- (1.29) Depth: 15 00:00:10 3042kN
    59...Rh6 60.Rh1 Kh8 61.Re2 Qe8 62.Ree1 Na2 63.Bb2 Nab4 64.g4 h4 65.Nf3 Kg8 66.Nxh4 a4 67.Nf3 Rf7 68.Rxh6 gxh6
    +/- (1.33) Depth: 15 00:00:12 3649kN
    59...Rh6 60.Rh1 Re8 61.Re2 Re7 62.Kg1 Qc8 63.Reh2 g6 64.Rb2 Qa6 65.Qe2 Qc8 66.Kg2 h4 67.gxh4 Qd7 68.Qe4
    +/- (1.21) Depth: 16 00:00:19 6218kN
    59...Rh6 60.Rh1 Re8 61.Re2 Re7 62.Re3 Qe8 63.Bxb4 axb4 64.d5 exd5 65.Qxd5+ Kf8
    +/- (1.25) Depth: 17 00:00:34 11692kN

    (, HMK 05.10.2010)
Some other engines, however don’t change their output when hash is resized. Here is the analysis of the same position when Booot 5.0 is used:


Booot 5.0 32-bit, single CPU

Hash 128:
  • 59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 10 00:00:00 145kN
    59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 11 00:00:00 196kN
    59...g6 60.Nf3 Qb7 61.Ne5 Nxe5 62.Qxb7 Rxb7 63.fxe5 Rf8 64.Bxb4 axb4 65.Rxb4 Ra8 66.Rb2 Kg7
    +/= (0.44) Depth: 12 00:00:04 902kN
    59...g6 60.Nf3 Rf5 61.Nh4 Rf6 62.Nxg6 Rg7 63.d5 Rfxg6 64.dxc6 Rxg3+ 65.Kh1 Qxc6 66.Qxc6 Nxc6 67.Bxg7 Kxg7 68.Rxb6
    +/- (0.84) Depth: 13 00:00:11 2596kN
    59...g6 60.Nf3 Qb7 61.Ne5 Rc7 62.Nxg6 Nxd4 63.Qxb7 Rxb7 64.Ne5 Nf5 65.Bxb4 axb4 66.Rxb4 Rg7 67.Rb3 Rf8
    +/- (0.80) Depth: 14 00:00:33 8091kN
    59...g6 60.Nf3 Kh7 61.Qb1 Rf5 62.Rbe2 Qd6 63.Kh2 Kh6 64.Nh4 Rf6 65.d5 exd5 66.Bxf6 Rxe2+ 67.Rxe2 Qxf6
    +/- (0.89) Depth: 15 00:00:54 12899kN

    (, HMK 05.10.2010)
Hash 256:
  • 59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 10 00:00:00 145kN
    59...g6 60.Qe3 Qd8 61.Kg1 Qc8 62.Qe4 Qe8 63.Kh2 Qc8 64.Bxb4 Nxb4
    +/= (0.27) Depth: 11 00:00:00 196kN
    59...g6 60.Nf3 Qb7 61.Ne5 Nxe5 62.Qxb7 Rxb7 63.fxe5 Rf8 64.Bxb4 axb4 65.Rxb4 Ra8 66.Rb2 Kg7
    +/= (0.44) Depth: 12 00:00:04 902kN
    59...g6 60.Nf3 Rf5 61.Nh4 Rf6 62.Nxg6 Rg7 63.d5 Rfxg6 64.dxc6 Rxg3+ 65.Kh1 Qxc6 66.Qxc6 Nxc6 67.Bxg7 Kxg7 68.Rxb6
    +/- (0.84) Depth: 13 00:00:12 2596kN
    59...g6 60.Nf3 Qb7 61.Ne5 Rc7 62.Nxg6 Nxd4 63.Qxb7 Rxb7 64.Ne5 Nf5 65.Bxb4 axb4 66.Rxb4 Rg7 67.Rb3 Rf8
    +/- (0.80) Depth: 14 00:00:33 8091kN
    59...g6 60.Nf3 Kh7 61.Qb1 Rf5 62.Rbe2 Qd6 63.Kh2 Kh6 64.Nh4 Rf6 65.d5 exd5 66.Bxf6 Rxe2+ 67.Rxe2 Qxf6
    +/- (0.89) Depth: 15 00:00:53 12899kN

    (, HMK 05.10.2010)
Does engines benefit from it? I'd greatly appreciate it if someone could enlighten me around that.
Top
Arsha Mahdavi
Posts: 27
Joined: Fri Jan 02, 2009 9:56 am
Full name: Arsha

Re: Different behavior with different hash sizes. (Stockfish

Post by Arsha Mahdavi »

What is the cause of this behavior?

And besides, I fail to see "ALL engines". I quickly analyzed a few other positions with both Booot 5.0 and Stockfish 1.9. Stockfish changes its score and "nodes counted" after a certain depth, but not Booot. They both use hashing.
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Different behavior with different hash sizes. (Stockfish

Post by bob »

Arsha Mahdavi wrote:What is the cause of this behavior?

And besides, I fail to see "ALL engines". I quickly analyzed a few other positions with both Booot 5.0 and Stockfish 1.9. Stockfish changes its score and "nodes counted" after a certain depth, but not Booot. They both use hashing.
Typically, if you change the hash size, you change the hash hits, and due to hash table "grafting" you search a different tree. It is perfectly normal for a particular program to produce the same scores using different hash sizes for some positions, and different scores with different hash sizes for other positions. And sometimes even different PVs or different best moves as well.

Hashing is based on a random-number-generated hash signature, and everyone does not use either the same random numbers, nor the same hash replacement schemes when two different positions map to the same hash table entry.

All this means is that some programs will behave in one way, others will behave in a different way, given the same set of positions. But if a single program never produces a different score or move when varying the hash size, it either has a bug in the hash implementation, or else a severe efficiency issue that can be improved.

A good example is typically an endgame position like fine 70. I have seen various versions of Crafty solve this anywhere from 18 plies to 24 plies deep, depending on the hash size setting. It is a 26 ply deep combination, finding it sooner requires some hash table help...
Top
Arsha Mahdavi
Posts: 27
Joined: Fri Jan 02, 2009 9:56 am
Full name: Arsha

Re: Different behavior with different hash sizes. (Stockfish

Post by Arsha Mahdavi »

bob wrote: Typically, if you change the hash size, you change the hash hits, and due to hash table "grafting" you search a different tree.
Thanks Bob. I always thought greater the hash size, greater the chance of hash hits, so less nodes to be counted. But when you say “it searches a different tree” it makes sense that it’s not necessarily always true. Am I correctly understood?
bob wrote: But if a single program never produces a different score or move when varying the hash size, it either has a bug in the hash implementation, or else a severe efficiency issue that can be improved.
Um… I thought otherwise!
Can we decide hash efficiency by just seeing the engine output? Times ago I took a ~2250 Elo engine and tried to improve its search function and correcting some bugs. I also changed its hash probing and replacement method. Now I completely gave up chess programming!

Here Lime 66 (Former chess program of Richard Allbert) searches lesser nodes when using less hash size!?:

Lime 66, 64 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 200kN
    16...c6 17.Qc3 a5 18.Ne5 Ba6 19.Rc1 Be2 20.Rxa5 Rxa5 21.Nxa5
    +/- (0.79) Depth: 7 00:00:02 922kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:07 3565kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qd8
    +/- (0.86) Depth: 9 00:00:30 14439kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4
    +/- (0.84) Depth: 10 00:00:46 22176kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:01:20 38455kN
Lime 66, 256 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 200kN
    16...c6 17.Qc3 a5 18.Ne5 Ba6 19.Rc1 Be2 20.Rxa5 Rxa5 21.Nxa5
    +/- (0.79) Depth: 7 00:00:02 898kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:07 3532kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qd8
    +/- (0.86) Depth: 9 00:00:36 16942kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4
    +/- (0.84) Depth: 10 00:00:53 25359kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:01:23 39819kN
But from the output of Lime 67 (My modified version of Lime 66) could we decide that it uses the hash table better?
I don’t remember most of the code I replaced for hash_store() function. It’s times ago. I added hash priority, etc.. (I inspired by some other open source engines)

Lime 67, 64 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 90kN
    16...Nc6 17.Bd3 Rb8 18.Nc5 Rb4 19.Qc2 Rxa4 20.Qxa4
    +/- (0.73) Depth: 7 00:00:00 344kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:02 958kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 g6 20.Bxc6 dxc6
    +/- (0.88) Depth: 9 00:00:03 1784kN
    16...c6 17.Qd2 Rb8 18.Ne5 Rb5 19.Rc1 d6 20.Nxf7 Kxf7 21.Rxb4 Nxe4 22.Bxe4 Qxe4
    +/- (0.84) Depth: 10 00:00:12 6095kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:00:20 10018kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4 22.Nd2
    +/- (0.89) Depth: 12 00:00:33 16412kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4 Nxd3 22.Bxd3 Be6
    +/- (0.80) Depth: 13 00:01:37 48363kN

Lime 67, 256 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 90kN
    16...Nc6 17.Bd3 Rb8 18.Nc5 Rb4 19.Qc2 Rxa4 20.Qxa4
    +/- (0.73) Depth: 7 00:00:00 344kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:02 957kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 g6 20.Bxc6 dxc6
    +/- (0.88) Depth: 9 00:00:03 1782kN
    16...c6 17.Qd2 Rb8 18.Ne5 Rb5 19.Rc1 d6 20.Nxf7 Kxf7 21.Rxb4 Nxe4 22.Bxe4 Qxe4
    +/- (0.84) Depth: 10 00:00:12 6068kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:00:20 9977kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4 22.Nd2
    +/- (0.89) Depth: 12 00:00:32 15894kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4 Nxd3 22.Bxd3 Be6
    +/- (0.80) Depth: 13 00:01:35 46965kN
Top
Dann Corbit
Posts: 12781
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: Different behavior with different hash sizes. (Stockfish

Post by Dann Corbit »

Arsha Mahdavi wrote:
bob wrote: Typically, if you change the hash size, you change the hash hits, and due to hash table "grafting" you search a different tree.
Thanks Bob. I always thought greater the hash size, greater the chance of hash hits, so less nodes to be counted. But when you say “it searches a different tree” it makes sense that it’s not necessarily always true. Am I correctly understood?
bob wrote: But if a single program never produces a different score or move when varying the hash size, it either has a bug in the hash implementation, or else a severe efficiency issue that can be improved.
Um… I thought otherwise!
Can we decide hash efficiency by just seeing the engine output? Times ago I took a ~2250 Elo engine and tried to improve its search function and correcting some bugs. I also changed its hash probing and replacement method. Now I completely gave up chess programming!

Here Lime 66 (Former chess program of Richard Allbert) searches lesser nodes when using less hash size!?:
It depends on how the accounting takes place.

Many programs increment nodes immediately when search() is entered. For these programs, we expect nodes per second to increase with bigger hash. A hash hit counts as a node for these programs.

Other programs increment nodes only after the possible return from a hash table lookup has occurred. For these programs, we expect nodes per second to go down when the hash table increases in size. A hash hit short-circuit is not counted as a node for these programs.

In all cases, if the hash table is working properly, we expect time to achieve the next ply to decrease (on average) as the hash table gets bigger.

Lime 66, 64 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 200kN
    16...c6 17.Qc3 a5 18.Ne5 Ba6 19.Rc1 Be2 20.Rxa5 Rxa5 21.Nxa5
    +/- (0.79) Depth: 7 00:00:02 922kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:07 3565kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qd8
    +/- (0.86) Depth: 9 00:00:30 14439kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4
    +/- (0.84) Depth: 10 00:00:46 22176kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:01:20 38455kN
Lime 66, 256 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 200kN
    16...c6 17.Qc3 a5 18.Ne5 Ba6 19.Rc1 Be2 20.Rxa5 Rxa5 21.Nxa5
    +/- (0.79) Depth: 7 00:00:02 898kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:07 3532kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qd8
    +/- (0.86) Depth: 9 00:00:36 16942kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4
    +/- (0.84) Depth: 10 00:00:53 25359kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:01:23 39819kN
But from the output of Lime 67 (My modified version of Lime 66) could we decide that it uses the hash table better?
I don’t remember most of the code I replaced for hash_store() function. It’s times ago. I added hash priority, etc.. (I inspired by some other open source engines)

Lime 67, 64 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 90kN
    16...Nc6 17.Bd3 Rb8 18.Nc5 Rb4 19.Qc2 Rxa4 20.Qxa4
    +/- (0.73) Depth: 7 00:00:00 344kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:02 958kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 g6 20.Bxc6 dxc6
    +/- (0.88) Depth: 9 00:00:03 1784kN
    16...c6 17.Qd2 Rb8 18.Ne5 Rb5 19.Rc1 d6 20.Nxf7 Kxf7 21.Rxb4 Nxe4 22.Bxe4 Qxe4
    +/- (0.84) Depth: 10 00:00:12 6095kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:00:20 10018kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4 22.Nd2
    +/- (0.89) Depth: 12 00:00:33 16412kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4 Nxd3 22.Bxd3 Be6
    +/- (0.80) Depth: 13 00:01:37 48363kN

Lime 67, 256 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 90kN
    16...Nc6 17.Bd3 Rb8 18.Nc5 Rb4 19.Qc2 Rxa4 20.Qxa4
    +/- (0.73) Depth: 7 00:00:00 344kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:02 957kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 g6 20.Bxc6 dxc6
    +/- (0.88) Depth: 9 00:00:03 1782kN
    16...c6 17.Qd2 Rb8 18.Ne5 Rb5 19.Rc1 d6 20.Nxf7 Kxf7 21.Rxb4 Nxe4 22.Bxe4 Qxe4
    +/- (0.84) Depth: 10 00:00:12 6068kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:00:20 9977kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4 22.Nd2
    +/- (0.89) Depth: 12 00:00:32 15894kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4 Nxd3 22.Bxd3 Be6
    +/- (0.80) Depth: 13 00:01:35 46965kN
Top
Arsha Mahdavi
Posts: 27
Joined: Fri Jan 02, 2009 9:56 am
Full name: Arsha

Re: Different behavior with different hash sizes. (Stockfish

Post by Arsha Mahdavi »

Hello Dann. If you again look at analysis I have provided, you’ll see that I compared Lime 66 with Lime 66, and Lime 67 with Lime 67. And in that case of Lime 66 “achieving the next ply will increase as the hash table gets bigger”.

OK, I correct myself. I did test a few other positions both with Lim 66 and Lime 67 and sometimes my version (Lime 67) counts more nodes as the hash size gets bigger. So it’s not a general case!
Top
Dann Corbit
Posts: 12781
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: Different behavior with different hash sizes. (Stockfish

Post by Dann Corbit »

Arsha Mahdavi wrote:Hello Dann. If you again look at analysis I have provided, you’ll see that I compared Lime 66 with Lime 66, and Lime 67 with Lime 67. And in that case of Lime 66 “achieving the next ply will increase as the hash table gets bigger”.

OK, I correct myself. I did test a few other positions both with Lim 66 and Lime 67 and sometimes my version (Lime 67) counts more nodes as the hash size gets bigger. So it’s not a general case!
If you take a large collection of different types of positions and test for time to ply, I think you can effectively measure the effectiveness of your strategy.
Top
ernest
Posts: 2048
Joined: Wed Mar 08, 2006 8:30 pm

Re: Different behavior with different hash sizes. (Stockfish

Post by ernest »

bob wrote: It is perfectly normal for a particular program to produce the same scores using different hash sizes for some positions
Hi Bob,

I am extremely surprised at that, at least when you look at PVs (and nodes) obtained after some time elapsed, when the hash table has been overly "filled" - don't pick at me for the word!

Of course, if you have Gigabyte large hashtables, and you look at PVs/nodes after 1 second (or less), you may have the same for 1 or 2 GB hash size... :)
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Different behavior with different hash sizes. (Stockfish

Post by bob »

Arsha Mahdavi wrote:
bob wrote: Typically, if you change the hash size, you change the hash hits, and due to hash table "grafting" you search a different tree.
Thanks Bob. I always thought greater the hash size, greater the chance of hash hits, so less nodes to be counted. But when you say “it searches a different tree” it makes sense that it’s not necessarily always true. Am I correctly understood?
Yes. In fact, some times hashing _increases_ the size of the tree, because of this grafting issue. But in doing so, you actually get a better search result than if you didn't have hashing at all. That is, an N-ply search with hashing can give you a more accurate score than an N-ply search without hashing. For example, without hashing, fine 70 takes 26 plies to see winning a pawn. With hashing, you can see the right answer anywhere from 18 plies on...



bob wrote: But if a single program never produces a different score or move when varying the hash size, it either has a bug in the hash implementation, or else a severe efficiency issue that can be improved.
Um… I thought otherwise!
Can we decide hash efficiency by just seeing the engine output? Times ago I took a ~2250 Elo engine and tried to improve its search function and correcting some bugs. I also changed its hash probing and replacement method. Now I completely gave up chess programming!

Here Lime 66 (Former chess program of Richard Allbert) searches lesser nodes when using less hash size!?:
Hash hits can do two things. (1) reduce the size of the tree by saving the effort of searching beyond the hash hit. (2) possibly increase the size of the tree because it introduces deeper searches than expected, which provides more accurate information.

In short, you can save time, or possibly gain increased accuracy. And sometimes even both.


Lime 66, 64 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 200kN
    16...c6 17.Qc3 a5 18.Ne5 Ba6 19.Rc1 Be2 20.Rxa5 Rxa5 21.Nxa5
    +/- (0.79) Depth: 7 00:00:02 922kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:07 3565kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qd8
    +/- (0.86) Depth: 9 00:00:30 14439kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4
    +/- (0.84) Depth: 10 00:00:46 22176kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:01:20 38455kN
Lime 66, 256 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 200kN
    16...c6 17.Qc3 a5 18.Ne5 Ba6 19.Rc1 Be2 20.Rxa5 Rxa5 21.Nxa5
    +/- (0.79) Depth: 7 00:00:02 898kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:07 3532kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qd8
    +/- (0.86) Depth: 9 00:00:36 16942kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4
    +/- (0.84) Depth: 10 00:00:53 25359kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:01:23 39819kN
But from the output of Lime 67 (My modified version of Lime 66) could we decide that it uses the hash table better?
I don’t remember most of the code I replaced for hash_store() function. It’s times ago. I added hash priority, etc.. (I inspired by some other open source engines)

Lime 67, 64 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 90kN
    16...Nc6 17.Bd3 Rb8 18.Nc5 Rb4 19.Qc2 Rxa4 20.Qxa4
    +/- (0.73) Depth: 7 00:00:00 344kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:02 958kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 g6 20.Bxc6 dxc6
    +/- (0.88) Depth: 9 00:00:03 1784kN
    16...c6 17.Qd2 Rb8 18.Ne5 Rb5 19.Rc1 d6 20.Nxf7 Kxf7 21.Rxb4 Nxe4 22.Bxe4 Qxe4
    +/- (0.84) Depth: 10 00:00:12 6095kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:00:20 10018kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4 22.Nd2
    +/- (0.89) Depth: 12 00:00:33 16412kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4 Nxd3 22.Bxd3 Be6
    +/- (0.80) Depth: 13 00:01:37 48363kN

Lime 67, 256 MB
  • 16...Nc6 17.Bd3 Bb7 18.Nc5
    +/= (0.65) Depth: 4 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 5 00:00:00
    16...Nc6 17.Nc5 d6 18.e5 dxe5 19.Nxe5 Nxe5 20.dxe5
    +/= (0.63) Depth: 6 00:00:00 90kN
    16...Nc6 17.Bd3 Rb8 18.Nc5 Rb4 19.Qc2 Rxa4 20.Qxa4
    +/- (0.73) Depth: 7 00:00:00 344kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 Kh8 20.Bxc6 dxc6
    +/- (0.84) Depth: 8 00:00:02 957kN
    16...Nc6 17.e5 Ng4 18.Be4 Rb8 19.Qc2 g6 20.Bxc6 dxc6
    +/- (0.88) Depth: 9 00:00:03 1782kN
    16...c6 17.Qd2 Rb8 18.Ne5 Rb5 19.Rc1 d6 20.Nxf7 Kxf7 21.Rxb4 Nxe4 22.Bxe4 Qxe4
    +/- (0.84) Depth: 10 00:00:12 6068kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4
    +/- (0.89) Depth: 11 00:00:20 9977kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Nxd3 21.Bxd3 Bg4 22.Nd2
    +/- (0.89) Depth: 12 00:00:32 15894kN
    16...c6 17.Qc3 Rb8 18.Nc5 a5 19.Rxa5 d6 20.Nd3 Qc7 21.Ra4 Nxd3 22.Bxd3 Be6
    +/- (0.80) Depth: 13 00:01:35 46965kN
Top

Return to “Computer Chess Club: Programming and Technical Discussions”