To Ronald de Man: recent stockfish_syzygy compiles are fishy

[ernest]

This was also noticed by Jouni Uski in http://www.talkchess.com/forum/viewtopi ... 22&start=0

but he never got an answer!

The recent RdM compiles found in the development versions http://abrok.eu/stockfish_syzygy/ are about 40% faster (in nps) than the corresponding original Stockfish development versions found in http://abrok.eu/stockfish/

Are the nodes calculated in a different way in stockfish_syzygy ?

Anyway, here is go depth 22 for both 64-bit versions (the "not modern" ones)

stockfish_syzygy_14021821_x64.exe
Stockfish 180214 64 by Tord Romstad, Marco Costalba and Joona Kiiski
go depth 22
...
info depth 22 seldepth 31 score cp 25 nodes 43184385 nps 1554401 tbhits 0 time 2
7782 multipv 1 pv e2e4 e7e5 g1f3 b8c6 f1c4 g8f6 e1g1 f8c5 b1c3 e8g8 d2d3 h7h6 a2
a3 a7a5 c3d5 d7d6 c2c3 f8e8 c1e3 c8e6 e3c5 d6c5
info nodes 43184385 tbhits 0 time 27782
bestmove e2e4 ponder e7e5

stockfish_14021816_x64.exe
Stockfish 180214 64 by Tord Romstad, Marco Costalba and Joona Kiiski
go depth 22
...
info depth 22 seldepth 29 score cp 26 nodes 11809371 nps 1104815 time 10689 mult
ipv 1 pv e2e4 e7e5 g1f3 g8f6 f3e5 d7d6 e5f3 f6e4 d2d3 e4f6 d3d4 f8e7 f1e2 d6d5 e
1g1 e8g8 b1c3 b8c6 f3e5 e7d6 c1f4 f8e8 e2b5
info nodes 11809371 time 10689
bestmove e2e4 ponder e7e5

Note: in matches against Houdini 4, both Stockfish_syzygy (from RdM) and Stockfish (from dev) perform approx. the same. But the nps of Stockfish_syzygy were even higher than those of Houdini (while for the Stockfish dev, nps are around the usual 2/3).

[syzygy]

This was also noticed by Jouni Uski in http://www.talkchess.com/forum/viewtopi ... 22&start=0

but he never got an answer!

I really do see an answer there.

The only explanation is that some of the recent changes in SF broke things. If that is the case, then the compiles in abrok.eu/stockfish_syzygy/ should be seriously broken.

[ernest]

The only explanation is that some of the recent changes in SF broke things.

Hi Ron,

Then, to investigate, one should look at when was your earliest compile that increased the nps by 40% !
Maybe Marco Costalba has an idea ?

[syzygy]

I just downloaded the latest binaries from abrok.eu and I get very similar nps for both versions. So for me there is no problem until something concrete is shown.

[ernest]

OK, I did a rapid check!

High nps started with:

Code: Select all

Author: Ronald de Man 
Date: Tue Feb 18 21:19:45 2014 +0100 
Timestamp: 1392754785 

Merge remote-tracking branch 'upstream/master' 

Today's last compile is back to normal nps:

Code: Select all

Author: Ronald de Man 
Date: Fri Feb 21 01:07:08 2014 +0100 
Timestamp: 1392941228 

For whatever reason, Marco decided to stop updating pieceCount for ALL_PIECES: 

"Don't update pieceCount for ALL_PIECES 

It is currently unused and only adds 
overhead for nothing." 

[syzygy]

Today's last compile is back to normal nps:

Ok, so it had to do with the funny reversion by Marco of a patch that he committed 4 months ago.

Originally I used popcount to determine whether the number of pieces is 6 or less (assuming 6-piece tables available). I then accepted a patch by Marco that changed this to using piececount[ALL_PIECES]. This turned out not to have been tested and therefore not to work, because SF did not update piececount[ALL_PIECES]. Marco then fixed that because not updating it was "not obvious and so dangerous".

A few days ago this patch was reverted, apparently because not updating piececount[ALL_PIECES] is not dangerous anymore...

[ernest]

So things seem to have gotten back to normal!...
(and I checked again with go depth 22)

Note that I couldn't find anything wrong with the SF sygyzy 16.2 version Juni Uski found to be fast. For me that version isn't even faster than the previous ones.

For me your buggy compiles went from Feb 18 to the 1st compile of Feb 21 (2nd Feb 21 compile is good!)

[mcostalba]

Today's last compile is back to normal nps:

Ok, so it had to do with the funny reversion by Marco of a patch that he committed 4 months ago.

Ooops sorry, didn't mean to break syzygy.

Eventually, in your branch, you can revert that patch in.

[syzygy]

Today's last compile is back to normal nps:

Ok, so it had to do with the funny reversion by Marco of a patch that he committed 4 months ago.

Ooops sorry, didn't mean to break syzygy.

Eventually, in your branch, you can revert that patch in.

For now I'll use popcount. It doesn't seem slower at least on my machine (i7).

[phenri]

Hello,

I noted that TBhits have decreased considerably in certain positions. Is this normal?

[d]1B1b4/7K/1p6/1k6/8/8/8/8 w - - 0 1

Analysis by Stockfish 200214:
1.Ba7 Bh4 2.Bxb6
= (0.00) Depth: 120/4 00:00:01 6004kN, tb=61234


Analysis by Stockfish 220214:
1.Ba7 Bh4 2.Bxb6 Kxb6
= (0.00) Depth: 120/5 00:00:19 204MN, tb=12