Marco Costalba [Sat, 22 Oct 2016 06:21:38 +0000 (08:21 +0200)]
Correcty resey TB hit counter
Restore original behaviour to reset
the counter before a new move search.
Also fixed some warnings and added const
qualifier to a couple of functions, as
suggested by m_stembera.
Thanks to Werner Bergmans for reporting
the regression.
No functional change.
syzygy [Thu, 20 Oct 2016 19:16:09 +0000 (21:16 +0200)]
Per-thread TB hit counters
Use a per-thread counter to reduce contention
with many cores and endgame positions.
Measured around 1% speed-up on a 12 core and 8%
on 28 cores with 6-men, searching on:
7R/1p3k2/2p2P2/3nR1P1/8/3b1P2/7K/r7 b - - 3 38
Also retire the unused set_nodes_searched() and fix
a couple of return types and naming conventions.
No functional change.
Joost Vandevondele [Sun, 16 Oct 2016 13:20:05 +0000 (15:20 +0200)]
Simplify next_move by always scoring evasions
For a default bench, this fixes the last valgrind
error (jump on uninitialised value).
Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 187869 W: 33303 L: 33463 D: 121103
No functional change.
Joost Vandevondele [Wed, 19 Oct 2016 19:29:00 +0000 (21:29 +0200)]
Make valgrind testing part of travis ci.
ajithcj [Sat, 15 Oct 2016 07:29:24 +0000 (07:29 +0000)]
Remove useless assignments to currentMove
We reference (ss-1)->currentMove, i.e. we peek
current move of the parent node, so currentMove
should be valid in the main move loop, when we
search() the subtree, but outside of main loop
it is useless.
No functional change.
VoyagerOne [Sat, 15 Oct 2016 21:35:10 +0000 (17:35 -0400)]
Use explicit logic for pruning
Also a speedup since we don't need to recalculate SEE
for extensions...as it already determined to be positive.
Results for 12 tests for each version:
Base Test Diff
Mean
2132395 2191002 -58607
StDev 128058 85917 134239
p-value: 0.669
speedup: 0.027
Non functional change.
Jacques [Sat, 8 Oct 2016 10:15:43 +0000 (12:15 +0200)]
Fixes for ARM compilation: take 2
The target:
Odroid U3 (http://www.hardkernel.com/main/products/prdt_info.php?g_code=g138745696275)
Debian Jessie
As listed in #550 and #638 three modifications are needed for compilation to work:
float-abi flag for GCC If an FPU is present and supported by the installed os then passed value need to be hard.
I didn't find any better solution than using readelf to check for the availibilty of Tag_ABI_VFP_args which sould indicate support for the FPU. The check is only done if the arch is arm and if readelf is not present
on the system, there will be an error (/bin/sh: 1: readelf: not found) but it will not break and will continue with the default softfp value. Outputing the error is not really acceptable but I wanted some feedback on the
check itself.
-lpthread is needed on armv7 outside of Android
I replaced UNAME with KERNEL and OS to allow to differentiate Android.
m32 flag
My understanding is that outside of Android the flag is generating errors on armv7.
These modifications should introduce change only for non Android armv7 build.
No functional change.
Marco Costalba [Thu, 13 Oct 2016 06:36:30 +0000 (08:36 +0200)]
Revert "Fixes for ARM compilation"
This reverts commit
a3fe80c36ac8ee7677d1f6b7df9b2497e3f755c5.
Break compilation on mingw for me.
Jacques [Sat, 8 Oct 2016 10:15:43 +0000 (12:15 +0200)]
Fixes for ARM compilation
The target:
Odroid U3 (http://www.hardkernel.com/main/products/prdt_info.php?g_code=g138745696275)
Debian Jessie
As listed in #550 and #638 three modifications are needed for compilation to work:
float-abi flag for GCC If an FPU is present and supported by the installed os then passed value need to be hard.
I didn't find any better solution than using readelf to check for the availibilty of Tag_ABI_VFP_args which sould indicate support for the FPU. The check is only done if the arch is arm and if readelf is not present
on the system, there will be an error (/bin/sh: 1: readelf: not found) but it will not break and will continue with the default softfp value. Outputing the error is not really acceptable but I wanted some feedback on the
check itself.
-lpthread is needed on armv7 outside of Android
I replaced UNAME with KERNEL and OS to allow to differentiate Android.
m32 flag
My understanding is that outside of Android the flag is generating errors on armv7.
These modifications should introduce change only for non Android armv7 build.
No functional change.
Marco Costalba [Mon, 10 Oct 2016 15:36:59 +0000 (17:36 +0200)]
AppVeyor: run bench after build
And show resulting bench signature.
The run is very slow becuase optimizations
are all disabled by default /Od /RTC1
No functional change.
Marco Costalba [Mon, 10 Oct 2016 12:21:57 +0000 (14:21 +0200)]
Add AppVeyor integration
It is like Trevis CI but for Windows platform.
Currently just compile builds, wthouth benching
the resulting executable.
No functional change.
ajithcj [Sat, 8 Oct 2016 05:06:33 +0000 (05:06 +0000)]
Simplify futility pruning return value
Return eval as it is while doing futility pruning.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 167687 W: 29778 L: 29904 D: 108005
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 26905 W: 3503 L: 3390 D: 20012
Bench:
5936728
atumanian [Thu, 6 Oct 2016 17:55:10 +0000 (20:55 +0300)]
Optimisation of Position::see and Position::see_sign
Stephane's patch removes the only usage of Position::see, where the
returned value isn't immediately compared with a value. So I replaced
this function by its optimised and more specific version see_ge. This
function also supersedes the function Position::see_sign.
bool Position::see_ge(Move m, Value v) const;
This function tests if the SEE of a move is greater or equal than a
given value. We use forward iteration on captures instread of backward
one, therefore we don't need the swapList array. Also we stop as soon
as we have enough information to obtain the result, avoiding unnecessary
calls to the min_attacker function.
Speed tests (Windows 7), 20 runs for each engine:
Test engine: mean 866648, st. dev. 5964
Base engine: mean 846751, st. dev. 22846
Speedup: 1.023
Speed test by Stephane Nicolet
Fishtest STC test:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 26040 W: 4675 L: 4442 D: 16923
http://tests.stockfishchess.org/tests/view/
57f648990ebc59038170fa03
No functional change.
Stéphane Nicolet [Wed, 5 Oct 2016 22:00:27 +0000 (00:00 +0200)]
Do not use SEE in evasion scoring
Idea by Aram Tumanian (atumanian)
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 43889 W: 7849 L: 7767 D: 28273
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 29333 W: 3809 L: 3700 D: 21824
Bench:
6421663
Stefano Cardanobile [Fri, 30 Sep 2016 18:50:42 +0000 (20:50 +0200)]
Retire implicit malus for stonewalls
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75864 W: 13466 L: 13437 D: 48961
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 99050 W: 12472 L: 12451 D: 74127
bench:
6098474
VoyagerOne [Mon, 3 Oct 2016 13:36:40 +0000 (09:36 -0400)]
Allow inCheck pruning
This is a bit tricky because we don't want
to prune the only legal evasions, even if
with negative SEE. So add an assert to avoid
this subtle bug to slip in later.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 14140 W: 2625 L: 2421 D: 9094
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 11558 W: 1555 L: 1379 D: 8624
bench:
5256717
Marco Costalba [Thu, 29 Sep 2016 13:24:36 +0000 (15:24 +0200)]
Remove useless razoring condition
Condition is always true! For any value of the
array index! Even an out of bound array, like
razor_margin[120]!!!!
No functional change.
HiraokaTakuya [Wed, 28 Sep 2016 22:11:03 +0000 (07:11 +0900)]
Make razor_margin[4] ONE_PLY value independent
No functional change.
Stéphane Nicolet [Fri, 23 Sep 2016 17:28:34 +0000 (19:28 +0200)]
Rename shift_bb() to shift()
Rename shift_bb() to shift(), and DELTA_S to SOUTH, etc.
to improve code readability, especially in evaluate.cpp
when they are used together:
old b = shift_bb<DELTA_S>(pos.pieces(PAWN))
new b = shift<SOUTH>(pos.pieces(PAWN))
While there fix some small code style issues.
No functional change.
joergoster [Wed, 21 Sep 2016 12:02:35 +0000 (14:02 +0200)]
Allowing singular extension in mate positions
Drop useless condition
abs(ttValue) < VALUE_KNOWN_WIN
And extend singular extension search to cases when ttValue
stores a mate score. This improves mate finding and does
not introduce any regression.
Yery tested this patch against current master on the 6500+
Chest mate suite with 200K fixed nodes:
shortest mates found: master: 1206 patch:1205
any mate found: master: 1903 patch: 2003
with 1 sec time:
shortest mates found: master: 2667 patch: 2628
any mate found: master: 3585 patch: 3646
Verified for no regression:
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 25655 W: 4578 L: 4465 D: 16612
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 66247 W: 8618 L: 8557 D: 49072
bench:
6335042
Marco Costalba [Sat, 24 Sep 2016 05:30:37 +0000 (07:30 +0200)]
Fix crash when passing a mate/stalemate position
Both Tablebases::filter_root_moves() and
extract_ponder_from_tt(9 were unable to handle
a mate/stalemate position.
Spotted and reported by Dann Corbit.
Added some mate/stalemate positions to bench so
to early catch this regression in the future.
No functional change.
Stéphane Nicolet [Wed, 21 Sep 2016 07:32:00 +0000 (09:32 +0200)]
Simplify pinners conditions in SEE()
Use the following transformations:
- to check that A is included in B, testing "(A & ~B) == 0" is faster
than "(A & B) == A"
- to remove the intersection of A and B from A, doing "A &= ~B;" is as
fast as "if (A & B) A &= ~B;" but is simpler.
Overall, the simpler patch version is 0.3% than current master.
No functional change.
Guenther Demetz [Mon, 19 Sep 2016 06:21:41 +0000 (08:21 +0200)]
Fix pin-aware SEE
Correct pinners calculation and fix bug with pinned
pieces giving check. With this patch 'pinners' only
returns sliders with exactly one defensive piece between
the slider and the attacked square (in other words, pinners
returns exact pinners).
This was a co-operation between Marco Costalba,
Stéphane Nicolet and me.
Special thanks to Ronald de Man for reporting the bug with
pinned pieces giving check, discussed here:
https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/S_4E_Xs5HaE
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 132118 W: 23578 L: 23645 D: 84895
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 36424 W: 4770 L: 4670 D: 26984
bench:
6272231
Joost Vandevondele [Sat, 17 Sep 2016 11:37:11 +0000 (13:37 +0200)]
Use fixed depth bench to make PGO builds more reproducible
Discussed on fishcooking
proposal and objdump verification:
https://groups.google.com/d/msg/fishcooking/4_ausUwMXP0/EGPsMYqOFAAJ
verified no significant speed difference between depth and time:
https://groups.google.com/d/msg/fishcooking/4_ausUwMXP0/KazW5QZmFgAJ
stockfish_time - stats:
mean =
2207232.56 std = 7079.51 std/mean = 0.003207
stockfish_depth - stats:
mean =
2201783.57 std = 6356.69 std/mean = 0.002887
No functional change
Marco Costalba [Sat, 17 Sep 2016 08:13:38 +0000 (10:13 +0200)]
Fix a warning with MSVC
warning C4706: assignment within conditional expression
No functional change.
Stéphane Nicolet [Fri, 16 Sep 2016 16:18:53 +0000 (18:18 +0200)]
Swap mg and eg in internal representation of Score
Instrumentation shows that in make_score(mg, eg) calls, the mg value is
zero in 25,9% of the calls while the eg value is zero in 36,8% of the
calls.
Swapping the internal fields of mg and eg in the internal
representation of Score allows the compiler to optimize away the shift
in (eg << 16) + mg in more cases, thus resulting in a 0.3% speed-up
overall.
No functional change
Marco Costalba [Sat, 17 Sep 2016 06:19:06 +0000 (08:19 +0200)]
Fix indentation in struct FromToStats
And other little trivial stuff.
No functional change.
Stéphane Nicolet [Wed, 7 Sep 2016 21:37:06 +0000 (23:37 +0200)]
Retire KingDanger array
Rescales the king danger variables in evaluate_king() to
suppress the KingDanger[] array. This avoids the cost of
the memory accesses to the array and simplifies the non-linear
transformation used.
Full credits to "hxim" for the seminal idea and implementation,
see pull request #786.
https://github.com/official-stockfish/Stockfish/pull/786
Passed STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9649 W: 1829 L: 1689 D: 6131
Passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 53494 W: 7254 L: 7178 D: 39062
Bench:
6116200
Marco Costalba [Mon, 29 Aug 2016 07:11:20 +0000 (09:11 +0200)]
Use per-thread counterMoveHistory
Drops a scalability bottleneck due to memory contention
of a single shared table across threads. The effect starts
to be sensible with a high number of threads. Specifically
we have a small regression with 7 threads both at 60 and
180 seconds TC:
10000 @ 60+0.6 th 7
ELO: -2.46 +-3.2 (95%) LOS: 6.5%
Total: 9896 W: 1037 L: 1107 D: 7752
5000 @ 180+0.6 th 7
ELO: -1.95 +-4.1 (95%) LOS: 17.7%
Total: 5000 W: 444 L: 472 D: 4084
We have a regression because counterMoveHistory table is
quite big and it takes time for a single thread to fill it.
Sharing the table yields to a higher fill rate and better
quality of moves and up to 7 threads the benefits of sharing
more then compensate the loss in speed due to contention.
Interestingly even with a 3X longer TC, so with more time
for the single thread to catch up, the improvment is quite
limited and below noise level. It seems we really need much
longer TC to saturate the table.
When we move to high threads number it's another story:
5000 @ 60+0.6 th 22
ELO: 3.49 +-4.3 (95%) LOS: 94.6%
Total: 4880 W: 490 L: 441 D: 3949
2000 @ 60+0.6 th 32
ELO: 8.34 +-6.9 (95%) LOS: 99.1%
Total: 2000 W: 229 L: 181 D: 1590
As expected the speed-up more than compensates the filling
rate, and we expect that with tournament TC, where single
thread is able to saturate the table, the difference will
be even stronger. For instance for TCEC 9 super-final time
control will be 180 minutes + 15 seconds and this scalability
improvement seems definitely the way to go.
So, summarizing:
GOOD:
Measured big improvement in high core scenario
Suitable for TCEC 9 superfinal (big hardware, very long TC)
Consistent and natural patch that extends to counterMoveHistory
what we already do for remaining history tables, that are all per-thread
Non functional change for the common case of a single core
Very simple (just 6 lines modified, no added ones)
BAD:
Small regression (within 2-3 ELO) with few threads and short TC
bench:
5341477
Marco Costalba [Thu, 15 Sep 2016 06:38:20 +0000 (08:38 +0200)]
Renaming in MovePicker
Rename stages and simplify a bit the code.
No functional change.
Marco Costalba [Wed, 14 Sep 2016 13:43:56 +0000 (15:43 +0200)]
Retire MovePicker::see_sign()
No more used after last patch.
No functional change.
VoyagerOne [Wed, 14 Sep 2016 13:09:41 +0000 (09:09 -0400)]
Tweak SEE margin in pruning conditions
Use 35 * depth^2 to calculate see_margin.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 22636 W: 4212 L: 3990 D: 14434
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 47241 W: 6314 L: 6041 D: 34886
The Movepick SEE is now dead code, retire it.
Bench:
5341477
syzygy [Sat, 10 Sep 2016 19:37:36 +0000 (21:37 +0200)]
Integrate next_stage() logic into next_move()
Measured bench speed up goes from 0,7% to 2%,
given the unreliable measure a reverse simmplification
test was done on fishtest:
master vs patch
LLR: -2.94 (-2.94,2.94) [-3.00,1.00]
Total: 15499 W: 2685 L: 2867 D: 9947
Test result is positive, master is weaker.
No functional change.
Guenther Demetz [Mon, 12 Sep 2016 12:30:52 +0000 (14:30 +0200)]
Simplify code for pinaware SEE
This is the most compact and neatest version
is was able to produce.
On normal builds I have a small slowdown:
normal builds base vs. simplification (gcc 4.8.1 Win7-64 i7-3770 @ 3.4GHz x86-64-modern)
Results for 20 tests for each version:
Base Test Diff
Mean
1974744 1969333 5411
StDev 11825 10281 5874
p-value: 0,178
speedup: -0,003
On pgo-builds however I measure a nice 1.1% speedup
pgo-builds base vs. simplification
Results for 20 tests for each version:
Base Test Diff
Mean
1974119 1995444 -21325
StDev 8703 5717 4623
p-value: 1
speedup: 0,011
No functional change.
Guenther Demetz [Mon, 12 Sep 2016 06:47:19 +0000 (08:47 +0200)]
Pinned aware SEE
Don't allow pinned pieces to attack the exchange-square as long all
pinners (this includes also potential ones) are on their original
square.
As soon a pinner moves to the exchange-square or get captured on it, we
fall back to standard SEE behaviour.
This correctly handles the majority of cases with absolute pins.
bench:
6883133
Stefano Cardanobile [Sat, 10 Sep 2016 15:23:26 +0000 (17:23 +0200)]
Reorder evaluation start
In evaluate, we start by initializing the pos.psq_score
and adding the material imbalance. After that, we check
whether a specialized eval exists and if yes we return
that value and discard whatever we have computed until now.
It sounds more logical to first probe material entry and
return if we have a specialized eval, and only if it is
not the case initialize eval with some values. There is
no measurable speed-difference on my computer.
Non functional change.
Marco Costalba [Fri, 9 Sep 2016 06:38:44 +0000 (08:38 +0200)]
Use Movepick SEE value in search
This halves the calls to the costly pos.see_sign(),
speed up is about 1-1.3%
Non functional change.
Marco Costalba [Thu, 8 Sep 2016 03:57:52 +0000 (05:57 +0200)]
Refactor previous patch
No functional change.
ajithcj [Thu, 8 Sep 2016 03:51:41 +0000 (05:51 +0200)]
Prune dangerous moves at low depth
At very low depths prune captures,
promotions and checks if see is negative.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 6772 W: 1328 L: 1173 D: 4271
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 8917 W: 1270 L: 1122 D: 6525
bench:
6024713
Marco Costalba [Sun, 4 Sep 2016 13:29:11 +0000 (15:29 +0200)]
Syntactic sugar to loop across pieces
Also add some comments to the new operator~(Piece).
No functional change.
syzygy [Sat, 3 Sep 2016 16:14:01 +0000 (18:14 +0200)]
Change from [Color][PieceType] to [Piece]
Speed up of almost 1% in both normal and
pgo builds.
No functional change.
Marco Costalba [Sat, 3 Sep 2016 06:19:17 +0000 (08:19 +0200)]
Fix syzygy with partial TB
In case we have installed a not complete set of 6-men tables and
there is 6 piece position on board, but no corresponding
tablebase engine is not using any syzygy at all.
Reported by Jouni Uski, fix by Peter Österlund,
confirmed as a bug by Ronald de Man.
bench:
7591630
Stéphane Nicolet [Fri, 2 Sep 2016 22:04:20 +0000 (00:04 +0200)]
Space bonus in presence of open files
If the opponent has a cramped position, opening a file often
helps him/her to exchange pieces, so it makes sense to reduce
the space bonus if there are open files.
Credits: Leonardo Ljubičić for the strategic idea, Alain Savard for the
implementation of the open files calculation, "CrunchyNYC" for the
compensation of the numerator.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 49112 W: 9239 L: 8900 D: 30973
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 89415 W: 12014 L: 11601 D: 65800
Bench:
7591630
lucasart [Tue, 30 Aug 2016 12:27:05 +0000 (20:27 +0800)]
Change exclusion key setup
Should depend on which move is excluded. This
allow us to remove the dedicated Position::exclusion_key().
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 59814 W: 11136 L: 11083 D: 37595
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 31023 W: 4187 L: 4080 D: 22756
bench
7553379
Stefano80 [Tue, 30 Aug 2016 18:15:51 +0000 (20:15 +0200)]
Retire linear imbalance
Retire linear imbalance and compensate
in piece values enumeration.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 43596 W: 8105 L: 8023 D: 27468
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 24482 W: 3352 L: 3237 D: 17893
Bench:
7777707
ajithcj [Wed, 31 Aug 2016 05:51:52 +0000 (05:51 +0000)]
Optimize order of a few conditions in search
Also fix size of KingDanger array to reduce memory footprint.
Small speed up of around 0.5%
No functional change.
VoyagerOne [Sat, 27 Aug 2016 17:21:06 +0000 (13:21 -0400)]
Remove condition on killers in history pruning
Now allows main killer to be history prune.
STC:
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 15852 W: 2910 L: 2781 D: 10161
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 56428 W: 7610 L: 7537 D: 41281
Bench:
8032058
Stefan Geschwentner [Sun, 28 Aug 2016 10:39:49 +0000 (12:39 +0200)]
Tweak probcut threshold
Use better threshold for capture move generation.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 23265 W: 4415 L: 4188 D: 14662
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 36618 W: 5083 L: 4836 D: 26699
bench:
7030088
Andrew Grant [Sun, 28 Aug 2016 07:23:36 +0000 (03:23 -0400)]
Removed an extra space
No functional change.
Alain SAVARD [Sat, 27 Aug 2016 22:16:28 +0000 (18:16 -0400)]
Move king tropism to evaluate_king
No functional change.
Marco Costalba [Sat, 27 Aug 2016 08:05:42 +0000 (10:05 +0200)]
Retire CheckInfo
Move its content directly under StateInfo.
Verified for no speed regression.
No functional change.
Marco Costalba [Sat, 27 Aug 2016 10:16:13 +0000 (12:16 +0200)]
Silence some warnings with MSVC 2013
No functional change.
Stéphane Nicolet [Sun, 3 Jul 2016 08:35:44 +0000 (10:35 +0200)]
Move CheckInfo under StateInfo
This greately simplifies usage because hides to the
search the implementation specific CheckInfo.
This is based on the work done by Marco in pull request #716,
implementing on top of it the ideas in the discussion: caching
the calls to slider_blockers() in the CheckInfo structure,
and simplifying the slider_blockers() function by removing its
first parameter.
Compared to master, bench is identical but the number of calls
to slider_blockers() during bench goes down from
22461515 to
18853422,
hopefully being a little bit faster overall.
archlinux, gcc-6
make profile-build ARCH=x86-64-bmi2
50 runs each
bench:
base =
2356320 +/- 981
test =
2403811 +/- 981
diff = 47490 +/- 1828
speedup = 0.0202
P(speedup > 0) = 1.0000
perft 6:
base =
175498484 +/- 429925
test =
183997959 +/- 429925
diff =
8499474 +/- 469401
speedup = 0.0484
P(speedup > 0) = 1.0000
perft 7 (but only 10 runs):
base =
185403228 +/- 468705
test =
188777591 +/- 468705
diff =
3374363 +/- 476687
speedup = 0.0182
P(speedup > 0) = 1.0000
$ ./pyshbench ../Stockfish/master ../Stockfish/test 20
run base test diff
...
base =
2501728 +/- 182034
test =
2532997 +/- 182034
diff = 31268 +/- 5116
speedup = 0.0125
P(speedup > 0) = 1.0000
No functional change.
Marco Costalba [Fri, 19 Aug 2016 10:17:38 +0000 (12:17 +0200)]
Make engine ONE_PLY value independent
This non-functional change patch is a deep work to allow SF to be independent
from the actual value of ONE_PLY (currently set to 1). I have verified SF is
now independent for ONE_PLY values 1, 2, 4, 8, 16, 32 and 256.
This patch gives consistency to search code and enables future work, opening
the door to safely tweaking the ONE_PLY value for any reason.
Verified for no speed regression at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 95643 W: 17728 L: 17737 D: 60178
No functional change.
gamander [Wed, 24 Aug 2016 21:37:45 +0000 (23:37 +0200)]
Fixed wrong definition of WhiteCamp and BlackCamp
No functional change.
hxim [Fri, 26 Aug 2016 17:47:40 +0000 (19:47 +0200)]
Simplify stats update
Simplify code by moving countermove and follow-up move
history update into procedure.
No functional change.
Marco Costalba [Wed, 24 Aug 2016 14:52:05 +0000 (16:52 +0200)]
Reformat stats update
Rewritten in a way to have explicit in the search
the bonus/penalty we apply: hopefully this will lead
to further simplification/fix of current rather messy
stats update code.
No functional change.
VoyagerOne [Tue, 23 Aug 2016 13:57:56 +0000 (09:57 -0400)]
Refutation penalty on captures
Apply refutation penalty for prior PV quiet move on captures
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 8208 W: 1153 L: 1008 D: 6047
http://tests.stockfishchess.org/tests/view/
57bc5a9f0ebc59030fbe47b5
Only LTC because a very similar patch already passed STC + LTC
bench:
7038730
VoyagerOne [Mon, 15 Aug 2016 15:19:21 +0000 (11:19 -0400)]
Simplify IID
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30468 W: 5687 L: 5582 D: 19199
http://tests.stockfishchess.org/tests/view/
57b1ddd80ebc591c761f63e2
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 87406 W: 11756 L: 11725 D: 63925
http://tests.stockfishchess.org/tests/view/
57b212590ebc591c761f63f9
bench:
6554900
VoyagerOne [Tue, 16 Aug 2016 13:53:45 +0000 (09:53 -0400)]
Do LMR on captures
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 5361 W: 1086 L: 936 D: 3339
http://tests.stockfishchess.org/tests/view/
57b31b0f0ebc591c761f643d
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 54694 W: 7591 L: 7287 D: 39816
http://tests.stockfishchess.org/tests/view/
57b3442b0ebc591c761f6450
bench:
6881120
Marco Costalba [Thu, 18 Aug 2016 08:40:56 +0000 (10:40 +0200)]
Remove a stale assignment
No more used after previous patch.
Spotted by Jekaa .
No functional change.
Stefano80 [Mon, 15 Aug 2016 10:24:48 +0000 (12:24 +0200)]
Retire pawn span
Retire pawn span and replace with pawn count in evaluate_scale_factor.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 26482 W: 4929 L: 4818 D: 16735
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 61938 W: 8400 L: 8335 D: 45203
Bench:
7662861
VoyagerOne [Fri, 12 Aug 2016 17:55:12 +0000 (13:55 -0400)]
Use predicted depth for history pruning
STC: (Yellow)
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 69115 W: 12880 L: 12797 D: 43438
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 124163 W: 16923 L: 16442 D: 90798
Note: Note based off past experiments / patches... history pruning
is quite TC sensitive. I believe the reason for this TC dependency
is that the CMH/FMH is a very large table that takes time to fill
up with. In addition having more time for will increase the accuracy
of the stats' value.
Bench:
7351698
Luca Brivio [Thu, 11 Aug 2016 23:48:38 +0000 (01:48 +0200)]
Cap space evaluation bonus
When computing space evaluation, limit the bonus square count to 16.
STC @ 10+0.1 th 1:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 30793 W: 5910 L: 5648 D: 19235
LTC @ 60+0.6 th 1:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 31361 W: 4410 L: 4184 D: 22767
Bench:
7165385
Alain SAVARD [Fri, 5 Aug 2016 14:09:22 +0000 (10:09 -0400)]
Simplify space formula
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 16868 W: 3260 L: 3132 D: 10476
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 16910 W: 2381 L: 2255 D: 12274
bench:
6663531
VoyagerOne [Mon, 25 Jul 2016 13:53:18 +0000 (09:53 -0400)]
Use Color-From-To history stats to help sort moves
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 33502 W: 6498 L: 6223 D: 20781
http://tests.stockfishchess.org/tests/view/
578abb940ebc5972faa169e2
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 50782 W: 7124 L: 6832 D: 36826
http://tests.stockfishchess.org/tests/view/
578b8e5d0ebc5972faa169fd
LTC: (Sanity test against latest master)
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 32759 W: 4600 L: 4370 D: 23789
http://tests.stockfishchess.org/tests/view/
5798b7d30ebc591c761f5b72
bench:
6985912
P.S. Thanks @mstembera for rewriting my code to make it smp compatible. A BIG thank you!
VoyagerOne [Sat, 30 Jul 2016 03:28:03 +0000 (23:28 -0400)]
Futility tweak
Use a different margin for pruning child nodes.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 16692 W: 3251 L: 3051 D: 10390
http://tests.stockfishchess.org/tests/view/
579b95d10ebc591c761f5c03
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 24140 W: 3501 L: 3297 D: 17342
http://tests.stockfishchess.org/tests/view/
579bb15d0ebc591c761f5c0b
Bench:
7927017
ajithcj [Sat, 16 Jul 2016 17:23:17 +0000 (17:23 +0000)]
Allow null pruning at depth 1
This removes a check that prevents null pruning at depth 1 PLY.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 23445 W: 4638 L: 4521 D: 14286
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 61416 W: 8627 L: 8563 D: 44226
bench:
8145304
Stefano80 [Sat, 23 Jul 2016 07:49:18 +0000 (09:49 +0200)]
See prune at higher depth
Allow SEE pruning at higher depths in shallow depth
pruning using a threshold increasing with depth.
STC
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35366 W: 7011 L: 6724 D: 21631
LTC
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 15578 W: 2243 L: 2070 D: 11265
Bench:
8417887
ajithcj [Thu, 14 Jul 2016 08:14:32 +0000 (08:14 +0000)]
Gradually relax the NMP staticEval check
Gradually relax the NMP staticEval check as we go to
higher depths.
Use tuned values.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 16745 W: 3371 L: 3168 D: 10206
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 5906 W: 875 L: 736 D: 4295
bench:
8548212
Lyudmil Antonov [Tue, 12 Jul 2016 09:39:47 +0000 (12:39 +0300)]
Workaround gcc stack alignment bug
GCC uses SSE instructions to move data but in 32-bit gcc version used
by abrok the stack is not 16-byte aligned due to a bug.
This patch workaround teh bug by not using the stack
to store KingFlank[]
Fixes issue #721.
No functional change.
joergoster [Sat, 9 Jul 2016 19:01:42 +0000 (21:01 +0200)]
Fix extract_ponder_from_tt()
Checking for legality of a possible ponder move
must be done before we undo the first pv move,
of course. (spotted by mohammed li.)
This obviously only has any effect when playing in ponder mode.
No functional change.
Stéphane Nicolet [Thu, 7 Jul 2016 23:03:06 +0000 (01:03 +0200)]
King tropism
Bonus for each square that we attack in the flank where the opponent
king is. Squares that we attack twice and are not protected by an enemy
pawn count double.
Passed STC:
http://tests.stockfishchess.org/tests/view/
577dfca60ebc5972faa166b8
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 48373 W: 9832 L: 9481 D: 29060
And LTC:
http://tests.stockfishchess.org/tests/view/
577e77870ebc5972faa166df
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 8881 W: 1408 L: 1255 D: 6218
Bench:
7577046
Alain SAVARD [Sun, 3 Jul 2016 12:29:53 +0000 (08:29 -0400)]
More safe checks
Consider a check given by a rook or a minor to be a "safe check"
also in the case where supported by another piece,
and given on a square only defended by a queen
Was yellow STC
http://tests.stockfishchess.org/tests/view/
576fcbc80ebc5972faa163e8
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 55453 W: 10431 L: 10315 D: 34707
Passed LTC
http://tests.stockfishchess.org/tests/view/
57733a0b0ebc5972faa164b7
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 54550 W: 7671 L: 7365 D: 39514
bench:
7398346
ajithcj [Fri, 24 Jun 2016 17:10:25 +0000 (17:10 +0000)]
Use staticEval in null prune condition
Don't null prune at depth < 12 if staticEval < beta
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 62858 W: 12035 L: 11632 D: 39191
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 49784 W: 7009 L: 6720 D: 36055
bench:
8054611
loco-loco [Sat, 25 Jun 2016 02:20:14 +0000 (19:20 -0700)]
Removing inCheck condition for counter move bonus
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20206 W: 3946 L: 3823 D:
LTC:
LLR: 3.10 (-2.94,2.94) [-3.00,1.00]
Total: 25004 W: 3512 L: 3390 D: 18102
Bench:
8172428
Marco Costalba [Sat, 25 Jun 2016 09:42:43 +0000 (11:42 +0200)]
Restore standard passed pawn definition
Use the usual and accepted passed pawn semantic
instead of a non-standard one and remove a FIXME.
STC (http://tests.stockfishchess.org/tests/view/
576401350ebc5972faa1608d):
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 29646 W: 5663 L: 5557 D: 18426
LTC (http://tests.stockfishchess.org/tests/view/
5764e4e90ebc5972faa160c3):
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 40224 W: 5578 L: 5484 D: 29162
bench:
7543902
ElbertoOne [Thu, 23 Jun 2016 14:14:51 +0000 (16:14 +0200)]
Remove redundant PvNode condition
After commit
6d58bf777caa323 we always call PvNodes
with cutNode set to false.
No functional change.
VoyagerOne [Thu, 23 Jun 2016 14:08:43 +0000 (10:08 -0400)]
Comment out a redundant condition
Take advantage that VALUE_NONE = 32002 to remove
the condition.
Commented out and not removed becuase it is tricky
to rely on the hidden value of VALUE_NONE and code
can break in case we change VALUE_NONE in the future.
No functional change.
Jonathan Calovski [Sun, 19 Jun 2016 21:31:12 +0000 (07:31 +1000)]
Remove scalefactor dependency
STC
http://tests.stockfishchess.org/tests/view/
5764539e0ebc5972faa160a4
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 43878 W: 8289 L: 8208 D: 27381
LTC
http://tests.stockfishchess.org/tests/view/
5764f0130ebc5972faa160c9
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 39338 W: 5408 L: 5313 D: 28617
bench:
7977279
ElbertoOne [Mon, 13 Jun 2016 07:10:37 +0000 (09:10 +0200)]
On IID do not always search with cutNode = true
On IID now search with cutNode value instead of fixed value true.
STC (http://tests.stockfishchess.org/tests/view/
575fa3860ebc5972faa15f67):
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 163974 W: 30744 L: 30874 D: 102356
LTC (http://tests.stockfishchess.org/tests/view/
5763b0640ebc5972faa16075):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 48363 W: 6611 L: 6528 D: 35224
Bench:
7806393
VoyagerOne [Sun, 12 Jun 2016 04:40:10 +0000 (00:40 -0400)]
Simplify Check Extension
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32704 W: 6146 L: 6045 D: 20513
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 146622 W: 19967 L: 20017 D: 106638
Bench:
8245662
ajithcj [Fri, 10 Jun 2016 18:10:40 +0000 (18:10 +0000)]
Don't insert pv back into tt
This code was added before the accurate pv patch, when
we retrieved PV directly from TT.
It's not required for correct (and long) PVs any more and
should be safe to remove it.
Also, allowing helper threads to repeatedly over-write
TT doesn't seem to make sense(that was probably an un-intended
side-effect of lazy smp). Before Lazy SMP only Main Thread used
to run ID loop and insert PV into TT.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 74346 W: 13946 L: 13918 D: 46482
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 47265 W: 6531 L: 6447 D: 34287
bench:
8819179
lucasart [Sun, 12 Jun 2016 23:12:24 +0000 (07:12 +0800)]
Do not hardcode Debug Log File
Allow to specifiy the log file name, this comes
handy in case of self-matches so that each SF
instance writes into a different log file.
No functional change.
Marco Costalba [Sat, 4 Jun 2016 05:53:29 +0000 (07:53 +0200)]
Filter root moves filter before copy to threads
Currently root moves are copied to all teh threads
but are DTZ filtered only in main thread at the
beginning of teh search.
This patch moves the TB filtering before the
copy of root moves fixing issue #679
https://github.com/official-stockfish/Stockfish/issues/679
No bench change.
VoyagerOne [Wed, 8 Jun 2016 15:21:43 +0000 (11:21 -0400)]
Stat Formula Tweak
bonus = d * d + 2 * d - 2
STC:
LLR: 2.94 (-2.94,2.94) [0.00,4.00]
Total: 99444 W: 18274 L: 17778 D: 63392
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 89757 W: 12285 L: 11896 D: 65576
bench:
8276130
VoyagerOne [Mon, 6 Jun 2016 13:39:26 +0000 (09:39 -0400)]
Tweak check extension condition
There are two concepts with this patch:
Limit check extensions by using move count.
The idea is to limit search explosion.
Always extend check if the first move gives check.
The idea is to save expensive SEE calls, since the vast
majority of first move will have SEE value >= 0, also
first move may still be strong even if the SEE is negative.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 16503 W: 3068 L: 2873 D: 10562
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 37202 W: 5261 L: 5014 D: 26927
bench:
8543366
Alain SAVARD [Sat, 4 Jun 2016 13:57:17 +0000 (09:57 -0400)]
Small Queen simplification
Moving a few lines from evaluate_threats to evaluate_pieces allows to
a) Remove a condition pos.count<QUEEN>(Them) == 1
b) use precalculated s instead of pos.square(Them)
c) do not check the condition at all in queenless endings
Passed STC
http://tests.stockfishchess.org/tests/view/
5752e0410ebc59029919b1f4
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 67175 W: 12194 L: 12152 D: 42829
and LTC
http://tests.stockfishchess.org/tests/view/
57587b140ebc59029919b2f4
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 20276 W: 2774 L: 2653 D: 14849
bench:
7907962
mstembera [Wed, 8 Jun 2016 00:09:57 +0000 (17:09 -0700)]
Avoid some redundant scaling function calls
Posted by Mohammed Li here:
https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/N-PHfN0O79o
No functional change.
ElbertoOne [Sat, 4 Jun 2016 05:10:43 +0000 (07:10 +0200)]
LMR reduction parameter tweak
More reduction for cut nodes, less for moves that escape a capture:
STC (http://tests.stockfishchess.org/tests/view/
57548c1e0ebc59029919b247):
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 60165 W: 11519 L: 11149 D: 37497
LTC (http://tests.stockfishchess.org/tests/view/
57555b570ebc59029919b260):
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 10353 W: 1493 L: 1317 D: 7543
Bench:
8902859
Marco Costalba [Sun, 29 May 2016 08:10:39 +0000 (10:10 +0200)]
Fix syzygy DTZ bug
In this position: 3K4/8/3k4/8/4p3/4B3/5P2/8 w - - 0 5
Current DTZ probe returns 1 instead of 15
What happens is that the double push f4 is erroneously detected as a win move.
After the push we have:
[D]3K4/8/3k4/8/4pP2/4B3/8/8 b - f3 0 5
And here the code misses the possible ep capture exf3.
The bug is in probe_dtz_no_ep() where is used probe_ab() that is
blind to ep captures so it returns v == 2 (win) for position
3K4/8/3k4/8/4pP2/4B3/8/8 b - f3 0 5
Note that at the caller site the original position did not have any
possible ep capture, so probe_dtz() returns immediately after calling
probe_dtz_no_ep().
The fix is to call the ep-aware probe_wdl() instead of probe_ab()
I have verified that DTZ is correct now and also there are no more
mistmatches compared to the new 'syzygy' branch. Tested on a set of
more than 600 endgame positions, included some tricky ones.
For people interested to redo the test or doing additional tests
please pull branch tb_dbg from https://github.com/mcostalba/Stockfish repo.
bench:
8450534 (bench unaffected because syzygy is not exercized during bench)
VoyagerOne [Fri, 3 Jun 2016 14:21:12 +0000 (10:21 -0400)]
Simplify Futility Pruning
Don't update bestValue when futility pruning.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 21933 W: 4031 L: 3912 D: 13990
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 46225 W: 6115 L: 6028 D: 34082
Bench:
8450534
ElbertoOne [Fri, 3 Jun 2016 08:01:02 +0000 (10:01 +0200)]
LMR Simplification
LMR simplification that also gives a slight ELO gain, especially at LTC:
STC (http://tests.stockfishchess.org/tests/view/
574ec8e20ebc59029919b147):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 32402 W: 5967 L: 5866 D: 20569
LTC (http://tests.stockfishchess.org/tests/view/
574fbebf0ebc59029919b16d):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 15103 W: 2103 L: 1975 D: 11025
Bench:
8248133
joergoster [Mon, 30 May 2016 20:42:47 +0000 (22:42 +0200)]
Tuned values for piece check and attack unit factors
A middle ground patch of two successful tuning patches,
one at STC, the other at LTC, which now passed both.
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 67893 W: 12777 L: 12384 D: 42732
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 30165 W: 4189 L: 3960 D: 22016
bench:
9209507
Stéphane Nicolet [Sat, 21 May 2016 08:05:19 +0000 (10:05 +0200)]
Pins or discovered attacks on the opponent's queen
Bonus for pins or discovered attacks on the opponent's queen
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 32020 W: 5914 L: 5652 D: 20454
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 10946 W: 1530 L: 1375 D: 8041
Bench:
7031649
Stéphane Nicolet [Sat, 21 May 2016 08:05:19 +0000 (10:05 +0200)]
Teach check_blockers to check also non-king pieces
This is a prerequisite for next patch
No functional change.
Stéphane Nicolet [Tue, 24 May 2016 06:09:13 +0000 (08:09 +0200)]
Simplify doubled pawn
Only use doubled pawn malus when the doubled pawns are on consecutive squares.
Passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 7678 W: 1469 L: 1325 D: 4884
And LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 26739 W: 3562 L: 3449 D: 19728
Bench:
8211685
Leonid Pechenik [Mon, 16 May 2016 20:30:57 +0000 (16:30 -0400)]
More detailed dependence of time allocation on the magnitude of score change
10+0.1:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 5657 W: 1130 L: 979 D: 3548
60+0.6:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36884 W: 5002 L: 4762 D: 27120
bench:
8428997
loco-loco [Wed, 18 May 2016 06:46:05 +0000 (23:46 -0700)]
Assorted pruning tweaks
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 38257 W: 5206 L: 4961 D: 28090
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 16550 W: 3110 L: 2914 D: 10526
Bench:
8428997
mstembera [Thu, 28 Apr 2016 19:13:32 +0000 (12:13 -0700)]
Fix a multiPV bug in lazy SMP
Where the helper threads were not doing multiPV at all.
Regression tested sprt @ 5+0.05 th 7
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 73918 W: 11891 L: 11853 D: 50174
bench:
8716243