Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Hash problem or not?
- - By genorb (**) Date 2007-06-24 12:29
Hi all,

First of all perhaps what I report here is totally normal and then forgive me. But I think this is anyway strange.

First how the "story" began: When I am testing chess engine, I use my desktop computer for blitz and my laptop for bullet. I also use test suites to test the engine. I was testing Rybka 2.3.2a with the LCTII test and I first tried on my laptop where I use 32MB for hash. Then I redo the test on my desktop where I use 256MB and I was surprised to see that Rybka was able to find the best move on a given position on my slower laptop and was not able to find it on my desktop computer.

Then I started to make tests only on my desktop computer:

AMD Athlon 64 Processor 3200+ 2200 MHz with 1024 MB memory, Microsoft Windows XP Professional Service Pack 2 (Build 2600) (32bits). Axon-Benchmark-4 (00:00:29.0 sec.) [3175776 pps.] PowX= 9.894

I analyzed the following position with Rybka 2.3.2a on this computer and changed the size of the hash. When I use 256MB or 128MB I get essentially the same result, only the figures for the evalution score can change a bit. But when I use 32MB for the hash then I get a complete different analysis.

Is it a normal thing??

I have also to say that the best move for this position is normally the one I get with 32MB for the hash!!

Here is the position:

bn6/1q4n1/1p1p1kp1/2pPp1pp/1PP1P1P1/3N1P1P/4B1K1/2Q2N2 w - - 0 1


Here are the analysis:

HASH : 256MB

Rybka 2.3.2a:
   5  00:00        10.806  100.594  +0.75  b4xc5 b6xc5 Nf1g3
   5  00:00        14.023  83.003  +0.91  Nf1e3 c5xb4
   6  00:00        18.801  87.510  +0.79  Nf1e3 c5xb4 Nd3xb4 Nb8d7
   6  00:00        21.570  87.998  +0.87  b4b5 Qb7c7 Qc1d2
   7  00:00        42.987  90.760  +0.72  b4b5 Qb7a7 Qc1e3 Nb8d7
   8  00:01        78.883  89.058  +0.77  b4b5 Qb7a7 Be2d1 Qa7a2+ Nf1d2 Nb8d7
   9  00:01       135.325  95.304  +0.64  b4b5 Qb7e7 Nf1e3 Kf6f7 Qc1a1 Ba8b7
   9  00:02       213.476  95.792  +0.65  Nf1e3 Nb8d7 Qc1a1 Kf6f7 Be2d1 c5xb4
  10  00:04       379.582  96.401  +0.68  Nf1e3 Nb8d7 g4xh5 g6xh5 h3h4 g5xh4 Qc1h1 Kf6f7 Qh1xh4
  11  00:05       484.212  97.624  +0.68  Nf1e3 Nb8d7 g4xh5 g6xh5 h3h4 g5xh4 Qc1h1 Kf6f7 Qh1xh4 Qb7c7
  12  00:10     1.040.028  99.643  +0.55  Nf1e3 c5xb4 Nd3xb4 Nb8d7 Qc1a3 Nd7c5 Nb4c6 Qb7a6 Qa3b2 Ng7e6
  12  00:12     1.163.600  100.069  +0.57  b4b5 Qb7e7 Qc1a1 Ba8b7 Nf1e3 Kf6f7 Qa1a3 Qe7c7 Be2d1
  12  00:22     1.924.242  90.072  +1.43  b4xc5 b6xc5 h3h4 g5xh4 f3f4 h5xg4 f4xe5+ d6xe5 Be2xg4 Nb8d7 Qc1h6 Qb7b3 Qh6xh4+ Kf6f7
  13  00:30     2.512.018  84.987  +1.50  b4xc5 b6xc5 h3h4 g5xh4 f3f4 Nb8d7 f4xe5+ Nd7xe5 Qc1f4+ Kf6e7 Nd3xe5 d6xe5 Qf4xe5+ Ke7f8
  14  00:36     2.884.935  81.987  +1.54  b4xc5 b6xc5 h3h4 g5xh4 f3f4 Nb8d7 f4xe5+ Nd7xe5 Qc1f4+ Kf6e7 Nd3xe5 d6xe5 Qf4xe5+ Ke7f8
15  00:53     4.066.974  77.591  +1.65  b4xc5 b6xc5 h3h4 g5xh4 f3f4 e5xf4 Qc1xf4+ Kf6e7 g4xh5 Ng7xh5 Be2xh5 g6xh5 Nf1e3 Qb7b6
 

HASH : 128MB

Rybka 2.3.2a:
   5  00:00        10.806  87.820  +0.75  b4xc5 b6xc5 Nf1g3
   5  00:00        14.023  91.462  +0.91  Nf1e3 c5xb4
   6  00:00        18.801  87.510  +0.79  Nf1e3 c5xb4 Nd3xb4 Nb8d7
   6  00:00        21.570  82.725  +0.87  b4b5 Qb7c7 Qc1d2
   7  00:00        42.987  90.760  +0.72  b4b5 Qb7a7 Qc1e3 Nb8d7
   8  00:00        78.883  90.556  +0.77  b4b5 Qb7a7 Be2d1 Qa7a2+ Nf1d2 Nb8d7
   9  00:01       135.325  96.297  +0.64  b4b5 Qb7e7 Nf1e3 Kf6f7 Qc1a1 Ba8b7
   9  00:02       211.765  97.023  +0.65  Nf1e3 Nb8d7 Qc1a1 Kf6f7 Be2d1 c5xb4
  10  00:03       380.056  97.660  +0.68  Nf1e3 Nb8d7 g4xh5 g6xh5 h3h4 g5xh4 Qc1h1 Kf6f7 Qh1xh4
  11  00:04       482.170  98.728  +0.68  Nf1e3 Nb8d7 g4xh5 g6xh5 h3h4 g5xh4 Qc1h1 Kf6f7 Qh1xh4 Qb7c7
  12  00:10     1.020.291  100.691  +0.56  Nf1e3 c5xb4 Nd3xb4 Nb8d7 Qc1a3 Nd7c5 Qa3a2 Qb7c8 Qa2a7 Qc8b7
  12  00:11     1.142.068  101.130  +0.57  b4b5 Qb7e7 Qc1a1 Ba8b7 Nf1e3 Kf6f7 Qa1a3 Qe7c7 Be2d1
  12  00:22     1.955.507  89.928  +1.44  b4xc5 b6xc5 h3h4 g5xh4 f3f4 h5xg4 f4xe5+ d6xe5 Be2xg4 Qb7b3 Nd3xc5 Qb3b4 Nc5d3 Qb4b3
  13  00:30     2.537.471  85.014  +1.50  b4xc5 b6xc5 h3h4 g5xh4 f3f4 Nb8d7 f4xe5+ Nd7xe5 Qc1f4+ Kf6e7 Nd3xe5 d6xe5 Qf4xe5+ Ke7f8
  14  00:38     3.069.709  81.544  +1.57  b4xc5 b6xc5 h3h4 g5xh4 f3f4 Ng7e6 f4xe5+ Kf6g7 g4xh5 Ne6d4 Be2g4 Qb7b3 Qc1d2 Qb3xc4
  15  01:03     4.749.174  76.339  +1.77  b4xc5 b6xc5 h3h4 g5xh4 f3f4 Ng7e6 f4xe5+ d6xe5 g4xh5 g6g5 Nf1e3 Nb8d7 Qc1a1 Qb7b8
 

HASH : 32MB

Rybka 2.3.2a:
   5  00:00        10.806  87.820  +0.75  b4xc5 b6xc5 Nf1g3
   5  00:00        14.023  83.003  +0.91  Nf1e3 c5xb4
   6  00:00        18.801  87.510  +0.79  Nf1e3 c5xb4 Nd3xb4 Nb8d7
   6  00:00        21.570  83.036  +0.87  b4b5 Qb7c7 Qc1d2
   7  00:00        43.046  90.884  +0.72  b4b5 Qb7a7 Qc1e3 Nb8d7
   8  00:00        78.936  93.988  +0.77  b4b5 Qb7a7 Be2d1 Qa7a2+ Nf1d2 Nb8d7
   9  00:01       137.567  101.271  +0.64  b4b5 Qb7e7 Nf1e3 Kf6f7 Qc1a1 Ba8b7
   9  00:01       161.180  100.577  +0.75  Nf1e3 c5xb4 Nd3xb4 Nb8d7 Qc1a1 Nd7c5 Nb4c6
  10  00:02       272.086  101.870  +0.57  Nf1e3 c5xb4 Nd3xb4 Nb8d7 Qc1a3 Nd7c5 Kg2g3 Qb7c8
  10  00:03       315.856  102.972  +0.58  b4b5 Qb7e7 Nf1e3 Kf6f7 Qc1a1 Ba8b7 Kg2f2
  11  00:07       747.655  101.430  +0.60  b4b5 Qb7e7 Nf1e3 Kf6f7 Qc1a1 Ba8b7 Qa1a7 Qe7c7
  11  00:17     1.477.916  86.242  +0.89  h3h4 g5xh4 f3f4 Ng7e6 g4xh5 Ne6d4 Be2g4 c5xb4 f4xe5+ d6xe5 h5xg6 Qb7g7
  12  00:20     1.674.500  85.197  +1.04  h3h4 g5xh4 f3f4 Ng7e6 g4xh5 Ne6d4 Be2g4 c5xb4 f4xe5+ d6xe5 Qc1e1 Qb7e7
  13  00:31     2.508.897  80.559  +1.31  h3h4 g5xh4 f3f4 Ng7e6 g4xh5 Ne6d4 Be2g4 c5xb4 f4xe5+ d6xe5 Qc1e1 Qb7e7 Qe1xh4+ g6g5
  14  01:02     4.697.937  76.548  +1.38  h3h4 g5xh4 f3f4 c5xb4 f4xe5+ d6xe5 g4g5+ Kf6f7 Nd3xe5+ Kf7g8 Ne5xg6 h4h3+ Kg2xh3 Qb7d7+
  15  01:32     6.742.596  74.742  +1.45  h3h4 g5xh4 f3f4 c5xb4 f4xe5+ d6xe5 g4g5+ Kf6f7 Nd3xe5+ Kf7g8 Ne5xg6 h4h3+ Kg2xh3 Qb7d7+

Regards,

Fabian
Parent - - By Michael Waesch Date 2007-06-24 12:37
Did you clean hash between you tests of different sizes?

Mike
Parent - - By genorb (**) Date 2007-06-24 13:02
of course yes :)

can you repoduced this behavior? (I use single processor Rybka 2.3.2a)
Parent - - By Michael Waesch Date 2007-06-24 13:10
No, I can´t reproduce it. I constantly get the same evaluations, no matter which hash size is applied.

Mike
Parent - - By genorb (**) Date 2007-06-24 14:43
I just tested on my laptop too. I tried with 32MB and 128MB for the hash (I cannot test with 256MB because I don't have enough memory on that computer). And I get the same result : I have a different result for the analysis if I set 32MB or 128MB for the hash...??

To be complete I did the test with Arena 1.99beta4 and I use the default UCI option for Rybka except that I set "NalimovUsage" to "normally" and I display the win percentage to the hash usage, but I checked that this has no influence on that result.

I have 3 and 4 men tablebases.

If I can reproduce this behavior on 2 different computers (having by the way 2 different processors (Intel and AMD)), this must be true no? It is very strange that you cannot reproduce this...

Someone else can check this please?
Parent - - By Uri Blass (*****) Date 2007-06-24 14:57
I can reproduce it but
I do not think that it is strange behaviour.

rybka2.3.2a single processor 32 mbytes

New game
bn6/1q4n1/1p1p1kp1/2pPp1pp/1PP1P1P1/3N1P1P/4B1K1/2Q2N2 w - - 0 1


Analysis by Rybka 2.3.2a 32-bit :

1.b4xc5 b6xc5 2.Nf1-g3
  ±  (0.75)   Depth: 5   00:00:00
1.Nf1-e3 c5xb4
  ±  (0.91)   Depth: 5   00:00:00
1.Nf1-e3 c5xb4 2.Nd3xb4 Nb8-d7
  ±  (0.79)   Depth: 6   00:00:00  19kN
1.b4-b5 Qb7-c7 2.Qc1-d2
  ±  (0.87)   Depth: 6   00:00:00  22kN
1.b4-b5 Qb7-a7 2.Qc1-e3 Nb8-d7
  ±  (0.72)   Depth: 7   00:00:00  43kN
1.b4-b5 Qb7-a7 2.Be2-d1 Qa7-a2+ 3.Nf1-d2 Nb8-d7
  ±  (0.77)   Depth: 8   00:00:00  79kN
1.b4-b5 Qb7-e7 2.Nf1-e3 Kf6-f7 3.Qc1-a1 Ba8-b7
  ²  (0.64)   Depth: 9   00:00:01  138kN
1.Nf1-e3 c5xb4 2.Nd3xb4 Nb8-d7 3.Qc1-a1 Nd7-c5 4.Nb4-c6
  ±  (0.75)   Depth: 9   00:00:01  161kN
1.Nf1-e3 c5xb4 2.Nd3xb4 Nb8-d7 3.Qc1-a3 Nd7-c5 4.Kg2-g3 Qb7-c8
  ²  (0.57)   Depth: 10   00:00:03  272kN
1.b4-b5 Qb7-e7 2.Nf1-e3 Kf6-f7 3.Qc1-a1 Ba8-b7 4.Kg2-f2
  ²  (0.58)   Depth: 10   00:00:03  316kN
1.b4-b5 Qb7-e7 2.Nf1-e3 Kf6-f7 3.Qc1-a1 Ba8-b7 4.Qa1-a7 Qe7-c7
  ²  (0.60)   Depth: 11   00:00:08  748kN
1.h3-h4 g5xh4 2.f3-f4 Ng7-e6 3.g4xh5 Ne6-d4 4.Be2-g4 c5xb4 5.f4xe5+ d6xe5 6.h5xg6 Qb7-g7
  ±  (0.89)   Depth: 11   00:00:19  1478kN
1.h3-h4 g5xh4 2.f3-f4 Ng7-e6 3.g4xh5 Ne6-d4 4.Be2-g4 c5xb4 5.f4xe5+ d6xe5 6.Qc1-e1 Qb7-e7
  ±  (1.04)   Depth: 12   00:00:22  1675kN
1.h3-h4 g5xh4 2.f3-f4 Ng7-e6 3.g4xh5 Ne6-d4 4.Be2-g4 c5xb4 5.f4xe5+ d6xe5 6.Qc1-e1 Qb7-e7 7.Qe1xh4+ g6-g5
  ±  (1.31)   Depth: 13   00:00:36  2509kN

(,  24.06.2007)

128 mbytes

New game
bn6/1q4n1/1p1p1kp1/2pPp1pp/1PP1P1P1/3N1P1P/4B1K1/2Q2N2 w - - 0 1


Analysis by Rybka 2.3.2a 32-bit :

1.b4xc5 b6xc5 2.Nf1-g3
  ±  (0.75)   Depth: 5   00:00:00
1.Nf1-e3 c5xb4
  ±  (0.91)   Depth: 5   00:00:00
1.Nf1-e3 c5xb4 2.Nd3xb4 Nb8-d7
  ±  (0.79)   Depth: 6   00:00:00  19kN
1.b4-b5 Qb7-c7 2.Qc1-d2
  ±  (0.87)   Depth: 6   00:00:00  22kN
1.b4-b5 Qb7-a7 2.Qc1-e3 Nb8-d7
  ±  (0.72)   Depth: 7   00:00:00  43kN
1.b4-b5 Qb7-a7 2.Be2-d1 Qa7-a2+ 3.Nf1-d2 Nb8-d7
  ±  (0.77)   Depth: 8   00:00:00  79kN
1.b4-b5 Qb7-e7 2.Nf1-e3 Kf6-f7 3.Qc1-a1 Ba8-b7
  ²  (0.64)   Depth: 9   00:00:01  135kN
1.Nf1-e3 Nb8-d7 2.Qc1-a1 Kf6-f7 3.Be2-d1 c5xb4
  ²  (0.65)   Depth: 9   00:00:02  212kN
1.Nf1-e3 Nb8-d7 2.g4xh5 g6xh5 3.h3-h4 g5xh4 4.Qc1-h1 Kf6-f7 5.Qh1xh4
  ²  (0.68)   Depth: 10   00:00:04  380kN
1.Nf1-e3 Nb8-d7 2.g4xh5 g6xh5 3.h3-h4 g5xh4 4.Qc1-h1 Kf6-f7 5.Qh1xh4 Qb7-c7
  ²  (0.68)   Depth: 11   00:00:05  482kN
1.Nf1-e3 c5xb4 2.Nd3xb4 Nb8-d7 3.Qc1-a3 Nd7-c5 4.Qa3-a2 Qb7-c8 5.Qa2-a7 Qc8-b7
  ²  (0.56)   Depth: 12   00:00:11  1020kN
1.b4-b5 Qb7-e7 2.Qc1-a1 Ba8-b7 3.Nf1-e3 Kf6-f7 4.Qa1-a3 Qe7-c7 5.Be2-d1
  ²  (0.57)   Depth: 12   00:00:12  1142kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 h5xg4 4.f4xe5+ d6xe5 5.Be2xg4 Qb7-b3 6.Nd3xc5 Qb3-b4 7.Nc5-d3 Qb4-b3
  +-  (1.44)   Depth: 12   00:00:23  1956kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Nb8-d7 4.f4xe5+ Nd7xe5 5.Qc1-f4+ Kf6-e7 6.Nd3xe5 d6xe5 7.Qf4xe5+ Ke7-f8
  +-  (1.50)   Depth: 13   00:00:32  2537kN

(,  24.06.2007)
Parent - - By genorb (**) Date 2007-06-24 15:06
Thanks Uri for confirming this point.

OK you know chess programming better than me :) . But anyway I find it strange ;) . But perhaps there is a rationnal reason to explain this behavior... Remark that it does not happen with Rybka 2.3.1
Parent - - By Uri Blass (*****) Date 2007-06-24 17:59
It seems to me that both h4 and bxc5 bxc5 h4 are winning so I do not see bug in choosing bxc5 first

New game
bn6/1q4n1/1p1p1kp1/2pPp1pp/1PP1P1P1/3N1P1P/4B1K1/2Q2N2 w - - 0 1


Analysis by Rybka 2.3.2a 32-bit :

1.b4xc5 b6xc5 2.Nf1-g3
  ±  (0.75)   Depth: 5   00:00:00
1.Nf1-e3 c5xb4
  ±  (0.91)   Depth: 5   00:00:00
1.Nf1-e3 c5xb4 2.Nd3xb4 Nb8-d7
  ±  (0.79)   Depth: 6   00:00:00  19kN
1.b4-b5 Qb7-c7 2.Qc1-d2
  ±  (0.87)   Depth: 6   00:00:00  22kN
1.b4-b5 Qb7-a7 2.Qc1-e3 Nb8-d7
  ±  (0.72)   Depth: 7   00:00:00  43kN
1.b4-b5 Qb7-a7 2.Be2-d1 Qa7-a2+ 3.Nf1-d2 Nb8-d7
  ±  (0.77)   Depth: 8   00:00:01  79kN
1.b4-b5 Qb7-e7 2.Nf1-e3 Kf6-f7 3.Qc1-a1 Ba8-b7
  ²  (0.64)   Depth: 9   00:00:01  135kN
1.Nf1-e3 Nb8-d7 2.Qc1-a1 Kf6-f7 3.Be2-d1 c5xb4
  ²  (0.65)   Depth: 9   00:00:02  213kN
1.Nf1-e3 Nb8-d7 2.g4xh5 g6xh5 3.h3-h4 g5xh4 4.Qc1-h1 Kf6-f7 5.Qh1xh4
  ²  (0.68)   Depth: 10   00:00:04  380kN
1.Nf1-e3 Nb8-d7 2.g4xh5 g6xh5 3.h3-h4 g5xh4 4.Qc1-h1 Kf6-f7 5.Qh1xh4 Qb7-c7
  ²  (0.68)   Depth: 11   00:00:06  484kN
1.Nf1-e3 c5xb4 2.Nd3xb4 Nb8-d7 3.Qc1-a3 Nd7-c5 4.Nb4-c6 Qb7-a6 5.Qa3-b2 Ng7-e6
  ²  (0.55)   Depth: 12   00:00:12  1091kN
1.b4-b5 Qb7-e7 2.Qc1-a1 Ba8-b7 3.Nf1-e3 Kf6-f7 4.Qa1-a3 Qe7-c7 5.Be2-d1
  ²  (0.57)   Depth: 12   00:00:14  1212kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 h5xg4 4.f4xe5+ d6xe5 5.Be2xg4 Nb8-d7 6.Qc1-h6 Qb7-b3 7.Qh6xh4+ Kf6-f7
  +-  (1.43)   Depth: 12   00:00:25  1986kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Ng7-e6 4.f4xe5+ d6xe5 5.g4xh5 Ne6-d4 6.Be2-g4 Nb8-a6 7.h5xg6 Na6-b4
  ±  (1.32)   Depth: 13   00:00:35  2605kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Ng7-e6 4.f4xe5+ d6xe5 5.g4xh5 Ne6-d4 6.Be2-g4 Qb7-e7 7.Nf1-e3 Ba8-b7
  +-  (1.61)   Depth: 14   00:00:43  3097kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Ng7-e6 4.f4xe5+ d6xe5 5.g4xh5 Ne6-d4 6.Be2-g4 Qb7-b3 7.Nd3xc5 Qb3-a2+
  +-  (1.56)   Depth: 15   00:00:49  3492kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Ng7-e6 4.f4xe5+ d6xe5 5.g4xh5 Ne6-d4 6.Be2-g4 Qb7-e7 7.Nf1-e3 Kf6-g7
  +-  (1.58)   Depth: 16   00:01:05  4465kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Ng7-e6 4.f4xe5+ d6xe5 5.g4xh5 Ne6-d4 6.Be2-g4 Qb7-e7 7.Nf1-e3 Kf6-g7
  +-  (1.77)   Depth: 17   00:02:18  8742kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Ng7-e6 4.f4xe5+ d6xe5 5.g4xh5 Ne6-d4 6.Be2-g4 Qb7-e7 7.Nf1-e3 Kf6-g7
  +-  (1.87)   Depth: 18   00:04:18  15652kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 e5xf4 4.Qc1xf4+ Kf6-e7 5.g4xh5 Ng7xh5 6.Be2xh5 g6xh5 7.Nf1-e3 Ke7-d7
  +-  (2.03)   Depth: 19   00:10:19  35590kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Nb8-d7 4.f4xe5+ Nd7xe5 5.Qc1-f4+ Kf6-e7 6.Nd3xe5 d6xe5 7.Qf4xe5+ Ke7-f8
  +-  (2.21)   Depth: 20   00:24:50  85527kN
1.b4xc5 b6xc5 2.h3-h4 g5xh4 3.f3-f4 Nb8-d7 4.f4xe5+ Nd7xe5 5.Qc1-f4+ Kf6-e7 6.Nd3xe5 d6xe5 7.Qf4xe5+ Ke7-f8
  +-  (2.21)   Depth: 21   00:30:19  103262kN

(,  24.06.2007)
Parent - - By genorb (**) Date 2007-06-24 21:53
"I do not see bug in choosing bxc5 first"

No I do not say that the other move is wrong (except that you can play h4 immediately). I just notice that changing the hash size can lead to a different analysis and this can happen even quite soon after just few seconds and depth 10-11. I would be surprised if the 32MB of the hash memory were already filled after only few seconds, so I have difficulties to understand why the analysis is different if I set 32MB for the hash or 128MB.
Parent - - By Roland Rösler (****) Date 2007-06-24 23:12
Maybe it´s new for Rybka, that memory size has effect on search/eval. I don´t believe it. But I know, that Shredder by example is extremly dependent on memory size (not the way that more is always better). If you are interested in testsuites, you can test it. There are different results even for Rybka 2.3.1 with 32 MB or 64 MB or 256 MB.
Parent - By genorb (**) Date 2007-06-25 09:07
thanks Roland!
Parent - - By Uri Blass (*****) Date 2007-06-25 09:27
The hash entries do not need to be full in order to have different analysis.

Suppose that you have 365 humans and you want to put them in 365 rooms.
Suppose that you put everyone of them in a room based on his birthday date
and the rooms have place only for one person.

You will have 2 people with the same birthday date even when most of the rooms are empty.
For similiar reasons a program may not be able to save a position in the hash even when most of the hash is empty.

Uri
Parent - By genorb (**) Date 2007-06-25 09:53
Thanks Uri for the explanation! I understand it better :)
Parent - - By Vasik Rajlich (Silver) Date 2007-06-25 14:55
Yes, this is correct. Once two searches diverge by even the smallest amount, they can go in two completely different directions. It's like that movie "Butterfly Effect" :)

Vas
Parent - - By Lukas Cimiotti (Bronze) Date 2007-06-26 20:32 Edited 2007-06-26 20:35
I saw quite different results for different hash sizes in analyzing a position.
But i made engines matches using different hash sizes - and that had no effect at all on the results. I don't exacly remember, but it was something like 8 mb for one copy of the engine and 512 mb for the other one. So i still don´t know if a lot of memory helps in playing computer chess. Btw. my oct only has got 8 GB of RAM, because prices dropped recently and i couldn´t resist to buy it.
Parent - - By Banned for Life (Gold) Date 2007-06-26 20:51
Vas's estimate of 5 Elo per hash doubling would result in a 30 point difference going from 8 MB to 512 MB. You should be able to see this in a large match, but its not earth shattering.

Alan
Parent - - By Lukas Cimiotti (Bronze) Date 2007-06-26 20:59
I'll retry this some time. But i think, time control (from my theoretical view of things) might have a big impact on the result.
I think for bullet, there is no need for large hash size - on longer time control this might be different.
Btw on WCCC we used 2 gb of hash on a 8 gb computer, and i think it was o.k.

Lukas
Parent - - By Banned for Life (Gold) Date 2007-06-26 21:03
Yes, a larger hash should be more important with more nodes being calculated (i.e. with increased speed-time product). I was assuming that the 5 Elo per doubling that Vas quoted was asymptotic (i.e. it would be the difference in strength if you left it running for a very long period of time).

Alan
Parent - - By Vasik Rajlich (Silver) Date 2007-06-27 14:02
Actually, this figure came from some old study. I have no idea about the conditions. It should depend on the program, time control, hardware, hash size, and who knows what else.

Vas
Parent - - By Banned for Life (Gold) Date 2007-06-27 20:32
ok, I thought you measured it.

From an engineering standpoint, it should depend on the hash read hit rate (easy to measure but highly dependent on what's going on in the search) and an estimate (probably depth dependent) of the amount of time saved by using the hash value rather than recomputing (except that recomputing should give a somewhat better answer since it would incorporate the information from the current hash state).

The hash hit rate averaged over some period of time, say a second, would be kind of a nice thing to have. When you double the hash size and the hit rate doesn't increase by a meaningful amount, you don't need to worry about adding more memory.

Alan
Parent - - By Vasik Rajlich (Silver) Date 2007-06-29 13:36
Search is way too complicated for me to measure these things and spit out an Elo figure.

You also can't use times-to-depth for this, because hash entries are often better than the search they replace.

And, for what it's worth, doubling the hash size would always increase your hit rate, although there are diminishing returns.

Practically speaking, I can suggest the following:

1) Always use the biggest hash
2) Unless you are really rich, don't buy RAM just to have a bigger hash - spend the money on the CPU and a nice cooling system

Vas
Parent - By Jim Walker (***) Date 2007-06-29 17:38
I do remember the Spraklens claimed that a doubling of hash would give about 7 Elo increase with their old Sargon program.  Don't remember how they arrived at that figure.
Jim
Up Topic Rybka Support & Discussion / Rybka Discussion / Hash problem or not?

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill