AndrewGrant wrote:I have forked Arasan's development repo for Fathom, as the main repo seems to be stale and or broken, and Jon Dart seems to have taken it into his own hands to fix it (
https://github.com/jdart1/Fathom)
A couple of things about how Stockfish implements Syzygy:
When SF probes and causes a cutoff, it is stored with depth = MIN(MAY_PLY-1, depth + 6).
I get that the idea is to store with a higher depth to avoid overwritting, and to allow more cutoffs,
since we should have a perfect eval of the position. But why not just save with MAX_PLY - 1?
If I remember well, the "depth + 6" was just a relatively arbitrary choice by me. A compromise between avoiding repeated TB probes of the same position and avoiding filling the TT with positions that may stop being relevant as the tree develops but won't let themselves be overwritten. I think the correction for MAX_PLY-1 was added by someone else (perhaps Gary, but I'm not sure).
My concern about MAX_PLY-1 is probably not valid given the current TT replacement policy of SF. But I'd have to check again to be sure.
A while ago I ran some local tests with both "MAX_PLY-1" and "depth", but neither seemed to be an improvement.
Also, when in a PvNode, SF does the following:
Code: Select all
if (PvNode){
if (bound == ALLNODE)
best = value, alpha = MAX(alpha, best);
else
maxValue = value;
}
And right at the end of the search, before storing in the table, SF has
Code: Select all
if (PvNode) best = MIN(best, maxValue);
This is part of the "early mate" patch.
Originally, SF simply probed and returned. That works "perfectly" but has the disadvantage of never finding a mate line that at some point enters the TBs. This is now solved by returning only if the TT value is outside the alpha/beta bounds. If it is not, the search is continued. To make sure the TT value is not forgotten if nothing better is found, bestValue or maxValue is adjusted in PV nodes.
If you want to start simple, just return immediately.
Also, do I really need the root_probe_dtz()? Won't the probes inside the search find A winning line on their own?
Not without special precautions. Assume the root node is in the TBs.
If you probe whenever the position is in the TBs, your search will return immediately from the root node and therefore not even look at any of the root moves. So it certainly won't find a winning line.
If you make sure the root node does not probe, your search will return immediately from nodes 1 ply away from the root. So the search will be able to distinguish winning moves from drawing and losing moves, but that is not sufficient even to win KBNK.
The simplest solution is to play a winning move that mates, captures or moves a pawn, if available, and otherwise a winning move that minimises DTZ. That will not be very pretty in certain positions, but it works.
Finally, how to go about showing that TB is worth elo? I normally just test with a 32-concurrency on my machine, but that sounds like a bad idea since that ( maybe ? ) causes 32 copies of the 5man TB to be thrown around.
The memory the TBs are mmap()ed to is shared between all threads and processes mmap()ing those files.
Also, I imagine time control is an important factor. Usually I test with some ultra-bullet TC like fishtest does...
Probing the DTZ tables can take a bit longer, especially if the relevant parts have to be loaded from disk. For normal TCs this should not be a problem as the DTZ tables are probed only at the root (once the root is in the TBs). At ultra-bullet TCs this could be more critical.