c++ class or a c wrapper for the syzygy egtb

[flok]

[quote="stuwph"to get 6-men working at start of tbcore.c #define HSHMAX 5 needs to be changed to 6

which also relates to GULL syzygy ...[/quote]

Hmmm that's interesting!
The code should maybe compare the TB_LARGEST variable against HSHMAX to prevent these kind of issues.

[flok]

Hi Basil,

I wonder why probe_wdl_table in tbprobe.c contains mutexes and a memory barrier. Because things are not supposed to be running in a thread? I think it only gives extra overhead cost.

[syzygy]

I wonder why probe_wdl_table in tbprobe.c contains mutexes and a memory barrier. Because things are not supposed to be running in a thread? I think it only gives extra overhead cost.

That is just a lock around the code that initialises a table upon the very first access of the table. Since this code is executed at most once for each table, this is perfectly fine and very certainly does not lead to any performance issues. The memory barrier is required to avoid miscompilation of double-checked locking. See this paper, section 2.1.

Probe_wdl() can be called from search threads running in parallel.

[basil00]

The code should maybe compare the TB_LARGEST variable against HSHMAX to prevent these kind of issues.

This issue was fixed: https://github.com/basil00/Fathom/commi ... 31dfec5894
If I had 6-man syzygy then I probably would have noticed this before release...

As for the locking issue, it is as Ronald says.

Note that the locking can be disabled by uncommenting the TB_NO_THREADS macro in tbconfig.h. This is useful for single-threaded applications, or engines like Gull that uses processes instead of threads.

[bob]

So when do you query it?
Do you check every node if total piece_count < x and then check it?

I was asked about this since it seems I am different here. My take has always been to probe when ALL of the following are true:

(1) piece count <= #pieces in tables;

(2) depth > probe_limit;

(3) move at previous ply was a capture;

Reasoning: (1) no point in probing if you have more pieces than your tables cover; (2) don't probe too near the tips or cost explodes; (3) If you capture at ply=10 and drop to 5 pieces and do not get a hit at ply=11, there is no point in probing at ply=12, etc.. This is an indication of an incomplete set of endgame tables but many users do this all the time.

[flok]

When compiling things with "-pedantic", I get the following warnings:

Code: Select all

tbprobe.c: In function ‘probe_ab’:
tbprobe.c:759:18: warning: array subscript is above array bounds [-Warray-bounds]
                 p[i++] = lsb(bb) ^ mirror;
                  ^
tbprobe.c: In function ‘probe_dtz’:
tbprobe.c:903:18: warning: array subscript is above array bounds [-Warray-bounds]
                 p[i++] = lsb(bb) ^ mirror;

Should I be worried?