You could try though, if the problem you found (in that specific positions) is affected by the NalimovUsage engine setting. Maybe it goes away if you adjust it from rarely to normally or frequently. Although, it may be that in other cases or in general, this could decrease the endgame performance. That certainly depends on your system and configuration detail, for example if you have the Nalimovs on a storage device with fast access(!) times.
Another consideration is if your position is a rare exception, or someting related to knowledge which was removed after Rybka 2.2. If you have Rybka 2.2 too, I suggest to try this version too, for comparison. In a number of positions which were posted, where 2.3.2a had problems, I got good results from 2.2. But my tests are not related to 6-piece tbs. because I don't use them and not even all 5-piece tbs.
I changed the NalimovUsage setting from rarely to frequently and that fixed the problem. Thank you! Why would that decrease the endgame performance to use the Nalimov tablebase more frequently? And could it decrease performance in other areas of the game?
In the board position the Brain posted below, notice the code immediately on top of the diagram.
> What is that?
Try finding something similar to "Copy FEN" or "Copy Position" on the "Edit" or "File" menu of your interface.
>>You could help us by posting the FEN.
>What is that?
I think, this is the post of the month!
PS: Maybe we shall have a poll about the best post of the month (or quarter).
>I honestly don't know which philosophers have done more harm, the French or the Germans.
I'd say the French were more harmful at philosophy, but possibly only because the Germans found that psychology was a superior field for spreading damage. :-P But then again, one could argue that the French [particularly Clemenceau] scored their greatest coup against the Germans via the unnatural preservation of the Bismarckian Reich during the Peace to End All Peace at Versailles.
> Why would that decrease the endgame performance to use the Nalimov tablebase more frequently?
I think it depends a lot on the individual system configuration. As you have seen, the default is "rarely" (it was "normally" in 2.2). The problem is the access time which is required, each time the engine looks up a tablebase position in the Nalimov files. This can cause a slowdown effect. This effect will of course be the bigger, the more tbs. lookups are done, per second. At the same time, the perfect information of course helps. So, it is always a tradeoff.
The slowdown is most noticable when the tbs. are accessed for the first time (per session), and will be smaller later because some data can be retrieved from caches, instead of having to access the storage device.
The number of such accesses can vary, up to many thousands per minute. Examples with setting "normally", D945 3.4 GHz:
Analysis by Rybka 2.3.2a 32-bit :
1.Rd1 f5 2.Kd3 Bf6 3.Kc4 Bxd4 4.Rxd4 Rxd4+ 5.Kxd4 f4
= (-0.01) Depth: 5 00:00:00
= (0.00) Depth: 21 00:01:37 4623kN, tb=3423 <-- that means ~35 tbs. accesses per second
Analysis by Rybka 2.3.2a 32-bit :
1.Ke2 Ke4 2.Kd2
= (0.22) Depth: 5 00:00:00
= (0.01) Depth: 6 00:00:00 0kN
1.Kf2 Ke4 2.Ke2 Kf5 3.Kd3 e5 4.fxe5 dxe5 5.dxe5 Kxe5
= (0.05) Depth: 6 00:00:00 0kN
= (0.00) Depth: 38 00:00:46 4817kN, tb=39970 --> 869/sec. (!)
The slowdown effect (in principle) should be minimized, as good as possible, by configuration. Recommendable is to use a fast storage device, like flash memory (USB memory stick or -card), or a solid state disk. Important is the access time, not the transfer rate, because small parts of data need to be read very often. Normal USB sticks will not have enough space for 6-piece tbs., but on an 8 GB stick you can put all 3/4/5-pieces files.
I use a 1 GB stick only, because I do not use all 5-piece tbs. but only a smaller subset with important files (rook vs. rook), as a compromise which I think is another idea to reduce the slowdown effect. I think there are many 5-piece endings which do not require tablebases, i.e. QB-N or the like, where "the case is clear." Since I do not need absolute high performance, I like to use the normally or even frequently settings, for endgame analyses with this configuration.
Another part of the related configuration is the tablebase cache. Here, tbs. data is buffered in it's uncompessed form, while the normal file caches contain compressed data because the Nalimov files are compressed. Various tests couldn't lead to a clear conclusion though, if the tablebase cache size has a significant impact on the tbs. performance or not. Some think it has none. Since I have more than enough RAM anyway, I set it to 128 MB. Even if it's almost useless, I think it cannot harm. But in case of shortage of RAM, the hash tables should have priority.
All this considerations apply of course only to endgame positions where the engine begins to access the tablebases, during the search.
An idea for the Rybka 3 GUI: instead of just showing 0.00, it could have some indication of what kind of 0.00 it is. When I see 0.00, I don't always know if it's a tablebase draw, a simple repetition of moves, or just an equal position with a lot of play left in it.
Can somebody update me on what's happening with the potential Nakamura-Rybka match?
> An idea for the Rybka 3 GUI: instead of just showing 0.00, it could have some indication of what kind of 0.00 it is. When I see 0.00, I don't always know if it's a tablebase draw, a simple repetition of moves, or just an equal position with a lot of play left in it.
This will require changes to UCI. Things like this are for Rybka 4 and beyond.
> Can somebody update me on what's happening with the potential Nakamura-Rybka match?
AFAIK Larry is working on it.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill