Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Multi-processors
- - By j33 Date 2009-10-09 19:19
Good evening. Can rybka use more than a one processor, for example two xeons (8 cores) on any 2-processors motherboard, on Windows?
Parent - - By Fulcrum2000 (****) Date 2009-10-09 19:45
Yes, if you have the mp version of Rybka.
Parent - - By j33 Date 2009-10-09 21:43
Thx. What about RAM? Can rybka use more than 4GB?
Parent - - By Uly (Gold) Date 2009-10-09 22:04
No, 2GB is the limit.
Parent - - By Fulcrum2000 (****) Date 2009-10-09 22:13
2 GB is the limit for R3, maybe Vas will surprise us with R4 ;-)
Parent - - By Gaмßito (****) Date 2009-10-09 22:45
I hope Rybka 4 can use much more than 4GB. Vas is already warned. :-)

Regards,
Gaмßito.
Parent - By Banned for Life (Gold) Date 2009-10-09 23:49
Vas has stated that he fixed the hash limitation a while back. I hope the only limitation for R4 will be how much DRAM your MB supports.
Parent - - By Uly (Gold) Date 2009-10-10 00:11
My prediction:

A R4 that supports >2GB RAM will be <1 elo stronger than R4 with 2GB or less.
Parent - - By Banned for Life (Gold) Date 2009-10-10 00:19
If you are doing multiple-day runs on a single position on a fast machine, the additional hash will save a lot of time and provide a very noticeable improvement in performance. If you are playing blitz games, it will provide no gain whatsoever.
Parent - - By Uly (Gold) Date 2009-10-10 00:34
You may be right for letting Infinite Analysis run for a really long time, but I think forcing the variations is more useful anyway, and in the last case Persistent Hash will be much more effective and it doesn't benefit much from more RAM (in some cases the hash contents slow down Rybka and you get analysis faster after clearing the hash and letting Persitent Hash handle the position.)
Parent - - By Banned for Life (Gold) Date 2009-10-10 01:07
Running IA at very deep depths from the root is certainly going to be a good strategy for long time control games in some cases (Uri claims this is a good strategy most of the time). Working backward through the resulting PV is frequently productive. Forcing promising lines is better in some cases too. In all of these cases, having a larger hash should be useful.

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.
Parent - - By Uly (Gold) Date 2009-10-10 01:34

> 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.
Parent - - By Banned for Life (Gold) Date 2009-10-10 04:59 Edited 2009-10-10 05:03
I wrote a lengthy reply which disappeared after a firefox crash, so this will be much shorter...

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.
Parent - By Uly (Gold) Date 2009-10-10 05:30

> 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.)
Up Topic Rybka Support & Discussion / Rybka Discussion / Multi-processors

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill