This patch is a simplification and a fix to dealing with null moves scores that returns proven mates or TB scores by preventing 'null move pruning' if the nullvalue is in that range.
Current solution downgrades nullValues on the non-PV node but the value can be used in a transposed PV-node to the same position afterwards (Triangulation), the later is prone to propagate a wrong score (96.05) to root that will not be refuted unless we search further.
Score of (96.05) can be obtained be two methods,
maxim static-eval returned on Pv update (mostly qSearch)
this downgrade (clamp) in NMP
and theoretically can happen with or without TBs but the second scenario is more dangerous than the first.
This fixes the reproducible case in very common scenarios with TBs as shown in the debugging at discord.
Fixes: #4699
Passed STC:
https://tests.stockfishchess.org/tests/view/64c1eca8dc56e1650abba6f9
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 670048 W: 171132 L: 171600 D: 327316
Ptnml(0-2): 2134, 75687, 179820, 75279, 2104
Passed LTC:
https://tests.stockfishchess.org/tests/view/64c5e130dc56e1650abc0438
LLR: 2.95 (-2.94,2.94) <-1.75,0.25>
Total: 92868 W: 23642 L: 23499 D: 45727
Ptnml(0-2): 52, 9509, 27171, 9648, 54
closes https://github.com/official-stockfish/Stockfish/pull/4715
Bench: 1327410
After removing classic evaluation VALUE_KNOWN_WIN is not anymore returned explicit evaluation. So remove and replace it with VALUE_TB_WIN_IN_MAX_PLY.
Measurement on my big bench (bench 16 1 16 pos1000.fen) verifies that at least with current net the calculated evaluation lies always in the open interval (-VALUE_KNOWN_WIN, VALUE_KNOWN_WIN).
So i consider this a non-functional change. But to be safe i tested this also at LTC as requested by Stephane Nicolet.
STC:
https://tests.stockfishchess.org/tests/view/64f9db40eaf01be8259a6ed5
LLR: 2.93 (-2.94,2.94) <-1.75,0.25>
Total: 455296 W: 115981 L: 116217 D: 223098
Ptnml(0-2): 1415, 50835, 123420, 50527, 1451
LTC:
https://tests.stockfishchess.org/tests/view/650bfd867ca0d3f7bbf25feb
LLR: 2.95 (-2.94,2.94) <-1.75,0.25>
Total: 35826 W: 9170 L: 8973 D: 17683
Ptnml(0-2): 12, 3523, 10645, 3722, 11
closes https://github.com/official-stockfish/Stockfish/pull/4792
Bench: 1603079
in the case of avx512 and vnni512 archs.
Up to 17% speedup, depending on the compiler, e.g.
```
AMD pro 7840u (zen4 phoenix apu 4nm)
bash bench_parallel.sh ./stockfish_avx512_gcc13 ./stockfish_avx512_pr_gcc13 20 10
sf_base = 1077737 +/- 8446 (95%)
sf_test = 1264268 +/- 8543 (95%)
diff = 186531 +/- 4280 (95%)
speedup = 17.308% +/- 0.397% (95%)
```
Prior to this patch, it appears gcc spills registers.
closes https://github.com/official-stockfish/Stockfish/pull/4796
No functional change
The commit adds a CI workflow that uses the included-what-you-use (IWYU)
tool to check for missing or superfluous includes in .cpp files and
their corresponding .h files. This means that some .h files (especially
in the nnue folder) are not checked yet.
The CI setup looks like this:
- We build IWYU from source to include some yet unreleased fixes.
This IWYU version targets LLVM 17. Thus, we get the latest release
candidate of LLVM 17 from LLVM's nightly packages.
- The Makefile now has an analyze target that just build the object
files (without linking)
- The CI uses the analyze target with the IWYU tool as compiler to
analyze the compiled .cpp file and its corresponding .h file.
- If IWYU suggests a change the build fails (-Xiwyu --error).
- To avoid false positives we use LLVM's libc++ as standard library
- We have a custom mappings file that adds some mappings that are
missing in IWYU's default mappings
We also had to add one IWYU pragma to prevent a false positive in
movegen.h.
https://github.com/official-stockfish/Stockfish/pull/4783
No functional change
deal with the general case
About a 8.6% speedup (for general arch)
Results for 200 tests for each version:
Base Test Diff
Mean 141741 153998 -12257
StDev 2990 3042 3742
p-value: 0.999
speedup: 0.086
closes https://github.com/official-stockfish/Stockfish/pull/4786
No functional change
The commit removes all uses of ICC's __INTEL_COMPILER macro and other
references to ICC. It also adds ICX info to the compiler command and
fixes two typos in Makefile's help output.
closes https://github.com/official-stockfish/Stockfish/pull/4769
No functional change
Created by retraining the master net on a dataset composed by:
- adding Leela data from T60 jul-dec 2020, T77 nov 2021, T80 jun-jul 2023
- deduplicating and unminimizing parts of the dataset before interleaving
Trained initially with max epoch 800, then increased near the end of training
twice. First to 960, then 1200. After training, post-processing involved:
- greedy permuting L1 weights with https://github.com/official-stockfish/Stockfish/pull/4620
- greedy 2- and 3- cycle permuting with https://github.com/official-stockfish/Stockfish/pull/4640
python3 easy_train.py \
--experiment-name 2048-retrain-S6-sk28 \
--training-dataset /data/S6.binpack \
--early-fen-skipping 28 \
--start-from-engine-test-net True \
--max_epoch 1200 \
--lr 4.375e-4 \
--gamma 0.995 \
--start-lambda 1.0 \
--end-lambda 0.7 \
--tui False \
--seed $RANDOM \
--gpus 0
In the list of datasets below, periods in the filename represent the sequence of
steps applied to arrive at the particular binpack. For example:
test77-dec2021-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
1. test77 dec2021 data rescored with 16 TB of syzygy tablebases during data conversion
2. filtered with csv_filter_v6_dd.py - v6 filtering and deduplication in one step
3. minimized with the original mar2023 implementation of `minimize_binpack` in
the tools branch
4. unminimized by removing all positions with score == 32002 (`VALUE_NONE`)
Binpacks were:
- filtered with: https://github.com/linrock/nnue-data
- unminimized with: https://github.com/linrock/Stockfish/tree/tools-unminify
- deduplicated with: https://github.com/linrock/Stockfish/tree/tools-dd
DATASETS=(
leela96-filt-v2.min.unminimized.binpack
dfrc99-16tb7p-eval-filt-v2.min.unminimized.binpack
# most of the 0dd1cebea57 v6-dd dataset (without test80-jul2022)
# https://github.com/official-stockfish/Stockfish/pull/4606
test60-novdec2021-12tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test77-dec2021-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test78-jantomay2022-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test78-juntosep2022-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test79-apr2022-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test79-may2022-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test80-jun2022-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test80-aug2022-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test80-sep2022-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test80-oct2022-16tb7p.filter-v6-dd.min.binpack
test80-nov2022-16tb7p.filter-v6-dd.min.binpack
test80-jan2023-3of3-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
test80-feb2023-16tb7p.filter-v6-dd.min-mar2023.unminimized.binpack
# older Leela data, recently converted
test60-octnovdec2020-2tb7p.min.unminimized.binpack
test60-julaugsep2020-2tb7p.min.binpack
test77-nov2021-2tb7p.min.dd.binpack
# newer Leela data
test80-mar2023-2tb7p.min.unminimized.binpack
test80-apr2023-2tb7p.filter-v6-sk16.min.unminimized.binpack
test80-may2023-2tb7p.min.dd.binpack
test80-jun2023-2tb7p.min.binpack
test80-jul2023-2tb7p.binpack
)
python3 interleave_binpacks.py ${DATASETS[@]} /data/S6.binpack
Training data can be found at:
https://robotmoon.com/nnue-training-data/
Local elo at 25k nodes per move:
nn-epoch1059 : 2.7 +/- 1.6
Passed STC:
https://tests.stockfishchess.org/tests/view/64fc8d705dab775b5359db42
LLR: 2.93 (-2.94,2.94) <0.00,2.00>
Total: 168352 W: 43216 L: 42704 D: 82432
Ptnml(0-2): 599, 19672, 43134, 20160, 611
Passed LTC:
https://tests.stockfishchess.org/tests/view/64fd44a75dab775b5359f065
LLR: 2.94 (-2.94,2.94) <0.50,2.50>
Total: 154194 W: 39436 L: 38881 D: 75877
Ptnml(0-2): 78, 16577, 43238, 17120, 84
closes https://github.com/official-stockfish/Stockfish/pull/4782
Bench: 1603079
Add more static checks regarding the SIMD width match.
STC: https://tests.stockfishchess.org/tests/view/64f5c568a9bc5a78c669e70e
LLR: 2.95 (-2.94,2.94) <-1.75,0.25>
Total: 125216 W: 31756 L: 31636 D: 61824
Ptnml(0-2): 327, 13993, 33848, 14113, 327
Fixes a bug introduced in 2f2f45f, where with AVX-512 the weights and input to
the last layer were being read out of bounds. Now AVX-512 is only used for the
layers it can be used for. Additional static assertions have been added to
prevent more errors like this in the future.
closes https://github.com/official-stockfish/Stockfish/pull/4773
No functional change
This is a cleanup PR that prepares the automatic checking of missing or
superfluous #include directives via the include-what-you-use (IWYU) tool
on the CI. Unfortunately, IWYU proposes additional includes for
"namespace std" although we don't need them.
To avoid the problem, the commit removes all "using namespace std"
statements from the code and directly uses the std:: prefix instead.
Alternatively, we could add specific usings (e.g. "using std::string")
foreach used type. Also, a mix of both approaches would be possible.
I decided for the prefix approach because most of the files were already
using the std:: prefixes despite the "using namespace std".
closes https://github.com/official-stockfish/Stockfish/pull/4772
No functional change
This patch implements the pure materialistic evaluation called simple_eval()
to gain a speed-up during Stockfish search.
We use the so-called lazy evaluation trick: replace the accurate but slow
NNUE network evaluation by the super-fast simple_eval() if the position
seems to be already won (high material advantage). To guard against some
of the most obvious blunders introduced by this idea, this patch uses the
following features which will raise the lazy evaluation threshold in some
situations:
- avoid lazy evals on shuffling branches in the search tree
- avoid lazy evals if the position at root already has a material imbalance
- avoid lazy evals if the search value at root is already winning/losing.
Moreover, we add a small random noise to the simple_eval() term. This idea
(stochastic mobility in the minimax tree) was worth about 200 Elo in the pure
simple_eval() player on Lichess.
Overall, the current implementation in this patch evaluates about 2% of the
leaves in the search tree lazily.
--------------------------------------------
STC:
LLR: 2.94 (-2.94,2.94) <0.00,2.00>
Total: 60352 W: 15585 L: 15234 D: 29533
Ptnml(0-2): 216, 6906, 15578, 7263, 213
https://tests.stockfishchess.org/tests/view/64f1d9bcbd9967ffae366209
LTC:
LLR: 2.94 (-2.94,2.94) <0.50,2.50>
Total: 35106 W: 8990 L: 8678 D: 17438
Ptnml(0-2): 14, 3668, 9887, 3960, 24
https://tests.stockfishchess.org/tests/view/64f25204f5b0c54e3f04c0e7
verification run at VLTC:
LLR: 2.94 (-2.94,2.94) <0.50,2.50>
Total: 74362 W: 19088 L: 18716 D: 36558
Ptnml(0-2): 6, 7226, 22348, 7592, 9
https://tests.stockfishchess.org/tests/view/64f2ecdbf5b0c54e3f04d3ae
All three tests above were run with adjudication off, we also verified that
there was no regression on matetracker (thanks Disservin!).
----------------------------------------------
closes https://github.com/official-stockfish/Stockfish/pull/4771
Bench: 1393714
To enhance code clarity and prevent potential confusion with the
'r' variable assigned to reduction later in the code, this pull
request renames it to 'reductionScale' when we use the same name
in the reduction() function.
Using distinct variable names for separate functions improves code
readability and maintainability.
closes https://github.com/official-stockfish/Stockfish/pull/4765
No functional change
The UCI protocol is rather technical and has little value in our README. Instead
it should be explained in our wiki. "Contributing" is moved above "Compiling
Stockfish" to make it more prominent.
Also move the CONTRIBUTING.md into the root directory and include it in the
distributed artifacts/releases.
closes https://github.com/official-stockfish/Stockfish/pull/4766
No functional change
This patch decays a little the evaluation (up to a few percent) for
positions which have a large complexity measure (material imbalance,
positional compensations, etc).
This may have nice consequences on the playing style, as it modifies
the search differently for attack and defense, both effects being
desirable:
- to see the effect on positions when Stockfish is defending, let us
suppose for instance that the side to move is Stockfish and the nnue
evaluation on the principal variation is -100 : this patch will decay
positions with an evaluation of -103 (say) to the same level, provided
they have huge material imbalance or huge positional compensation.
In other words, chaotic positions with an evaluation of -103 are now
comparable in our search tree to stable positions with an evaluation
of -100, and chaotic positions with an evaluation of -102 are now
preferred to stable positions with an evaluation of -100.
- the effect on positions when Stockfish is attacking is the opposite.
Let us suppose for instance that the side to move is Stockfish and the
nnue evaluation on the principal variation is +100 : this patch will
decay the evaluation to +97 if the positions on the principal variation
have huge material imbalance or huge positional compensation. In other
words, stable positions with an evaluation of +97 are now comparable
in our search tree to chaotic positions with an evaluation of +100,
and stable positions with an evaluation of +98 are now preferred to
chaotic positions with an evaluation of +100.
So the effect of this small change of evaluation on the playing style
is that Stockfish should now play a little bit more turbulent when
defending, and choose slightly simpler lines when attacking.
passed STC:
LLR: 2.93 (-2.94,2.94) <0.00,2.00>
Total: 268448 W: 68713 L: 68055 D: 131680
Ptnml(0-2): 856, 31514, 68943, 31938, 973
https://tests.stockfishchess.org/tests/view/64e252bb99700912526653ed
passed LTC:
LLR: 2.94 (-2.94,2.94) <0.50,2.50>
Total: 141060 W: 36066 L: 35537 D: 69457
Ptnml(0-2): 71, 15179, 39522, 15666, 92
https://tests.stockfishchess.org/tests/view/64e4447a9009777747553725
closes https://github.com/official-stockfish/Stockfish/pull/4762
Bench: 1426295
Increase reduction on retrying a move we just retreated that falls in a repetition:
if current move can be the same move from previous previous turn then we retreated
that move on the previous turn, this patch increases reduction if retrying that move
results in a repetition.
How to continue from there? Maybe we some variants of this idea could bring Elo too
(only testing the destination square, or triangulations, etc.)
Passed STC:
https://tests.stockfishchess.org/tests/view/64e1aede883cbb7cbd9ad976
LLR: 2.94 (-2.94,2.94) <0.00,2.00>
Total: 424000 W: 108675 L: 107809 D: 207516
Ptnml(0-2): 1296, 47350, 113896, 48108, 1350
Passed LTC:
https://tests.stockfishchess.org/tests/view/64e32d629970091252666872
LLR: 2.94 (-2.94,2.94) <0.50,2.50>
Total: 89682 W: 22976 L: 22569 D: 44137
Ptnml(0-2): 39, 8843, 26675, 9240, 44
closes https://github.com/official-stockfish/Stockfish/pull/4757
bench: 1574347
