Rybka3, Arena & Hashtable szie

[chesstango]

why doing things so complex? ; sorry but it seems like you dont believe to Kah Huat, Koh......
He is asking for a concrete subject and u are not giving him what u guess it might be happening..... Just that. I guess Kah Huat, Koh is only wondering , like me, why it happens something rather "irregular"....
On the other hand, I notice that there are many tips that in this forum are not shared..... I respect people doing that..... but, sometimes its frustrating for people like me who are not experts in computing or even programmers but just love chess, or mistreated or ignored......
I declare these are not statements for a particular person , obviously not even for u. It is just what i feel. I guess that this is a forum to exchange experiences among us and i never was advised that i had to be a computer expert to participate . So, finally, i wish to state that moderators always treated me very well, doing their best, and i feel comfortable with them and many other users.
Thx for listening to my thoughts.

[Ovyron]

Well, the outputs of Rybka 256MB and 384MB should be identical, I'm trying to figure out why are they different but I need more information.

I already answered the original question that the best move will most of the time be that with the biggest hash, for analysis. 512MB in this case. 64Mb also picked this move by luck. Bigger Hash or longer time control may reveal that there's a better move, 7...cxd5 perhaps, but these moves may be equally good and it's just the order Rybka refutes the moves that one move is picked instead of the other. This depends on the contents of the hash, and different sized hashes have different contents.

[Gerd Lahnstein]

Hi all,

when playing with the rybka 3 hash size some days ago, I was quite puzzled about the results as well.

The results were posted here:
"Rybka 3 - Seltsamer Einfluß der Hash-Speichergröße auf die Rechenleistung"
http://www.schachfeld.de/f202/rybka-3-s ... tung-7874/

Although this is in German, at least you should be able to read the tables and the attached analysis output file.

Anyway, a short summary is provided here for your convenience:

Configuration:
CPU: 2GHz P4, 1GB RAM, XP-Home, 32-Bit
Rybka Version: Rybka 3 UCI 32 Bit
GUI: Scid 3.6.25 (Arena 1.99 with same results)

Testing procedure notes:
The GUI (Scid and Arena) was restarted each time before a single hash size test and repeated twice.
All Rybka settings are default, except hash size.
No other programs in background (virus scanners and the like)

Testing position:
FEN: r3r3/p2n4/2qpp2k/1p5n/3PNp1p/1PP1QP2/P1B2P2/6RK w - - 0 1

I did two tests:

1. time to find the winning move depending on hash size

64 MB: 9 +0.49 1.Sxd6 ( 9.69) Sek.
32 MB: 10 +0.69 1.Sxd6 (27.34)
512 MB: 10 +0.69 1.Sxd6 (29.95)
384 MB: 10 +0.69 1.Sxd6 (31.63)
256 MB: 10 +0.69 1.Sxd6 (32.00)
128 MB: 10 +0.69 1.Sxd6 (35.95)
16 MB: 11 +0.72 1.Sxd6 (37.42)


2. time to reach a certain depth depending on hash size

32 MB: 13 +7.33 1.Sxd6 (543.80) Sek.
16 MB: 13 +7.67 1.Sxd6 (729.70)
512 MB: 13 +7.80 1.Sxd6 (673.83)
128 MB: 13 +7.90 1.Sxd6 (685.36)
384 MB: 13 +7.93 1.Sxd6 (900.13)
256 MB: 13 +7.93 1.Sxd6 (902.70)
64 MB: -- ----- ------ -------- no further output after depth 10 - BUG ?

The above results are a bit strange and could have been titled:
CAUTION - LARGER HASH SIZE MAY SLOW DOWN YOUR RYBKA

remarkable:
with 64 MB the winning move is found 3-4 times faster, second best is 32 MB.
with 256 MB or 384 MB hash it takes almost 2 times longer to reach depth 13 than with 32 MB.

Regarding 64 MB hash:
I already have made the experience before that some other positions were causing rybka to hang occasionally (infinite loop, bug ?).

[ernest]

The above results are a bit strange and could have been titled:
CAUTION - LARGER HASH SIZE MAY SLOW DOWN YOUR RYBKA

No problem: try it with another position, you will find another "best hash"

Note: Rybka only considers (power of 2)MB as hash size, so 384MB hash is considered as 256MB hash.

[Ovyron]

Note: Rybka only considers (power of 2)MB as hash size, so 384MB hash is considered as 256MB hash.

That is being discussed in this thread, people are getting different results with 384 and 256 MB.

[Karmazen & Oliver]

The above results are a bit strange and could have been titled:
CAUTION - LARGER HASH SIZE MAY SLOW DOWN YOUR RYBKA

No problem: try it with another position, you will find another "best hash"

Note: Rybka only considers (power of 2)MB as hash size, so 384MB hash is considered as 256MB hash.

try it with another position ??? why ??? that is a horrible BUG ¡ this is very ... a superBUG.---

[Karmazen & Oliver]

Hi all,

I'm running Rybka3 on my pc (2Gb RAM), single cpu, Win-XP under Arena1.99beta5, fixed search depth=16 and different hashtable size for this position:

1. e4 d6 2. d4 Nf6 3. Nc3 g6 4. Be2 Bg7 5. f4 O-O 6. Nf3 c5 7. Be3

Each time, I "clear hash" and re-boot my pc before I use different hastable size. I am surprised with the following result

(1) hashtable size = 64Mb, move play is 7...Qa5, score +0.09, time taken is 02:56

(2) 128Mb, 7...cxd5, score -0.01, time:5:52

(3) 256Mb, 7...Qb6, score 0.00, time: 03:50

(4) 384Mb, 7...cxd5, score +0.02, time:11:20 (!)

(5) 512Mb, 7...Qa5, score +0.11, time: 04:32

My questions are:
(a) why at different hashtable size, the move played is different?
(b) 64Mb and 512Mb, Rybka selects the same move but time taken is quite significantly different. Similarly for 128Mb and 384Mb.
(c) Thus, at what hashtable size would (i) give the best move (ii) take the least time to find and select the best move?

Thank you!
Kah Huat, Koh
- from Singapore

fantasctic analysis...

This is a BUG, and it´s a lot of time... a superBUG.-

[Tony Thomas]

Why is it that the guy who posted the results above has almost the same results as kat Kuhaut Ko?? Did he start a new account?

[Ovyron]

What bug? Different hash leads to different results sometimes better, sometimes worse. It's normal, try a different engine.

[Karmazen & Oliver]

No. this is not a normal BUG, it´s a supperBUG.

OK, diferents hash-table show diferents results, OK, BUT never is posible that "small" hashtable show betters results... that more hast-table except if that hash-table go access HDD---

256 MB or 512 MB are normal hash-table.. for a pc with 2GB system ram..

and they are more slowly result.

this is horriblus. a superBUG.