Manual: How to use Syzygy (or any other) 6-men without SSD

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

Ryan Benitez
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

Post by Ryan Benitez »

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.
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Manual: How to use Syzygy (or any other) 6-men without S

Post by syzygy »

Milos wrote:
mvk wrote:
Milos wrote:So if you don't have expensive SSD and want to get accurate endgame analysis.
You can also opt for a cheap SSD.
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.
Latency is what counts here.

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.
Expensive PCIe SSD is a different thing, but as I said they are expensive.
Imho only worth the money (for this purpose) if they give far better read latency.
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Manual: How to use Syzygy (or any other) 6-men without S

Post by syzygy »

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.
This is certainly possible.

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.