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

335 views
Skip to first unread message

Laoshi Ma

unread,
May 13, 2022, 3:52:32 AMMay 13
to FishCooking
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

unread,
Jun 20, 2022, 7:06:17 AMJun 20
to FishCooking
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

unread,
Jul 22, 2022, 5:32:24 AMJul 22
to FishCooking
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.
Reply all
Reply to author
Forward
0 new messages