A R4 that supports >2GB RAM will be <1 elo stronger than R4 with 2GB or less.
If Rybka is taking longer to analyze positions in the general case using a few dozen persistent hash entries rather than hundreds of millions of hash entries, its indicative of some serious problems with Rybka. I don't think this is really the case although there are definitely instances where the hash slows down the search, and definitely a lot of bugs that need to be worked around in both persistent hash and hash. I am hoping Vas will improve this a lot for R4, but I will not be surprised if only the worst problems have been addressed.
> If Rybka is taking longer to analyze positions in the general case using a few dozen persistent hash entries rather than hundreds of millions of hash entries, its indicative of some serious problems with Rybka.
It happens often, with Persistent Hash ON, sometimes when coming back to the root, Rybka displays a very high depth, and is apparently analyzing, but takes unreasonable time to show anything. In such cases, I unload the engine, reload, and the next depth is reached very fast.
If we're talking about different things, then I've never used big amounts of RAM so I can't tell, but the problem is that eventually Rybka is going to overwrite some key variation and all interactive analysis is suddenly wasted, then having Persistent Hash ON is again the better option.
I'd like to see one of these cases where using 2GB RAM finds the best move consistently faster than 64MB, that'd change my opinion.
Rybka 3 PH has well known problems. Rybka 3 hash has problems too, but not as bad as PH. You are clearly the expert in PH problems and unfortunately you seem to understand these problems better than Vas.
I use PH all the time. I do not understand what Rybka is doing when it is screwed up, but I do know when I have to change the number of PVs to clear things up. The PH problem does not seem to be related to hash size.
Rybka's hash policy tries to keep the results that take the most time to calculate (i.e. those at greatest depth). HG Mueller has pointed out that this probably overemphasizes hash entries that are deep over hash entries that are less deep but used more frequently. I bought Dr. Mueller's argument to a greater extent than Vas. Obviously this will be less of an issue with a larger hash.
Sometimes Rybka puts bad results in the hash that slow things down and faster results can be obtained by clearing hash and starting again. I don't think this is related to hash size, and its hard to know a priori if restarting is a good thing if you have already reached a high depth. PH is some help, but its not a panacea here.
A chess engine's hash behavior can be analyzed using queuing theory with a Markov model. As depth increases, it takes longer and longer to complete an iterative deepening cycle. At some point, when you return to a move, most of the hash entries have been overwritten. Using a larger hash pushes this point to a higher depth resulting in faster speed on average for depths where the hash hit rate is significantly higher for the engine with the larger hash. This is particularly true if the PV changes near the root at these depths.
Finding an example of this wouldn't be terribly difficult. Any complex middle game position without tactics where Rybka significantly changes evaluation at a high depth (maybe 27) would be a fine example. This might take a whole day to find with a fast quad and 2GB of hash. I would be willing to bet it will take significantly longer with 64MB, probably too long to wait for completion. I can fish one of these positions from an old correspondence game if you are interested in putting this to the test.
> I wrote a lengthy reply which disappeared after a firefox crash
That was the main reason I didn't move to Firefox 3 (at least, I haven't had any crashes with 2, while after moving to 3 any site with heavy Java and Flash content would make FF crash.)
>Rybka 3 hash has problems too, but not as bad as PH.
But hash has the main problem of being non-persistent, I think that problem offsets all the PH problems, though, I have to agree that Persistent Hash is a hassle, specially when it disconnects the learning from the actual analysis, and you have to force the learned line again to plug it back, but you have to store your main lines somewhere else, and check what Rybka shows against it, so I can understand why so few people are using it.
> Rybka significantly changes evaluation at a high depth (maybe 27)
Now I've got to admit I'm not of the kind that leaves the computer analyzing overnight, usually on the middlegame positions I analyze I don't go beyond real depth 21, and up to this point using x2 or x4 the RAM doesn't seem to make any difference, but I can conceive the difference to grow significantly the higher the depth.
In these cases I see how having 8GB RAM would be very useful to speed it up, so I take back the my "<1 elo" statement for these cases (though I maintain that interactive analysis is superior, and in that, you'd focus more on pruning and extending variations effectively than on reaching high real depth.)
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill