Manual: How to use Syzygy (or any other) 6-men without SSD
Moderators: hgm, Rebel, chrisw
-
- Posts: 719
- Joined: Thu Mar 09, 2006 1:21 am
- Location: Portland Oregon
Re: Manual: How to use Syzygy (or any other) 6-men without S
Can someone show me an example of a game other than chess using DTM in its endgame tablebases? I am still trying to find the evidence that having more than WLD (implemented properly) helps overall performance.
-
- Posts: 5563
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Manual: How to use Syzygy (or any other) 6-men without S
Latency is what counts here.Milos wrote:Slow SATA SSD doesn't help much, you gain from 80MB/s common HDD to 160MB/s slow SSD. You gain quite a bit in latency, but once TBs are fatched loading them doesn't get much faster.mvk wrote:You can also opt for a cheap SSD.Milos wrote:So if you don't have expensive SSD and want to get accurate endgame analysis.
Once TBs are cached in RAM it does not matter whether they came from HDD or SSD. So with lots of RAM the difference between SSD and HDD disappears the longer you let the engine analyse a position.
Imho only worth the money (for this purpose) if they give far better read latency.Expensive PCIe SSD is a different thing, but as I said they are expensive.
-
- Posts: 5563
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Manual: How to use Syzygy (or any other) 6-men without S
This is certainly possible.M ANSARI wrote:I wonder if an efficient algo could be written in an engine to quickly decide which bases to look at and which bases to totally avoid on the fly. It would probably reduce any speed hit for the engine.
The use of tablebases improves play in two ways:
- improved evaluation of endgame positions;
- improved pruning.
For many tables the engine's evaluation plus qsearch will already evaluate almost all positions correctly. For those the improvement will come only from improved pruning. To benefit from improved pruning, the table should only be probed with sufficient depth left (i.e. the pruned subtree should be large enough to make probing worth it).
For tables such as KRPPvKR the engine's evaluation will be less reliable, so probing close to the leaves of the search tree makes sense. But even for this table it might make sense not to probe close to the leaves if "white can at least draw" would cause a cutoff, because the engine's own evaluation will normally be reliable in detecting this. KRPPvKR should be probed if knowing whether white can win or not may make a difference.
My implementation in Stockfish probes everywhere (except in the qsearch), which probably is less than optimal on machines that do not have a huge amount of RAM. But my implementation was only intended as a proof of concept.