Weird Phantom-Mates

[R. Tomasi]

Problem persists:

Microsoft compiler, x64 Debug build:

Code: Select all

0:     +7.05469 -
  5.00 N   in    835 mcs =>   5.99 kN/s

1:     +7.07813 - Rd8
   203 N   in   21.2 ms  =>   9.59 kN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   503 N   in   39.4 ms  =>   12.8 kN/s
  

Clang, x64 Debug build:

Code: Select all

0:     +7.05469 -
  5.00 N   in    431 mcs =>   11.6 kN/s

1:     +7.07813 - Rd8
   195 N   in   6.55 ms  =>   29.8 kN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   448 N   in   14.0 ms  =>   31.9 kN/s

Microsoft compiler, x64 Release build:

Code: Select all

0:     +7.05469 -
  5.00 N   in   85.6 mcs =>   58.4 kN/s

1:     +7.07812 - Rd8
   195 N   in    363 mcs =>    537 kN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   448 N   in    618 mcs =>    725 kN/s

Clang, x64 Release build:

Code: Select all

0:     +7.05469 -
  5.00 N   in   55.8 mcs =>   89.6 kN/s

1:     +7.07812 - Rd8
   195 N   in    177 mcs =>   1.10 MN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   448 N   in    248 mcs =>   1.81 MN/s

Apparently the MS Debug build searches more nodes, even at depth 1 (i.e. a certain all-node at the root, it should look at any generated move). I will now implement some sort of tracing to see which moves are left out by the other builds, and why. Maybe some SSE/AVX code paths that do not make it into the MS Debug build?

Microsoft, x64 Release:

Code: Select all

debug-cpu

CPU features:
  X86
  X64
  BMI2
  AVX
  AVX2
  AVX512

Clang, x64 Release:

Code: Select all

debug-cpu

CPU features:
  X86
  X64
  MMX
  BMI
  BMI2
  SSE
  SSE2
  SSE3
  SSSE3
  AVX
  AVX2

Microsoft, x64 Debug:

Code: Select all

debug-cpu

CPU features:
  X86
  X64
  BMI2

Clang, x64 Debug:

Code: Select all

debug-cpu

CPU features:
  X86
  X64
  MMX
  BMI
  BMI2
  SSE
  SSE2
  SSE3
  SSSE3
  AVX
  AVX2

Ok. So the builds do actually differ with respect to what CPU features are enabled/used. That at least seems like a lead worth following...

I will rebuild all four, forcing any fancy SIMD stuff to be disabled and then check if it is still different.

[R. Tomasi]

MS, Release:

Code: Select all

debug-cpu

CPU features:
  X86
  X64

set-fen 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

New position: 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

debug-pvs 3

0:     +7.05469 -
  5.00 N   in   82.8 mcs =>   60.4 kN/s

1:     +7.07812 - Rd8
   203 N   in    403 mcs =>    504 kN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   503 N   in    731 mcs =>    688 kN/s

3:     +8.04297 - Qb4 Re7 Qxb7
  2.41 kN  in   2.91 ms  =>    830 kN/s

Clang, Release:

Code: Select all

debug-cpu

CPU features:
  X86
  X64

set-fen 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

New position: 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

debug-pvs 3

0:     +7.05469 -
  5.00 N   in   68.7 mcs =>   72.8 kN/s

1:     +7.07812 - Rd8
   203 N   in    217 mcs =>    935 kN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   503 N   in    332 mcs =>   1.52 MN/s

3:     +8.04297 - Qb4 Re7 Qxb7
  2.41 kN  in   1.62 ms  =>   1.49 MN/s

MS, Debug:

Code: Select all

debug-cpu

CPU features:
  X86
  X64

set-fen 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

New position: 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

debug-pvs 3

0:     +7.05469 -
  5.00 N   in    828 mcs =>   6.04 kN/s

1:     +7.07813 - Rd8
   203 N   in   20.6 ms  =>   9.83 kN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   503 N   in   38.9 ms  =>   12.9 kN/s

3:     +8.04297 - Qb4 Re7 Qxb7
  2.41 kN  in    225 ms  =>   10.7 kN/s

Clang, Debug:

Code: Select all

debug-cpu

CPU features:
  X86
  X64

set-fen 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

New position: 5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - -

debug-pvs 3

0:     +7.05469 -
  5.00 N   in    439 mcs =>   11.4 kN/s

1:     +7.07813 - Rd8
   203 N   in   7.62 ms  =>   26.7 kN/s

2:     +8.04297 - Qb4 Re7 Qxb7
   503 N   in   14.7 ms  =>   34.3 kN/s

3:     +8.04297 - Qb4 Re7 Qxb7
  2.41 kN  in   81.3 ms  =>   29.7 kN/s

What a relief. So it's some SSE/AVX specific function that misbehaves. I'm now confident that I'll be able to track this down, even if it may take some time/effort. I'll report what exactly the cause was, once I have the bug gone. Meanwhile thanks for the tips and heads-ups!

[R. Tomasi]

Ok. Turn's out it was a subtle bug in the 5-lane SIMD-wise comparator. The automated testing didn't catch it, beacause I only checked if the sorted list is actually in descending order, however I did not check if elements got lost or duplicated during sorting. I'll have to include these checks into the tests.