Was SF loss in TCEC VVLTC game 6 due to buggy behavior?

[Laoshi Ma]

I don't know if this has already been discussed, but there is something very strange about

SF behavior in that Pirc-Ufymtsev game. If one looks at the depth graph, during moves

~16-25 the search depth completely collapsed, to values far below what one'd expect

for very long time control. When I tried this for myself, in those positions SF reaches a

depth 20~25 or even lower instantaneously (in the first second), and then doesn't make

any subsequent progress.

I've had this a few times recently in other positions that an SF search just gets stuck at

a certain point, though not this extreme. Didn't use to happen in SF versions prior to

this year for me.

Anybody got an idea what is going on? Maybe some extension explosion? Doesn't

look like intended behavior.

[Laoshi Ma]

Confirm that this is reproducible with the latest SF. I used the 18 June 2022 "Redfish" incarnation

by Windfishballad (should make no difference since the problem originally showed up with vanilla

SF on TCEC), 96 GB hash, 28 threads. Still replaying the Season 22 VVLTC game 6. Up to Black's

move 15, everything looks normal, with typical time-to-depth -- which of course also means that

said depth is steadily increasing. But already at that move 15 for Black, this doesn't help Fish

very much, since it doesn't see that its favored move 15. ... Qd8 is refuted by 16. Nfd2! Up to this

point though, it still looks like normal behavior (search blindness, overpruning) of the sort that

unfortunately happens from time to time.

But once 15. ... Qd8 is played, SF instantaneously sees 16. Nfd2, and sees that it is pretty much

winning. In 8s, it got to d=27 ... and then got stuck there. No further output was given until I

stopped the engine after 2 hours, even though CPU and memory usage all looked normal. At this

point, this seems to be outright broken behavior, which has persisted for ~6 weeks now.

Is this even still the right place to report something of this nature? Or do all the active devs only

follow Discord these days? I'd have thought that an actual SF search bug would elicit some

response. Or perhaps someone is experimenting with this?

[Laoshi Ma]

On the Github list of SF issues, I saw that a lot of the discussion about search anomalies was connected to multithreading (now hopefully addressed with the patch of 9 July). So I decided to redo the experiment with only a single thread. Again, up to move 15 for Black, everything looked normal. Then at move 16 for White, SF got stuck at d=53, at which point it hadn't spotted the win yet; so it reached a high depth, but got stuck nonetheless. It may be that with just one thread, it takes SF a long time to find and enter the key winning line that is causing the problem apparently. At move 16 for Black, SF got stuck at d=34 in under 1 minute, just as it was starting to "suspect something" as evidenced by repeated fail-lows.

NB because of hash, because I use Redfish (no optimism), and because I only have a selection of 7-man TBs installed for space reasons, it's very unlikely that one would reproduce my results exactly, even with a single thread. But the hanging behavior itself *is* reproducible in this Pirc line. It is unrelated to SMP, and since the above is in infinite analysis, anyway it should be completely separate from the now-resolved "search-again" stuff, which is tied to time management if I understood it right.

Since I still had SF13 running on my phone, I also tried this same line there (using four threads IIRC). Even at Black's move 16, it takes a long time to see the loss: SF13 thinks the position is drawn until it finds White's follow-up at moves 19-20. So SF13 is no doubt weaker overall, but the search itself is completely well-behaved, gradually reaching ever-higher depths. Whatever causes the "hanging" glitch, it seems to have entered the SF code since the days of SF13.