Topic Rybka Support & Discussion / Rybka Discussion / Hash test with Rybka3: 32/64/128/256 MB - weird results?!
![[fi]](/mwf/v12/flags/fi.png "Finland")
I tested in P2400 single PC and with 200 test positions: no significant difference in solution times att all from 32MB to 256 MB. And additionally I tested even with minimum hash = 2 MB! Result: it's not worse than others!! May be we can safely conclude, that bigger
hash never hurt engine (assuming you have enough RAM)?? Or is Rybka's 74 MB RAM usage the key here...
Jouni
hash never hurt engine (assuming you have enough RAM)?? Or is Rybka's 74 MB RAM usage the key here...
Jouni
![[gr]](/mwf/v12/flags/gr.png "Greece")
well i saw the same in my laptop centino 1.6 1-cpu..but you should make another test.. witch hash size is better to reach one specific depth, example
how much secs to reach the 20 plies ...here the bigger size=the faster will reach that depth...but in positions results no difference?? strange!
i think the 74 mb have nothing to do with that.....but even u need big hash size cuz in endgames the hash size is very important cuz lot
of transpositions....ok make one test of fixed depth.....maybe we need the vader,ops vasik help here :)
how much secs to reach the 20 plies ...here the bigger size=the faster will reach that depth...but in positions results no difference?? strange!
i think the 74 mb have nothing to do with that.....but even u need big hash size cuz in endgames the hash size is very important cuz lot
of transpositions....ok make one test of fixed depth.....maybe we need the vader,ops vasik help here :)
Hmm. I get same result with other engines as well :-) Testing of hash is very difficult and time consuming - I give up now.
Jouni
Jouni
![[fr]](/mwf/v12/flags/fr.png "France")
> I tested even with minimum hash = 2 MB!
Funny: in ShredderClassic GUI the minimum for Rybka 3 is 4MB, in the Fritz 11 GUI, you can even set 1 MB (not sure what it really uses...)
> no significant difference in solution times att all from 32MB to 256 MB
You mean individually, or the sum of all the solution times (the danger of summing, is that positions with long solution times matter much more than the positions with short position times)?
With different hash size for a given position, the depth needed for the solution is often not the same, so solution times can easily be multiplied by 2 or 4...
2MB is the real minimum: setting it to 1 is a no-op (you can prove this with the MP version: she doesn't kill her children if you tell her to use 1MB).
![[mx]](/mwf/v12/flags/mx.png "Mexico")
> (not sure what it really uses...)
Setting it to 2MB makes her use 83MB on my computer.
![[pl]](/mwf/v12/flags/pl.png "Poland")
You probably need a finer-grained test. Rybka's 74 MB process size is not relevant to the general formula that doubling == 5 Elo.
Vas
Vas
Very good news that there will be an update Vas!
To be honest I have not bought Rybka yet but would like to eventually... It was mainly reading about the backlog in order processing that had me worried a little bit. One small concern though if the update will be not so very far from an expected Rybka 4 then for new customers it may mean they will just wait a little longer for Rybka 4... In which case I really do think a policy for long term customers would be helpful! Stefan Meyer Kahlen has introduced this for Shredder 11 I believe, Mark Uniacke has it. Maybe Stefan could say something about if he is satisfied with the results of his upgrade policy.
But I know you like to keep things simple :)
About the speed-up of larger hash, I was a bit curious if 74 MB process size not being relevant means that these are just empty tables, or was/is there really a purpose for this? If a doubling of hash gives 5 Elo, this is not very much: if a doubling of processor speed means ≈ 50 Elo then doubling hash would be worth about a 7% speed-up. (slide-rule math, 1.07^10 ≈ 2) It could be though that this does not hold for finding solutions to tactical positions. I'm not sure, but I think it could be, and especially if the tactical solutions are not very deeply hidden, the solutions probably will be found before Rybka has to start replacing hash entries? It is my understanding the replacement scheme does not start right away but have not really studied how that works in general.
I am definitely sure that small hash eventually slows down a engine on longer analysis (hours, not in fast tactics), but that may vary with the efficiency of replacement schemes and about Rybka I do not really know how much of a slowdown there is. It should be fairly easy to measure this at least for one threaded Rybkas.
Another small complication is I think the 5 Elo would have been measured in games, but Rybka profits from not clearing the hash tables between moves, for every new move it already has some shallow analysis available. In that case larger hash tables are more helpful then if hash was cleared between moves, the 5 Elo would probably be less. So not sure if 5 elo is very accurate if you want to know about the speed of finding tactical solutions when using larger hash sizes.
Regards, Eelco
To be honest I have not bought Rybka yet but would like to eventually... It was mainly reading about the backlog in order processing that had me worried a little bit. One small concern though if the update will be not so very far from an expected Rybka 4 then for new customers it may mean they will just wait a little longer for Rybka 4... In which case I really do think a policy for long term customers would be helpful! Stefan Meyer Kahlen has introduced this for Shredder 11 I believe, Mark Uniacke has it. Maybe Stefan could say something about if he is satisfied with the results of his upgrade policy.
But I know you like to keep things simple :)
> You probably need a finer-grained test. Rybka's 74 MB process size is not relevant to the general formula that doubling == 5 Elo.
>
> Vas
About the speed-up of larger hash, I was a bit curious if 74 MB process size not being relevant means that these are just empty tables, or was/is there really a purpose for this? If a doubling of hash gives 5 Elo, this is not very much: if a doubling of processor speed means ≈ 50 Elo then doubling hash would be worth about a 7% speed-up. (slide-rule math, 1.07^10 ≈ 2) It could be though that this does not hold for finding solutions to tactical positions. I'm not sure, but I think it could be, and especially if the tactical solutions are not very deeply hidden, the solutions probably will be found before Rybka has to start replacing hash entries? It is my understanding the replacement scheme does not start right away but have not really studied how that works in general.
I am definitely sure that small hash eventually slows down a engine on longer analysis (hours, not in fast tactics), but that may vary with the efficiency of replacement schemes and about Rybka I do not really know how much of a slowdown there is. It should be fairly easy to measure this at least for one threaded Rybkas.
Another small complication is I think the 5 Elo would have been measured in games, but Rybka profits from not clearing the hash tables between moves, for every new move it already has some shallow analysis available. In that case larger hash tables are more helpful then if hash was cleared between moves, the 5 Elo would probably be less. So not sure if 5 elo is very accurate if you want to know about the speed of finding tactical solutions when using larger hash sizes.
Regards, Eelco
Re. Rybka 3 update vs Rybka 4 - Rybka 3 update will have no strength gain, I'll compile that out. Rybka 4 is still a long way away.
Re. business stuff - maybe later we'll do another pass. Right now we concentrate on development.
Re. hash & 5 Elo - it's a rule of thumb covering an average scenario. There are dozens of variables here. In tactical positions and in middlegames the typical gain will be less, while in endgames it will be more.
Vas
Re. business stuff - maybe later we'll do another pass. Right now we concentrate on development.
Re. hash & 5 Elo - it's a rule of thumb covering an average scenario. There are dozens of variables here. In tactical positions and in middlegames the typical gain will be less, while in endgames it will be more.
Vas
> Re. Rybka 3 update vs Rybka 4 - Rybka 3 update will have no strength gain
Actually, I predict that the fix of the Persistent Hash Play Depth Bug will bring home the elo :)
Thanks Vas! That all makes sense I think.
Re Rybka, my financial budget is rather limited at the moment, sorry to say.. So an update somewhere in December would be okay for me! Maybe I will just go for the engine alone or just single processor version with Aquarium via New in Chess. Only 50 € for Rybka single processor or 89 € for Deep Rybka, that is a fair price compared with Deep Shredder for instance.
Eelco
Rybka artwork by Carina Jørgensen. Inspiration for Felix´ logo? I think the text is poetic too.
Re Rybka, my financial budget is rather limited at the moment, sorry to say.. So an update somewhere in December would be okay for me! Maybe I will just go for the engine alone or just single processor version with Aquarium via New in Chess. Only 50 € for Rybka single processor or 89 € for Deep Rybka, that is a fair price compared with Deep Shredder for instance.
Eelco
Rybka artwork by Carina Jørgensen. Inspiration for Felix´ logo? I think the text is poetic too.
I think the problems arise more often with larger hash sizes, 512+ or even more.
That bigger hash never hurts, is not quite true, but it is a very complicated technical matter. It was a topic here and in CCC, where Bob Hyatt explained details about it. It has to do with memory addressing and the TLB (a buffer to speed up memory accesses) losing effectiveness, with very large hash tables. I am no expert of it and it requires someone very fit in PC hardware system internals, to give a really competent explanation. It's something like, the bigger the hash, the more is the TLB polluted with garbage data reducing the speed-up.
Anyway, the recommendation was just what you did now: Methodical step-by-step tests with different hash sizes and speed comparison. It certainly depends on the individual system and it's components, OS, settings etc. But I guess only people with 2 GB or even 4 GB total will notice a significant effect, with the very large hash sizes the can configure.
Of course, the tests should be done not with just one, but with a couple of different but "typical" positions. I would compare time to depth x.
That bigger hash never hurts, is not quite true, but it is a very complicated technical matter. It was a topic here and in CCC, where Bob Hyatt explained details about it. It has to do with memory addressing and the TLB (a buffer to speed up memory accesses) losing effectiveness, with very large hash tables. I am no expert of it and it requires someone very fit in PC hardware system internals, to give a really competent explanation. It's something like, the bigger the hash, the more is the TLB polluted with garbage data reducing the speed-up.
Anyway, the recommendation was just what you did now: Methodical step-by-step tests with different hash sizes and speed comparison. It certainly depends on the individual system and it's components, OS, settings etc. But I guess only people with 2 GB or even 4 GB total will notice a significant effect, with the very large hash sizes the can configure.
Of course, the tests should be done not with just one, but with a couple of different but "typical" positions. I would compare time to depth x.
hey we bring the big news here, rybka 3 update soon :)
![[de]](/mwf/v12/flags/de.png "Germany")
Yes, there is a TLB problem when using large hash sizes. The workaround is using huge pages on Linux - that's what the microwine discussion is all about.
I tried to find out how much huge pages help. For these tests I used a 2x X5365 8x3 GHz computer. The speedup in the starting position was 17% at a hash size of 2 GB. If we assume that doubling speed adds 70 Elo points 17% should add ~16 points.
I've also tested different small hash sizes 2 MB - 128 MB. In these tests in fact I got +5 Elo points per hash doubling.
My guess is: in the range of large hash tables doubling size might bring diminishing returns, but larger hash should only hurt in very fast games. I can't imagine that it hurts in infinite analysis.
Regards,
Lukas
I tried to find out how much huge pages help. For these tests I used a 2x X5365 8x3 GHz computer. The speedup in the starting position was 17% at a hash size of 2 GB. If we assume that doubling speed adds 70 Elo points 17% should add ~16 points.
I've also tested different small hash sizes 2 MB - 128 MB. In these tests in fact I got +5 Elo points per hash doubling.
My guess is: in the range of large hash tables doubling size might bring diminishing returns, but larger hash should only hurt in very fast games. I can't imagine that it hurts in infinite analysis.
Regards,
Lukas
The doubling == 5 Elo formula ignores NUMA & TLB considerations, which will be hardware-dependent of course. There may be some really obscure scenarios where bigger hash is not better, but I wouldn't worry about those.
Vas
Vas
Topic Rybka Support & Discussion / Rybka Discussion / Hash test with Rybka3: 32/64/128/256 MB - weird results?!
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill