Question about mate scores Lc0 vs SF

[OneTrickPony]

Consider this position:
[d]8/8/8/1p2K3/1P6/n5k1/6p1/6N1 b - - 3 60

SF: 3970x, 64GB hash, 48 threads
lc0: 3080, 2000000 NN cache size
Both engines with 6man Syzygy tablebases.

When I run lc0 (J92-290) it instantly shows mate scores, mate in 143 to be precise.
When I run SF (build from 14.10.2020) it shows -152.65 but doesn't show mate scores until around 18 seconds (this is at ~145000kn/s so quite a long time).

How is it possible Leela sees mate so much faster? On the other hand when I leave SF running it quickly finds much quicker mate (M21 after about 2 minutes). I probably don't understand how mate scores work. My understanding is that the engine needs to prove no other branch offers better (longer) defence to show a mate score (so the mate score is always correct, just might be too high). if that's the case it would be quite strange for SF to be that much slower to see proven mate.

[Alayan]

Leela doesn't "see mate", it sees a forced TB win. The displayed mate number comes from this forced TB win, though I'm not sure what the Leela code is doing exactly.

Technically, a proven TB win also gives you a proven mate score upperbound, just a ridiculously high and irrelevant one.

[OneTrickPony]

By "sees mate" I mean exactly that: forced reduction to TBs and being and to infer upper bound for number of moves.
Both engines have access to the same tablebases so SF should see such reduction pretty quickly as well.

I am wondering how it's possible for slow MCTS to see forced reduction faster than fast alpha/beta search.

[jp]

I am wondering how it's possible for slow MCTS to see forced reduction faster than fast alpha/beta search.

If it's a true mate announcement, they both have to go through an entire tree.

Is Leela doing that when it announces mate?

[Alayan]

By "sees mate" I mean exactly that: forced reduction to TBs and being and to infer upper bound for number of moves.
Both engines have access to the same tablebases so SF should see such reduction pretty quickly as well.

I am wondering how it's possible for slow MCTS to see forced reduction faster than fast alpha/beta search.

There is no UCI standard to announce TB win in X.

The internal TB win value in Stockfish is nonsensically scaled by pawn value, but the 152.xx value you see (this might change with pawn value eg) is effectively a forced TB win announcement.