when using multiple clang compilers in parallel, it is necessary to use
a matching llvm-profdata, as the profile data format may change between
versions. To use the proper llvm-profdata binary, the one in the same directory
as the compiler is used. This allows for code like:
```bash
echo "Compiling clang"
for comp in clang++-11 clang++-12 clang++-13 clang++-14 clang++-15 clang++-16 clang++-17 clang++-18 clang++-19 clang++-20
do
make -j profile-build CXX=$comp COMP=clang >& out.compile.$comp
mv stockfish stockfish.$comp
done
```
after installing the required versions with the automatic installation script (https://apt.llvm.org/)
closes https://github.com/official-stockfish/Stockfish/pull/5958
No functional change
Currently SF’s quiescence search like most alpha-beta based engines
doesn’t verify for stalemate because doing it each leaf position is to
expensive and costs elo. However in certain positions this creates a
blindspot for SF, not recognizing soon enough that the opponent can
reach a stalemate by sacrifycing his last mobile heavy piece(s). This
tactical motif & it’s measure are similar to zugzwang & verification
search: the measure itself does not gain elo, but prevents SF from
loosing/drawing games in an awkward way.
The fix consists of 3 measures:
1. Make qsearch verify for stalemate on transitions to pure KP-material
for the side to move with our last Rook/Queen just been captured. In
fact this is the scenario where stalemate happens with highest
frequency. The stalemate-verification itself is optimized by merely
checking for pawn pushes & king mobility (captures were already
tried by qssearch)
2. Another culprit for the issue figured out to be SEE based pruning for
checks in step 14. Here often the move forcing the stalemate (or
forcing the opponent to not retake) get pruned away and it need to
much time to reach enough depth. To encounter this we verify
following conditions:
- a) side to move is happy with a draw (alpha < 0)
- b) we are about to sacrify our last heavy & unique mobile piece in
this position.
- c) this piece doesn’t move away from our kingring giving the king a
new square to move.
When all 3 conditions meet we don’t prune the move, because there
is a good chance that capturing the piece means stalemate.
3. Store terminal nodes (mates & stalemates) in TT with higher depth
than searched depth. This prevents SF from:
- reanalyzing the node (=trying to generate legal moves) in vain at
each iterative deepening step.
- overwriting an already correct draw-evaluation from a previous shallow
normal search by a qsearch which doesn’t recognize stalemate and might
store a verry erratic evaluation.
This is due to the 4 constant in the TT-overwrite condition: d -
DEPTH_ENTRY_OFFSET + 2 * pv > depth8 – 4 which allows qs to override
entries made by normal searches with depth <=4.
This 3hrd measure however is not essential for fixing the issue, but
tests (one of vdv & one of mine) seem to suggest that this measure
brings some small benefit.
Another other position where SF benefits from this fix is for instance
Position FEN 8/8/8/1B6/6p1/8/3K1Ppp/3N2kr w - - 0 1 bm f4 +M9
P.S.: Also this issue higly depends on the used net, how good the net is
at evaluate such mobility restricted positions. SF16 was pretty good in
solving 2rr4/5pBk/PqP3p1/1N3pPp/1PQ1bP1P/8/3R4/R4K2 b - - 0 40 bm Rxc6
(< 1 second) while SF16_1 with introduction of the dual net needs about
1,5 minutes and SF17.1 requires 3 minutes to find the drawing move Rxc6.
P.S.2: Using more threads produces indeterminism & using high hash
pressure makes SF reevaluate explored positions more often which makes
it more likely to solve the position. To have stable meaningful results
I tested therfore with one single thread and low hash pressure.
Preliminary LTC test at 30k games
https://tests.stockfishchess.org/tests/view/67ece7a931d7cf8afdc44e18 Elo: 0.04 ± 2.0 (95%) LOS: 51.7%
Total: 24416 W: 6226 L: 6223 D: 11967
Ptnml(0-2): 12, 2497, 7185, 2504, 10
nElo: 0.09 ± 4.4 (95%) PairsRatio: 1.00
Passed LTC no-regression sprt
https://tests.stockfishchess.org/tests/view/67ee8e4631d7cf8afdc452fb
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 401556 W: 101612 L: 101776 D: 198168
Ptnml(0-2): 152, 42241, 116170, 42049, 166
closes https://github.com/official-stockfish/Stockfish/pull/5983
fixes https://github.com/official-stockfish/Stockfish/issues/5899
Bench: 1721673
Since @xu-shawn's refactor the acc pointer has become a bit unnecessary,
we can achieve the same behavior by using the dimension size to get the
right accumulator from the `AccumulatorState`. I think the acc pointer
has become a bit of a burden required to be passed through multiple
different functions together with the necessary templating required.
Passed Non-Regression STC:
https://tests.stockfishchess.org/tests/view/67ed600f31d7cf8afdc45183
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 279744 W: 72037 L: 72082 D: 135625
Ptnml(0-2): 673, 29918, 78767, 29809, 705
closes https://github.com/official-stockfish/Stockfish/pull/5942
No functional change
Official release version of Stockfish 17.1
Bench: 2030154
---
Stockfish 17.1
Today, we have the pleasure to announce Stockfish 17.1. As always, you can
**freely** download it at [stockfishchess.org/download][1] and use it in the
[GUI of your choice][2].
Join our [Discord server][3] to get in touch with the community of developers
and users of the project!
Quality of chess play
In our testing against its predecessor, Stockfish 17.1 shows a consistent
improvement in performance, with an [Elo gain of up to 20 points][4] and
winning close to 2 times more game pairs than it loses.
Update highlights
New speedtest command
The new `speedtest` command benchmarks your computer's performance (measured in
nodes per second) using a realistic and stable test. To run it, you'll need
[command line access][5]—give it a try and share your results with the
community!
Improved hardware support
Stockfish is [no longer limited to 1024 threads][6] and will allow users to
specify whatever their system is capable of. Additionally, hardware such as
ppc64 and Loongson is now better supported at build time.
Bug fixes for tablebase support
Our previous release introduced improved engine lines (principal variations)
ending in mate as soon as a mate score is announced. A side effect of this
improvement was a [rare corner case][7] involving cursed tablebase wins, only
relevant in correspondence chess when the 50-move rule does not apply, which
has now been fixed. Relatedly, [time management][8] has also been improved to
avoid potential time losses.
Shoutouts
Download page redesign
We've redesigned the [download page][1] to address unclear wording and simplify
a previously cluttered experience. The page now features a modernized layout,
streamlined navigation, and clearer guidance to help you select the right
binary for your system.
Fishtest framework
Our testing framework has been improved in various ways, both on the worker
side, including the adoption of [Fastchess][9] as a new game manager, and on
the server side, such as streamlined configuration. The reliable availability
of testing resources is key for the progress of the engine.
Thank you
The Stockfish project builds on a thriving community of enthusiasts (thanks
everybody!) who contribute their expertise, time, and resources to build a free
and open-source chess engine that is robust, widely available, and very strong.
We would like to express our gratitude for the [12k stars][10] that light up
our GitHub project! Thank you for your support and encouragement – your
recognition means a lot to us.
We invite our chess fans to [join the Fishtest testing framework][11] to
contribute compute resources needed for development. Programmers can contribute
to the project either directly to [Stockfish][12] (C++), to [Fishtest][13]
(HTML, CSS, JavaScript, and Python), to our trainer [nnue-pytorch][14] (C++ and
Python), or to our [website][15] (HTML, CSS/SCSS, and JavaScript).
The Stockfish team
[1]: https://stockfishchess.org/download
[2]: https://official-stockfish.github.io/docs/stockfish-wiki/Download-and-usage.html#download-a-chess-gui
[3]: https://discord.gg/GWDRS3kU6R
[4]: https://tests.stockfishchess.org/tests/view/67e7d2fd6682f97da2178fbd
[5]: https://official-stockfish.github.io/docs/stockfish-wiki/UCI-&-Commands.html#speedtest
[6]: 652a8874b5
[7]: 6c7c5c7e47
[8]: 0f9ae0d11c
[9]: https://github.com/Disservin/fastchess
[10]: https://github.com/official-stockfish/Stockfish/stargazers
[11]: https://official-stockfish.github.io/docs/fishtest-wiki/Running-the-Worker.html
[12]: https://github.com/official-stockfish/Stockfish
[13]: https://github.com/official-stockfish/fishtest
[14]: https://github.com/official-stockfish/nnue-pytorch
[15]: https://github.com/official-stockfish/stockfish-web
Helps gcc silence the warning about
```
warning: 'added' may be used uninitialized [-Wmaybe-uninitialized]
const IndexType offsetA0 = TransformedFeatureDimensions * added[0];
```
closes https://github.com/official-stockfish/Stockfish/pull/5950
No functional change
This PR updates the internal WDL model, using data from 2.6M games
played by the revisions since f3bfce3531.
Note that the normalizing constant increases only moderately from 372 to
377.
```
> ./updateWDL.sh --firstrev f3bfce3531
Running: ./updateWDL.sh --firstrev f3bfce3531 --lasttrev HEAD --materialMin 17 --EloDiffMax 5
started at: Sat 22 Mar 11:02:14 CET 2025
Look recursively in directory pgns for games with max nElo difference 5 using books matching "UHO_Lichess_4852_v..epd" for SF revisions between f3bfce3531 (from 2025-02-28 09:50:59 +0100) and HEAD (from 2025-03-21 11:22:59 +0100).
Based on 138253430 positions from 2579360 games, NormalizeToPawnValue should change from 372 to 377.
ended at: Sat 22 Mar 11:04:00 CET 2025
```
```
> cat scoreWDL.log
Converting evals with NormalizeData = {'momType': 'material', 'momMin': 17, 'momMax': 78, 'momTarget': 58, 'as': [-37.45051876, 121.19101539, -132.78783573, 420.70576692]}.
Reading eval stats from updateWDL.json.
Retained (W,D,L) = (33794348, 69943262, 34515820) positions.
Saved distribution plot to updateWDLdistro.png.
Fit WDL model based on material.
Initial objective function: 0.3648260131692729
Final objective function: 0.36482338611818094
Optimization terminated successfully.
const int NormalizeToPawnValue = 377;
Corresponding spread = 71;
Corresponding normalized spread = 0.1879431202530567;
Draw rate at 0.0 eval at material 58 = 0.9902694872976331;
Parameters in internal value units:
p_a = ((-13.500 * x / 58 + 40.928) * x / 58 + -36.828) * x / 58 + 386.830
p_b = ((96.534 * x / 58 + -165.791) * x / 58 + 90.897) * x / 58 + 49.296
constexpr double as[] = {-13.50030198, 40.92780883, -36.82753545, 386.83004070};
constexpr double bs[] = {96.53354896, -165.79058388, 90.89679019, 49.29561889};
Preparing plots.
Saved graphics to updateWDL.png.
Total elapsed time = 46.92s.
```
Only affects displayed `cp` and `wdl` values.
closes https://github.com/official-stockfish/Stockfish/pull/5939
No functional change
