Stockfish TI is coming

[Hai]

It sounds like new ShashChess 40.1 is coming

[Modern Times]

Perfect for those Qualcomm Snapdragon X Elite based laptops on the market now, and the next generation of them due early next year.

Exactly
+ we will see more and more ARM laptops.
+ nearly every mobile phone uses ARM, so it's like a big + for everybody
+ compared to amd and intel, with arm we are still at the beginning so we will see a lot of elo+ and speedups on arm devices.
- but engine developers (not only Stockfish developers) must find these improvements.

Yes, but I don't really care for example whether my Windows laptop has AMD, Intel or Qualcomm. Whatever best meets my price, performance and other criteria is what I purchase. Five years ago it was an AMD powered Lenovo, last year it was an Intel powered Lenovo. Let's see what it will be in a few years' time.

[pohl4711]

TI is released, I started the testrun for my UHO-Top15 ratinglist:

https://github.com/official-stockfish/S ... h/releases


Update NNUE architecture to SFNNv10 with Threat Inputs and net nn-49c1193b131c.nnue
This commit introduces Full Threat Input features, which are a subset of Piece(Square)-Piece(Square) pairs. In any given position, the active features consist of pairs where the second piece’s square lies in the attack set of the first piece. This is an extremely simplified explanation that leaves out many details. The already-used HalfKAv2_hm feature set completes the input features.
Minor quantization changes have also been made.

The net nn-49c1193b131c.nnue was trained by vondele using the following setup: https://github.com/vondele/nettest/blob ... reats.yaml

A graphical version of an earlier scheme (with less refinement) that illustrates the core concepts can be found attached.
[NewInputs.pdf](https://github.com/user-attachments/fil ... Inputs.pdf)

Further information, as well as a brief description of the history of development, can be found attached.
[Stockfish threat inputs PR summary.pdf](https://github.com/user-attachments/fil ... ummary.pdf)

This has been a huge effort spanning over half a year, with the original [discussion thread](https://discord.com/channels/4359437104 ... 0388034610) reaching over 11k messages. Thanks to everyone who has contributed.

Monty PRs:
official-monty/Monty#87 (Initial threat input PR)
official-monty/Monty#114 (Fixed threat indexing to take into account colour correctly)
official-monty/Monty#116 (i8 quantisation of weights whilst keeping calculations in i16)

Yukari commit:
yukarichess/yukari@2d482c6 (Threat inputs merged)

Plentychess PRs:
Yoshie2000/PlentyChess#400 (Threat inputs merged)
Yoshie2000/PlentyChess#411 (Threat input weights quantised to i8)

Passed STC:
LLR: 2.93 (-2.94,2.94) <0.00,2.00>
Total: 63424 W: 16956 L: 16591 D: 29877
Ptnml(0-2): 276, 7522, 15797, 7795, 322
https://tests.stockfishchess.org/tests/ ... d2c195c569

Passed LTC:
LLR: 2.95 (-2.94,2.94) <0.50,2.50>
Total: 27876 W: 7417 L: 7110 D: 13349
Ptnml(0-2): 23, 3033, 7530, 3318, 34
https://tests.stockfishchess.org/tests/ ... d2c195c66e

Passed VVLTC (Hash accidentally set to 1/2 normal value for both sides):
LLR: 2.94 (-2.94,2.94) <0.50,2.50>
Total: 12458 W: 3353 L: 3102 D: 6003
Ptnml(0-2): 0, 1106, 3767, 1355, 1
https://tests.stockfishchess.org/tests/ ... d2c195c7cd

This version has also passed non-regression LTC against the originally passed version:
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 51144 W: 13086 L: 12903 D: 25155
Ptnml(0-2): 22, 5167, 15018, 5336, 29
https://tests.stockfishchess.org/tests/ ... 18523314bf

LTC elo estimate on ARM:
1 patch : 13.9 1.9 38296.5 73728 52
2 master : 0.0 ---- 35431.5 73728 48

closes #6411

bench: 2626086

Co-authored-by: Shawn Xu <xu107288696@gmail.com>
Co-authored-by: Timothy Herchen <timothy.herchen@gmail.com>
Co-authored-by: Viren6 <94880762+Viren6@users.noreply.github.com>
Co-authored-by: Yoshie2000 <patrick.leonhardt@gmx.net>
Co-authored-by: Joost Vandevondele <Joost.VandeVondele@gmail.com>
Co-authored-by: rn5f107s2 <clemens.lerchl@gmail.com>
Co-authored-by: cj5716 <125858804+cj5716@users.noreply.github.com>
Co-authored-by: AliceRoselia <63040919+AliceRoselia@users.noreply.github.com>
Co-authored-by: Linmiao Xu <linmiao.xu@gmail.com>
Co-authored-by: Disservin <disservin.social@gmail.com>

[Graham Banks]

Stockfish dev-20251112-8e5392d7 Pre-release

[Modern Times]

I'll wait for the actual release, even though it is likely that there will not be any changes. There is no urgency from my point of view.

[Werewolf]

Looks like this is even better at really long time controls?

[Werewolf]

This is really confusing me. Given what the Ti offers, I would have expected the greatest gains to be when the nodes searched are few, but as node search rises I would expect any advantages to tend toward zero.

In the same way, at very low node count Lc0 would roast SF (if both searched the same few nodes) but as search nodes tends upwards towards infinity I think (?) SF would come out on top or certainly equal.

This Ti seems to buck that trend.

[syzygy]

This is really confusing me. Given what the Ti offers, I would have expected the greatest gains to be when the nodes searched are few, but as node search rises I would expect any advantages to tend toward zero.

In the same way, at very low node count Lc0 would roast SF (if both searched the same few nodes) but as search nodes tends upwards towards infinity I think (?) SF would come out on top or certainly equal.

This Ti seems to buck that trend.

As far as I understand, this change decreases SF's speed. It will play better at the same low node counts because of a more accurate eval, but it needs enough time/nodes to offset the loss of speed.

What potentially might play a role is that a more accurate eval makes the search more efficient.

[Werewolf]

This is really confusing me. Given what the Ti offers, I would have expected the greatest gains to be when the nodes searched are few, but as node search rises I would expect any advantages to tend toward zero.

In the same way, at very low node count Lc0 would roast SF (if both searched the same few nodes) but as search nodes tends upwards towards infinity I think (?) SF would come out on top or certainly equal.

This Ti seems to buck that trend.

As far as I understand, this change decreases SF's speed. It will play better at the same low node counts because of a more accurate eval, but it needs enough time/nodes to offset the loss of speed.

What potentially might play a role is that a more accurate eval makes the search more efficient.

This is wonderful news overall. Perhaps SF will be on the horizon

[chrisw]

This is really confusing me. Given what the Ti offers, I would have expected the greatest gains to be when the nodes searched are few, but as node search rises I would expect any advantages to tend toward zero.

In the same way, at very low node count Lc0 would roast SF (if both searched the same few nodes) but as search nodes tends upwards towards infinity I think (?) SF would come out on top or certainly equal.

This Ti seems to buck that trend.

As far as I understand, this change decreases SF's speed. It will play better at the same low node counts because of a more accurate eval, but it needs enough time/nodes to offset the loss of speed.

What potentially might play a role is that a more accurate eval makes the search more efficient.

Likely. The statistic and the various history tables are smart networks all of their own, in them builds the plan of what to do.