Performance of Syzygy and Scorpio

[syzygy]

To note that SF Scorpio had a dramatic loss in NPS, on average by a factor 1.7 or so.

Well I already mentioned to Adam syzygy is probed much less frequently than I did because it probes 6 plies away from the root

Where do you get the number 6 from? And what do you mean "away from the root".

My implementation probes whenever remaining depth is at least SyzygyProbeDepth which by default is set to 1. This means it probes everywhere in the regular search (not in the qsearch). If only 5-piece tables are probed, SyzygyProbeDepth should be set to 1 since the WDL tables should easily fit in RAM. NPS should not be affected much (except maybe in the first seconds while the OS pages the tables into the page cache).

There is certainly no minimum number of plies "away from the root" since the closer to root the better.

The exception is probing WDL when the root position is already in the tablebases, since probing immediately would basically lead to random play without progress. In this case I probe immediately after a move that is known to make progress (provided it is winning), i.e. a capture or pawn move. This exception applies only if DTZ is not available.

[ouachita]

thanks again, I'm following this topic with great interest

[syzygy]

The exception is probing WDL when the root position is already in the tablebases, since probing immediately would basically lead to random play without progress. In this case I probe immediately after a move that is known to make progress (provided it is winning), i.e. a capture or pawn move. This exception applies only if DTZ is not available.

I just realised it makes no sense to probe after captures and pawn moves if the root position is a TB loss or TB draw.

I've made a small change that fixes this. The new version will probably be on http://abrok.eu/stockfish_syzygy/ soon.

The previous version would avoid captures and pawn moves when losing. Unless the 50-move rule is in sight this makes it easier for the winning side. A similar problem existed with drawing positions (making it easier to defend the draw for the other side). So this new version might score a bit better.

[Daniel Shawul]

I meant away from the leaves NOT root but I see your limits is different from mine. I limit probe depending on plies away from the root and you use plies from the leaves. I do it like the former because reductions and extension can mess up my evaluation that is dependent on the plies from the root, other wise heavily reduced moves will be prefered. I thought your TBProbeLimit was similar to mine EgbbPlyLimit which had value of 6, but you have something else for TBProbeDepth

Code: Select all

if (   !RootNode
        && depth >= TBProbeDepth
        && pos.count<ALL_PIECES>&#40;WHITE&#41; + pos.count<ALL_PIECES>&#40;BLACK&#41; <= TBCardinality
        && pos.rule50_count&#40;) == 0&#41;
    &#123;

Also your 'new addition' pos.rule50_count() == 0 decreases the number of probes, but that may be a bug. It should be (depth < TBProbeDEpth || pos.rule50_count() == 0).

[syzygy]

Also your 'new addition' pos.rule50_count() == 0 decreases the number of probes, but that may be a bug. It should be (depth < TBProbeDEpth || pos.rule50_count() == 0).

There is no bug. It also does not decrease the number of probes.

If the root is not in the TB, I will probe once the number of pieces is <= 6 (or 5 depending on what tables there are). This will always be immediately after a capture, so the rule50_count() is always 0 in that case.

If the root is in the TB (and no DTZ available), then previously I limited probes to positions with one piece less than the number of pieces on the board (root position). That meant I probed immediately after captures.

I have now changed this to probing immediately after captures and pawn moves even if the number of pieces is equal to the number of pieces on the board (root position). So I probe more than I did before.

Of course my latest change, which disables probing if the root position is a TB draw or TB loss, does limit the number of probes. Probing WDL makes no sense in this case.

[Daniel Shawul]

Also your 'new addition' pos.rule50_count() == 0 decreases the number of probes, but that may be a bug. It should be (depth < TBProbeDEpth || pos.rule50_count() == 0).

There is no bug.

So you do not probe WDL tables even if the number of pieces is 5-men?? This can happen in case the root is a 5-man itself. The below WDL code then will be using Stockfish internal reconginezers instead of giving a cutoff...

Code: Select all

if (   !RootNode 
        && depth >= TBProbeDepth 
        && pos.count<ALL_PIECES>&#40;WHITE&#41; + pos.count<ALL_PIECES>&#40;BLACK&#41; <= TBCardinality 
        && pos.rule50_count&#40;) == 0&#41; 
    &#123; 

[syzygy]

Also your 'new addition' pos.rule50_count() == 0 decreases the number of probes, but that may be a bug. It should be (depth < TBProbeDEpth || pos.rule50_count() == 0).

There is no bug.

So you do not probe WDL tables even if the number of pieces is 5-men??

Every probe inside the search will result in a cut off in my implementation, so I certainly don't want to probe WDL inside the search if the root position is a TB win and I have no clue if I have made any progress at all. The only way to know I made progress is too see whether I made a pawn move or capture.

In my implementation, the engine is searching for a winning pawn move or winning capture. Those are effectively treated as "mate". Progress towards such a move (if within the search horizon) is ensured in exactly the same was as any engine ensure progress towards mate (if within the search horizon).

So if winning pawn moves and captures are not within the search horizon, my implementation indeed relies on SF's evaluation to make progress. So with KBNK it will be the SF KBNK code doing the work. I see no reason why TB probing code should do that.

Of course this is all assuming DTZ tables are not available.

[Daniel Shawul]

Also your 'new addition' pos.rule50_count() == 0 decreases the number of probes, but that may be a bug. It should be (depth < TBProbeDEpth || pos.rule50_count() == 0).

There is no bug.

So you do not probe WDL tables even if the number of pieces is 5-men??

Every probe inside the search will result in a cut off in my implementation, so I certainly don't want to probe WDL inside the search if the root position is a TB win and I have no clue if I have made any progress at all. The only way to know I made progress is too see whether I made a pawn move or capture.

In my implementation, the engine is searching for a winning pawn move or winning capture. Those are effectively treated as "mate". Progress towards such a move (if within the search horizon) is ensured in exactly the same was as any engine ensure progress towards mate (if within the search horizon).

Yes the 'fifty=0' addition certainly helps to cover major progress but it still doesn't cover where cases where pawn pushes or captures are not made to win KBNK or KBBKN f.i. That is why I need to do (depth < limit || fifity == 0). Otherwise you let the search escape the horizon and get back eval() or something else that screws up progress. Stockfish has internal reconginers that helps in that regard but other engines will be screwed.

[syzygy]

Yes the 'fifty=0' addition certainly helps to cover major progress but it still doesn't cover where cases where pawn pushes or captures are not made to win KBNK or KBBKN f.i.

But WDL information is never going to help with KBNK. Every move wins unless it is an obvious blunder.

With KBBKN it is similar, because afaik it is a general win (ignoring the 50-move rule).

In an endgame that is not a general win (I think KBNKN is an example), it might help to probe inside the search to filter out moves that are losing or drawing. That might help the engine to search deep enough to find the win. However, this also gives a lot of probing overhead. Since DTZ solves the problem completely, I don't care enough for this case to try it out.

[Daniel Shawul]

Yes the 'fifty=0' addition certainly helps to cover major progress but it still doesn't cover where cases where pawn pushes or captures are not made to win KBNK or KBBKN f.i.

But WDL information is never going to help with KBNK. Every move wins unless it is an obvious blunder.

With KBBKN it is similar, because afaik it is a general win (ignoring the 50-move rule).

In an endgame that is not a general win (I think KBNKN is an example), it might help to probe inside the search to filter out moves that are losing or drawing. That might help the engine to search deep enough to find the win. However, this also gives a lot of probing overhead. Since DTZ solves the problem completely, I don't care enough for this case to try it out.

This only happens when the root is in TB, so overhead is small and acceptable. In all other cases we need to make atleast one capture to probe the TBs anyway so it doesn't really matter. I have tried it make the engine to escape through the horizon and do search, then adjust the returned value with VALUE_WIN but I realized engine is wasting lot of time on positions that are WDL when it can just add a heurstic eval() and return. If the engine has table for KBNK, then this is workable, but I decided to move away everything to egbb_probe because this only happens when the root is in TB.