hash never hurt engine (assuming you have enough RAM)?? Or is Rybka's 74 MB RAM usage the key 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 :)
> 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...
> (not sure what it really uses...)
Setting it to 2MB makes her use 83MB on my computer.
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.
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.
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.
> 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 :)
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.
Rybka artwork by Carina Jørgensen. Inspiration for Felix´ logo? I think the text is poetic too.
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.
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.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill