stockfish
2 years agoIncrease thread stack for OS X (#2035)
Marco Costalba [Tue, 12 Mar 2019 07:35:10 +0000 (08:35 +0100)]
Increase thread stack for OS X (#2035)

On OS X threads other than the main thread are created with a reduced stack
size of 512KB by default, this is dangerously low for deep searches, so
adjust it to TH_STACK_SIZE. The implementation calls pthread_create() with
proper stack size parameter.

Verified for no regression at STC enabling the patch on all platforms where
pthread is supported.

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 50873 W: 9768 L: 9700 D: 31405

No functional change.

2 years agoRemove popcount16() (#2038)
protonspring [Sun, 10 Mar 2019 09:53:39 +0000 (03:53 -0600)]
Remove popcount16() (#2038)

This is a non-functional simplification / code-style change.

This popcount16 method does nothing but initialize the PopCnt16 arrays.

This can be done in a single bitset line, which is less lines and more clear. Performance for this code is moot.

No functional change.

2 years agoSimplify failedLow away #1986
xoto10 [Fri, 1 Feb 2019 20:02:03 +0000 (20:02 +0000)]
Simplify failedLow away #1986

FailedLow doesn't seem to add any value so remove it.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 43915 W: 9682 L: 9604 D: 24629
http://tests.stockfishchess.org/tests/view/5c5339770ebc592fc7baef74

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 58515 W: 9670 L: 9609 D: 39236
http://tests.stockfishchess.org/tests/view/5c53cc840ebc592fc7baf6c1

Ideas for further work:

    Tune the values in the revised fallingEval calculation
    Consider adding a term using delta, e.g. c * (delta - 20) as an indicator of eval instability

Bench: 3318033

2 years agoRevert "Allowing singular extension in mate positions"
Marco Costalba [Sat, 9 Mar 2019 12:24:26 +0000 (13:24 +0100)]
Revert "Allowing singular extension in mate positions"

It was causing an assert: value > -VALUE_INFINITE
under some conditions.

See https://github.com/official-stockfish/Stockfish/issues/2036

Bench: 3318033

2 years agoRemove FutilityMoveCounts array. (#2024)
protonspring [Tue, 5 Mar 2019 19:48:29 +0000 (12:48 -0700)]
Remove FutilityMoveCounts array. (#2024)

This is a functional simplification that removes the FutilityMoveCounts array with a simple equation using only ints.

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 14175 W: 3123 L: 2987 D: 8065

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9900 W: 1735 L: 1597 D: 6568

Bench: 3380343

2 years agoShrink Reductions[] array to one dimension
protonspring [Sun, 3 Mar 2019 14:53:36 +0000 (07:53 -0700)]
Shrink Reductions[] array to one dimension

This is a non-functional patch which shrinks the reductions array.
This saves about 8Kb of memory.

The only slow part of master's reductions array is the calculation
of the log values, so using a separate array for those values and
calculating the rest real-time appears to be just as fast as master.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 63245 W: 13906 L: 13866 D: 35473
http://tests.stockfishchess.org/tests/view/5c7b571f0ebc5925cffdc104

No funcional change.

2 years agoPawn value tweak
SFisGOD [Tue, 5 Mar 2019 04:34:02 +0000 (12:34 +0800)]
Pawn value tweak

STC:
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 47166 W: 10664 L: 10311 D: 26191
http://tests.stockfishchess.org/tests/view/5c7dfc370ebc5925cffdf830

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 35439 W: 6034 L: 5767 D: 23638
http://tests.stockfishchess.org/tests/view/5c7e41020ebc5925cffdfe9b

Bench: 3470519

2 years agoAssorted trivial cleanups 2/2019
Marco Costalba [Fri, 8 Feb 2019 09:36:03 +0000 (10:36 +0100)]
Assorted trivial cleanups 2/2019

No functional change.

2 years agoAdd continuation history 5
Vizvezdenec [Wed, 27 Feb 2019 20:25:12 +0000 (23:25 +0300)]
Add continuation history 5

Original patch passed STC:
http://tests.stockfishchess.org/tests/view/5c7439ff0ebc5925cffd3e64
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 26348 W: 5926 L: 5632 D: 14790

and LTC:
http://tests.stockfishchess.org/tests/view/5c745a8b0ebc5925cffd41a8
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 198411 W: 33238 L: 32510 D: 132663

But had undefined behavior.
After fixing (thx to @vondele )

passed LTC:
http://tests.stockfishchess.org/tests/view/5c763c7c0ebc5925cffd5de2
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 112253 W: 18711 L: 18225 D: 75317

bench 3049229

2 years agoRemove skipQuiets with mate fix. (#2021)
Joost VandeVondele [Wed, 27 Feb 2019 12:36:48 +0000 (13:36 +0100)]
Remove skipQuiets with mate fix. (#2021)

This removes the skipQuiets variable, as was done in an earlier round by
@protonspring, but fixes an oversight which led to wrong mate
announcements. Quiets can only be pruned when there is no mate score, so
set moveCountPruning at the right spot.

tested as a fix at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 66321 W: 14690 L: 14657 D: 36974
http://tests.stockfishchess.org/tests/view/5c74f3170ebc5925cffd4b3c

and as the full patch at LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 25903 W: 4341 L: 4228 D: 17334
http://tests.stockfishchess.org/tests/view/5c7540030ebc5925cffd506f

Bench: 3292342

2 years agoRevert "Remove skipQuiets variable in search()"
Marco Costalba [Tue, 26 Feb 2019 12:20:48 +0000 (13:20 +0100)]
Revert "Remove skipQuiets variable in search()"

This reverts commit 76d2f5b94a0df20d84ccf922bd1c0fcf1c779090.

Due to a bug, see https://github.com/official-stockfish/Stockfish/issues/2019

Bench: 3516616

2 years agoAdd KNNvKP Endgame Heuristic
Kurtbusch [Fri, 4 Jan 2019 23:27:14 +0000 (18:27 -0500)]
Add KNNvKP Endgame Heuristic

This is a somewhat different patch. It fixes blindspots for
 two knights vs pawn endgame.

With local testing starting from random KNNvKP positions where the
pawn has not advanced beyond the 4th rank (thanks @protonspring !)
at 15+0.15 (4 cores), this went +105=868-27 against master. All except
two losses were won in reverse.

The heuristic is simple but effective - the strategy in these endgames
is to push the opposing king to the corner, then move the knight that's
blocking the pawn in for the checkmate while the pawn is free to move
and prevents stalemate. This patch gives SF the little boost it needs
to search the relevant king-cornering mating lines.

See the discussion in pull request 1939 for some more good results for
this test in independant tests:
https://github.com/official-stockfish/Stockfish/pull/1939

Bench: 3310239

2 years agoProbCutCount limit dependancy to cutNode
MJZ1977 [Tue, 19 Feb 2019 16:48:03 +0000 (17:48 +0100)]
ProbCutCount limit dependancy to cutNode

Use the ProbCutCount limit `2 + 2 * cutNode` instead of constant 3.

STC
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 61812 W: 13599 L: 13459 D: 34754
http://tests.stockfishchess.org/tests/view/5c6d19240ebc5925cffca07a

LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 27549 W: 4614 L: 4363 D: 18572
http://tests.stockfishchess.org/tests/view/5c6d45c10ebc5925cffca7a6

Closes https://github.com/official-stockfish/Stockfish/pull/2015

Bench: 3368889

2 years agoRemove PvNode dimension from Reductions array
protonspring [Wed, 13 Feb 2019 21:58:43 +0000 (14:58 -0700)]
Remove PvNode dimension from Reductions array

This is a functional simplification: if we simply subtract one to Reductions[]
when PvNode is set, we can remove this dimension of the multidimensional array.
I think this saves about 8K of memory.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 10118 W: 2282 L: 2138 D: 5698
http://tests.stockfishchess.org/tests/view/5c6332b60ebc5925cffbdfed

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 70765 W: 11617 L: 11575 D: 47573
http://tests.stockfishchess.org/tests/view/5c63379e0ebc5925cffbe0de

Closes https://github.com/official-stockfish/Stockfish/pull/2010

Bench 3261078

2 years agoRemove skipQuiets variable in search()
protonspring [Thu, 14 Feb 2019 21:23:24 +0000 (14:23 -0700)]
Remove skipQuiets variable in search()

This is a functional simplification. The moveCountPruning variable and the
skipQuiets variable are similar enough in function that they can be combined.
This removes the skipQuiets variable in search.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 23278 W: 5210 L: 5091 D: 12977
http://tests.stockfishchess.org/tests/view/5c65dc490ebc5925cffc12e9

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 77107 W: 12792 L: 12761 D: 51554
http://tests.stockfishchess.org/tests/view/5c65e4360ebc5925cffc1490

Closes https://github.com/official-stockfish/Stockfish/pull/2011

bench 3640330

2 years agoChange outposts to single value #1946
protonspring [Sun, 13 Jan 2019 02:30:56 +0000 (19:30 -0700)]
Change outposts to single value #1946

This is a functional simplification of the Outposts array
moving it to a single value. This is a duplicate PR because
I couldn't figure out how to fix the original one.

The idea is from @31m059 with formatting recommendations by @snicolet.

See #1940 for additional information.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 23933 W: 5279 L: 5162 D: 13492
http://tests.stockfishchess.org/tests/view/5c3575800ebc596a450c5ecb

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 41718 W: 6919 L: 6831 D: 27968
http://tests.stockfishchess.org/tests/view/5c358c440ebc596a450c6117

bench 3783543

2 years agoAssorted trivial cleanups 1/2019
Marco Costalba [Tue, 1 Jan 2019 13:13:08 +0000 (14:13 +0100)]
Assorted trivial cleanups 1/2019

To address #1862

No functional change.

2 years agoLog message of: Less king danger...
Marco Costalba [Fri, 8 Feb 2019 09:17:18 +0000 (10:17 +0100)]
Log message of: Less king danger...

The commit:

Less king danger if we have a knight near by to defend it

went in withouth proper commit message, here below we add it:

STC: LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 113106 W: 25087 L: 24367 D: 63652
http://tests.stockfishchess.org/tests/view/5c5517540ebc592fc7bb0eb4

LTC: LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 96669 W: 16318 L: 15872 D: 64479
http://tests.stockfishchess.org/tests/view/5c55352b0ebc592fc7bb11c8

bench: 3653942

2 years agoRemove Some Bitboard Arrays (#1963)
protonspring [Fri, 8 Feb 2019 08:54:38 +0000 (01:54 -0700)]
Remove Some Bitboard Arrays (#1963)

This is non-functional. These 5 arrays are simple enough to calculate real-time and maintaining an array for them does not help. Decreases the memory footprint.

This seems a tiny bit slower on my machine, but passed STC well enough. Could someone verify speed?

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 44745 W: 9780 L: 9704 D: 25261
http://tests.stockfishchess.org/tests/view/5c47aa2d0ebc5902bca13fc4

The slowdown is minimal even in 32 bit case (thanks to @mstembera for testing):

Compiled using make build ARCH=x86-32 CXX=i686-w64-mingw32-c++ and benched
This patch only:

```
Results for 40 tests for each version:

            Base      Test      Diff
    Mean    1455204   1450033   5171
    StDev   49452     34533     59621

p-value: 0.465
speedup: -0.004
```

No functional change.

2 years agoLess king danger if we have a knight near by to defend it. (#1987)
mstembera [Sun, 3 Feb 2019 13:16:34 +0000 (05:16 -0800)]
Less king danger if we have a knight near by to defend it. (#1987)

bench: 3653942

2 years agoExtend discovered checks regardless of SEE
Miguel Lahoz [Tue, 29 Jan 2019 14:26:03 +0000 (22:26 +0800)]
Extend discovered checks regardless of SEE

A simple idea, but it makes sense: in current master the search is extended
for checks that are considered somewhat safe, and for for this we use the
static exchange evaluation which only considers the `to_sq` of a move.
This is not reliable for discovered checks, where another piece is giving
the check and is arguably a more dangerous type of check. Thus, if the check
is a discovered check, the result of SEE is not relevant and can be ignored.

STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 29370 W: 6583 L: 6274 D: 16513
http://tests.stockfishchess.org/tests/view/5c5062950ebc593af5d4d9b5

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 227341 W: 37972 L: 37165 D: 152204
http://tests.stockfishchess.org/tests/view/5c5094fb0ebc593af5d4dc2c

Bench: 3611854

2 years agoTweak tropism weight in king danger
Stéphane Nicolet [Fri, 1 Feb 2019 12:09:17 +0000 (13:09 +0100)]
Tweak tropism weight in king danger

There was a simplification attempt last week for the tropism
term in king danger, which passed STC but failed LTC. This
was an indirect sign that maybe the tropism factor was sightly
untuned in current master, so we tried to change it from 1/4
to 5/16.

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 28098 W: 6264 L: 5990 D: 15844
http://tests.stockfishchess.org/tests/view/5c518db60ebc593af5d4e306

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 103709 W: 17387 L: 16923 D: 69399
http://tests.stockfishchess.org/tests/view/5c52a5510ebc592fc7baea8b

Bench: 4016000

2 years agoMore precise checks evaluation in king danger
Vizvezdenec [Fri, 1 Feb 2019 06:21:23 +0000 (09:21 +0300)]
More precise checks evaluation in king danger

Remove overlapping safe checks from kingdanger:
- rook and queen checks from the same square: rook check is preferred
- bishop and queen checks form the same square: queen check is preferred

Increase bishop and rook check values as a compensation.

STC
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 27480 W: 6111 L: 5813 D: 15556
http://tests.stockfishchess.org/tests/view/5c521d050ebc593af5d4e66a

LTC
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 78500 W: 13145 L: 12752 D: 52603
http://tests.stockfishchess.org/tests/view/5c52b9460ebc592fc7baecc5

Closes https://github.com/official-stockfish/Stockfish/pull/1983

------------------------------------------

I have quite a few ideas of how to improve this patch.

- actually rethinking it now it will maybe be useful to discount
  queen/bishop checks if there is only one square that they can
  give check from and it's "occupied" by more valuable check. Right
  now count of this squares does not really matter.

- maybe some small extra bonus can be given for overlapping checks.

- some ideas about using popcount() on safechecks can be retried.

- tune this safecheck values since they were more or less randomly handcrafted in this patch.

Bench: 3216489

2 years agoSimplify Stat Score bonus
protonspring [Thu, 31 Jan 2019 14:18:33 +0000 (15:18 +0100)]
Simplify Stat Score bonus

This is a functional simplification of this statScore bonus.
There seems to be little risk of regression with this one.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 26829 W: 5892 L: 5781 D: 15156
http://tests.stockfishchess.org/tests/view/5c5086bb0ebc593af5d4db75

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 28232 W: 4684 L: 4575 D: 18973
http://tests.stockfishchess.org/tests/view/5c50d7690ebc593af5d4dec9

Closes https://github.com/official-stockfish/Stockfish/pull/1979

Bench: 4001014

2 years agoDon't update pvHit after IID
DU-jdto [Wed, 23 Jan 2019 04:19:10 +0000 (15:19 +1100)]
Don't update pvHit after IID

This patch removes line 875 of search.cpp, which was updating pvHit after IID.
Bench testing at depth 22 shows that line 875 of search.cpp never changes the
value of pvHit at NonPV nodes, while at PV nodes it often changes the value
from true to false (and never the reverse). This is because the definition of
pvHit at line 642 is :

```
pvHit = (ttHit && tte->pv_hit()) || (PvNode && depth > 4 * ONE_PLY);
```

while the assignment after IID omits the ` (PvNode && depth > 4 * ONE_PLY) `
condition. As such, unlike the other two post-IID tte reads, this line of code
does not make SF's state more consistent, but rather introduces an inconsistency
in the definition of pvHit. Indeed, changing line 875 read

```
pvHit = (ttHit && tte->pv_hit()) || (PvNode && depth > 4 * ONE_PLY);
```

to match line 642 is functionally equivalent to removing the line entirely, as
this patch does.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 62756 W: 13787 L: 13746 D: 35223
http://tests.stockfishchess.org/tests/view/5c446c850ebc5902bb5d4b75

LTC
LLR: 3.19 (-2.94,2.94) [-3.00,1.00]
Total: 61900 W: 10179 L: 10111 D: 41610
http://tests.stockfishchess.org/tests/view/5c45bf610ebc5902bb5d5d62

Bench: 3796134

2 years agoChange pinning logic in Static Exchange Evaluation (SEE)
Miguel Lahoz [Fri, 25 Jan 2019 06:37:03 +0000 (14:37 +0800)]
Change pinning logic in Static Exchange Evaluation (SEE)

This changes 2 parts with regards to static exchange evaluation.

Currently, we do not allow pinned pieces to recapture if *all* opponent
pinners are still in their starting squares. This changes that to having
a less strict requirement, checking if *any* pinners are still in their
starting square. This makes our SEE give more respect to the pinning
side with regards to exchanges, which makes sense because it helps our
search explore more tactical options.

Furthermore, we change the logic for saving pinners into our state
variable when computing slider_blockers. We will include double pinners,
where two sliders may be looking at the same blocker, a similar concept
to our mobility calculation for sliders in our evaluation section.
Interestingly, I think SEE is the only place where the pinners bitboard
is actually used, so as far as I know there are no other side effects
to this change.

An example and some insights:

White Bf2, Kg1
Black Qe3, Bc5

The move Qg3 will be given the correct value of 0. (Previously < 0)
The move Qd4 will be incorrectly given a value of 0. (Previously < 0)

It seems the tradeoff in search is worth it. Qd4 will likely be pruned
soon by something like probcut anyway, while Qg3 could help us spot
tactics at an earlier depth.

STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 62162 W: 13879 L: 13408 D: 34875
http://tests.stockfishchess.org/tests/view/5c4ba1a70ebc593af5d49c55

LTC: (Thanks to @alayant)
LLR: 3.40 (-2.94,2.94) [0.00,3.50]
Total: 140285 W: 23416 L: 22825 D: 94044
http://tests.stockfishchess.org/tests/view/5c4bcfba0ebc593af5d49ea8

Bench: 3937213

2 years agoUse int8_t instead of int for SquareDistance[]
Maciej Żenczykowski [Sat, 26 Jan 2019 17:16:17 +0000 (09:16 -0800)]
Use int8_t instead of int for SquareDistance[]

This patch saves (4-1) * 64 * 64 = 12KiB of cache.

STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 176120 W: 38944 L: 38087 D: 99089
http://tests.stockfishchess.org/tests/view/5c4c9f840ebc593af5d4a7ce

LTC
As a pure speed up, I've been informed it should not require LTC.

No functional change

2 years agoSimplify TrappedRook
protonspring [Mon, 21 Jan 2019 18:55:51 +0000 (11:55 -0700)]
Simplify TrappedRook

Simplified TrappedRook to a single penalty removing the dependency on mobility.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 106718 W: 23530 L: 23577 D: 59611
http://tests.stockfishchess.org/tests/view/5c43f6bd0ebc5902bb5d4131

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 54053 W: 8890 L: 8822 D: 36341
http://tests.stockfishchess.org/tests/view/5c44932a0ebc5902bb5d4d59

bench 3665090

2 years agoSimplify pondering time management (#1899)
Joost VandeVondele [Sun, 20 Jan 2019 18:14:24 +0000 (19:14 +0100)]
Simplify pondering time management (#1899)

stopOnPonderhit is used to stop search quickly on a ponderhit. It is set by mainThread as part of its time management. However, master employs it as a signal between mainThread and the UCI thread. This is not necessary, it is sufficient for the UCI thread to signal that pondering finished, and mainThread should do its usual time-keeping job, and in this case stop immediately.

This patch implements this, removing stopOnPonderHit as an atomic variable from the ThreadPool,
and moving it as a normal variable to mainThread, reducing its scope. In MainThread::check_time() the search is stopped immediately if ponder switches to false, and the variable stopOnPonderHit is set.

Furthermore, ponder has been moved to mainThread, as the variable is only used to exchange signals between the UCI thread and mainThread.

The version has been tested locally (as fishtest doesn't support ponder):

Score of ponderSimp vs master: 2616 - 2528 - 8630 [0.503] 13774
Elo difference: 2.22 +/- 3.54

which indicates no regression.

No functional change.

2 years agoSimplify pvHit (#1953)
marotear [Sun, 20 Jan 2019 11:24:03 +0000 (03:24 -0800)]
Simplify pvHit (#1953)

Removing unnecessary excludedMove condition (there is not excluded move for PvNodes) and re-ordering computation.

Non functional change.

2 years agoClean-up some shifting in space calculation (#1955)
protonspring [Sun, 20 Jan 2019 11:21:16 +0000 (04:21 -0700)]
Clean-up some shifting in space calculation (#1955)

No functional change.

2 years agoTweak initiative and Pawn PSQT (#1957)
Jonathan D [Sun, 20 Jan 2019 11:20:21 +0000 (19:20 +0800)]
Tweak initiative and Pawn PSQT (#1957)

Small changes in initiative(). For Pawn PSQT, endgame values for d6-e6 and d7-e7 are now symmetric. The MG value of d2 is now smaller than e2 (d2=13, e2=21 now compared to d2=19, e2=16 before). The MG values of h5-h6-h7 also increased so this might encourage stockfish for more h-pawn pushes.

STC
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 81141 W: 17933 L: 17777 D: 45431
http://tests.stockfishchess.org/tests/view/5c4017350ebc5902bb5cf237

LTC
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 83078 W: 13883 L: 13466 D: 55729
http://tests.stockfishchess.org/tests/view/5c40763f0ebc5902bb5cff09

Bench: 3266398

2 years agoRemove AdjacentFiles
protonspring [Tue, 15 Jan 2019 05:53:43 +0000 (22:53 -0700)]
Remove AdjacentFiles

This is a non-functional simplification that removes the AdjacentFiles array.
This array is simple enough to calculate that the pre-calculated array provides
no benefit. Reduces the memory footprint.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 74839 W: 16390 L: 16373 D: 42076
http://tests.stockfishchess.org/tests/view/5c3d75920ebc596a450cfb67

No functionnal change

2 years agoSimplify pawn moves (#1900)
protonspring [Mon, 14 Jan 2019 14:03:31 +0000 (07:03 -0700)]
Simplify pawn moves (#1900)

If we define dcCandidates with & pawnsNotOn7,
we don't have to & it both times.

This seems more clear to me as well.

Tested for no regression.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 44042 W: 9663 L: 9585 D: 24794
http://tests.stockfishchess.org/tests/view/5c21d9120ebc5902ba12e84d

No functional change.

2 years agoSimplify time management a bit
Joost VandeVondele [Wed, 2 Jan 2019 10:09:50 +0000 (11:09 +0100)]
Simplify time management a bit

The new form is likely to trigger a bit more at LTC. Given that LTC
appears to be an improvement, I think that is fine.

The change is not very invasive: it does the same as before, use
potentially less time for moves that are very stable. Most of the
time, the full bonus was given if the bonus was given, so the gradual
part {3, 4, 5} didn't matter much. Whereas previously 'stable' was
expressed as the last 80% of iterations are the same, now I use a
fixed depth (10 iterations). For TCEC style TC, it will presumably
imply some more moves that are played quicker (and thus more time
on the clock when it potentially matters). Note that 10 iterations
of stability means we've been proposing that move for 99.9% of search
time.

passed STC
http://tests.stockfishchess.org/tests/view/5c30d2290ebc596a450c055b
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 70921 W: 15403 L: 15378 D: 40140

passed LTC
http://tests.stockfishchess.org/tests/view/5c31ae240ebc596a450c1881
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17422 W: 2968 L: 2842 D: 11612

No functional change.

2 years agoRemove pvExact
Joost VandeVondele [Thu, 10 Jan 2019 06:43:17 +0000 (07:43 +0100)]
Remove pvExact

The variable pvExact now overlaps with the pvHit concept. So you simplify
the logic with small code tweaks to have pvHit trigger where pvExact
previously triggered.

passed STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20558 W: 4497 L: 4373 D: 11688
http://tests.stockfishchess.org/tests/view/5c36e9fd0ebc596a450c7885

passed LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 23482 W: 3888 L: 3772 D: 15822
http://tests.stockfishchess.org/tests/view/5c37072d0ebc596a450c7a52

Bench: 3739723

2 years agoMinor cleanup to recent 'Flag critical search tree in hash table' patch
mstembera [Wed, 9 Jan 2019 15:27:47 +0000 (07:27 -0800)]
Minor cleanup to recent 'Flag critical search tree in hash table' patch

No functional change

2 years agoSmall improvements to the CI infrastructure
Joost VandeVondele [Wed, 9 Jan 2019 15:14:34 +0000 (16:14 +0100)]
Small improvements to the CI infrastructure

- avoid inlining for the debug testing so that suppressions work
- provide more output for triggered errors

No functional change.

2 years agoFlag critical search tree in hash table
MJZ1977 [Wed, 9 Jan 2019 14:05:28 +0000 (15:05 +0100)]
Flag critical search tree in hash table

Introducing new concept, saving principal lines into the transposition table
to generate a "critical search tree" which we can reuse later for intelligent
pruning/extension decisions.

For instance in this patch we just reduce reduction for these lines. But a lot
of other ideas are possible.

To go further : tune some parameters, how to add or remove lines from the
critical search tree, how to use these lines in search choices, etc.

STC :
LLR: 2.94 (-2.94,2.94) [0.50,4.50]
Total: 59761 W: 13321 L: 12863 D: 33577 +2.23 ELO
http://tests.stockfishchess.org/tests/view/5c34da5d0ebc596a450c53d3

LTC :
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 26826 W: 4439 L: 4191 D: 18196 +2.9 ELO
http://tests.stockfishchess.org/tests/view/5c35ceb00ebc596a450c65b2

Special thanks to Miguel Lahoz for his help in transposition table in/out.

Bench: 3399866

2 years agoIntroduce Multi-Cut
Miguel Lahoz [Sat, 5 Jan 2019 20:53:21 +0000 (04:53 +0800)]
Introduce Multi-Cut

This was inspired after reading about
[Multi-Cut](https://www.chessprogramming.org/Multi-Cut).

We now do non-singular cut node pruning. The idea is to prune when we
have a "backup plan" in case our expected fail high node does not fail
high on the ttMove.

For singular extensions, we do a search on all other moves but the
ttMove. If this fails high on our original beta, this means that both
the ttMove, as well as at least one other move was proven to fail high
on a lower depth search. We then assume that one of these moves will
work on a higher depth and prune.

STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 72952 W: 16104 L: 15583 D: 41265
http://tests.stockfishchess.org/tests/view/5c3119640ebc596a450c0be5

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 27103 W: 4564 L: 4314 D: 18225
http://tests.stockfishchess.org/tests/view/5c3184c00ebc596a450c1662

Bench: 3145487

2 years agoCheck tablebase files
Joost VandeVondele [Thu, 3 Jan 2019 22:56:11 +0000 (23:56 +0100)]
Check tablebase files

This addresses partially issue #1911 in that it documents in our
Readme the command that users can use to verifying the md5sum of
their downloaded tablebase files.

Additionally, a quick check of the file size (the size of each
tablebase file modulo 64 is 16 as pointed out by @syzygy1) has been
implemented at launch time in Stockfish.

Closes https://github.com/official-stockfish/Stockfish/pull/1927
and https://github.com/official-stockfish/Stockfish/issues/1911

No functional change.

2 years agoDelay castling legality check
Marco Costalba [Wed, 2 Jan 2019 07:31:03 +0000 (08:31 +0100)]
Delay castling legality check

Delay legality check of castling moves at search time,
just before making the move, as is the standard with all
the other move types.

This should avoid an useless and not trivial legality check
when the castling is then not tried later. For instance due
to a previous cut-off.

The patch is also a big simplification and allows to entirely
remove generate_castling()

Bench changes due to a different move sequence out of MovePicker.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 45073 W: 9918 L: 9843 D: 25312
http://tests.stockfishchess.org/tests/view/5c2f176f0ebc596a450bdfb3

LTC:
LLR: 3.15 (-2.94,2.94) [-3.00,1.00]
Total: 10156 W: 1707 L: 1560 D: 6889
http://tests.stockfishchess.org/tests/view/5c2e7dfd0ebc596a450bcdf4

Verified with perft both in standard and Chess960 cases.

Closes https://github.com/official-stockfish/Stockfish/pull/1929

Bench: 3559104

2 years agoAssorted trivial cleanups (#1894)
Marco Costalba [Tue, 1 Jan 2019 13:10:26 +0000 (14:10 +0100)]
Assorted trivial cleanups (#1894)

To address https://github.com/official-stockfish/Stockfish/issues/1862

No functional change.

2 years agoRemove openFiles in pawns. (#1917)
protonspring [Tue, 1 Jan 2019 12:38:09 +0000 (05:38 -0700)]
Remove openFiles in pawns. (#1917)

A single popcount in evaluate.cpp replaces all openFiles stuff in pawns. It doesn't seem to affect performance at all.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 28103 W: 6134 L: 6025 D: 15944
http://tests.stockfishchess.org/tests/view/5b7d70a20ebc5902bdbb1999

No functional change.

2 years agoRemove "Any" predicate filter (#1914)
protonspring [Tue, 1 Jan 2019 12:36:56 +0000 (05:36 -0700)]
Remove "Any" predicate filter (#1914)

This custom predicate filter creates an unnecessary abstraction layer, but doesn't make the code any more readable. The code is clear enough without it.

No functional change.

2 years agoRemove as useless micro-optimization in pawns generation (#1915)
protonspring [Tue, 1 Jan 2019 12:35:53 +0000 (05:35 -0700)]
Remove as useless micro-optimization in pawns generation (#1915)

The extra condition is used as a shortcut to skip the following 3 assignments:

```C++
        Bitboard b1 = shift<UpRight>(pawnsOn7) & enemies;
        Bitboard b2 = shift<UpLeft >(pawnsOn7) & enemies;
        Bitboard b3 = shift<Up     >(pawnsOn7) & emptySquares;
```

In case of EVASION with no target on 8th rank (the common case), we end up performing the 3 statements for nothing because b1 = b2 = b3 = 0.

But this is just a small micro-optimization and the condition is quite confusing, so just remove it and prefer a readable code instead.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78020 W: 16978 L: 16967 D: 44075
http://tests.stockfishchess.org/tests/view/5c27b4fe0ebc5902ba135bb0

No functional change.

2 years agoImprove the Readme
erbsenzaehler [Sat, 29 Dec 2018 10:49:10 +0000 (11:49 +0100)]
Improve the Readme

I tried to improve the Readme because many people in my local
chess club do not understand some of the UCO options properly.
Starting point of this was Cfish's Readme by Ronald de Man,
some internet resources and the Stockfish code itself.

Closes https://github.com/official-stockfish/Stockfish/pull/1898

Initial commit by user @erbsenzaehler, with help from users
Adrian Petrescu, @alayan-stk-2 and Elvin Liu.

No functional change

Co-Authored-By: Alayan-stk-2 <alayan-stk-2@users.noreply.github.com>
Co-Authored-By: Adrian Petrescu <apetresc@gmail.com>
Co-Authored-By: Elvin Liu <solarlight2@users.noreply.github.com>
2 years agoAlways initialize and evaluate king safety
31m059 [Thu, 27 Dec 2018 06:51:43 +0000 (01:51 -0500)]
Always initialize and evaluate king safety

Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could
be gained by expanding the number of cases where king safety is applied. Several
users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in
evaluation of tactics. It appears that we actually do not need to restrict the
cases in which we initialize and evaluate king safety at all: initializing and
evaluating it in every position appears roughly Elo-neutral at STC and possibly
a substantial Elo gain at LTC.

Any explanation for this scaling is, at this point, conjecture. Assuming it is
not due to chance, my hypothesis is that initialization of king safety in all
positions is a mild slowdown, offset by an Elo gain of evaluating king safety
in all positions. At STC this produces Elo gains and losses that offset each
other, while at longer time control the slowdown is much less important, leaving
only the Elo gain. It probably helps SF to explore king attacks much earlier in
search with high numbers of enemy pieces concentrating but not essentially attacking
king ring.

Thanks to @xoto10 and @Vizvezdenec for helping run my LTC!

Closes https://github.com/official-stockfish/Stockfish/pull/1906

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35432 W: 7815 L: 7721 D: 19896
http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 12887 W: 2217 L: 2084 D: 8586
http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586

Bench: 3163951

------------------

How to continue from there?

* Next step will be to tune all the king danger terms once more after that :-)

2 years agoSimplify SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX loop (#1892)
noobpwnftw [Mon, 24 Dec 2018 10:24:29 +0000 (18:24 +0800)]
Simplify SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX loop (#1892)

When iterating through 'SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX' structure, do not use structure member beyond known size.

API is guaranteed to provide us at lease one element upon successful, and no element in the structure can have a zero size.

No functional change.

2 years agoFix crash in best_group() (#1891)
noobpwnftw [Sat, 22 Dec 2018 17:05:13 +0000 (01:05 +0800)]
Fix crash in best_group() (#1891)

This pull request fixes a rare crashing bug on Windows inside our NUMA code, first
reported by Dann Corbit in the following forum thread (thanks!):
https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/gA6aoMEuOwg

The fix is to not use structure member beyond known size when iterating through
'SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX' structure. We note that the Microsoft
API is guaranteed to provide us at least one element upon successful, and no
element in the structure can have a zero size.

No functional change.

2 years agoExtend stack to ss-5, and remove conditions
Joost VandeVondele [Wed, 19 Dec 2018 20:04:36 +0000 (21:04 +0100)]
Extend stack to ss-5, and remove conditions

The `&& (ss-1)->killers[0] ` conditions are there seemingly to protect
accessing ss-5.

This is unneeded and not so intuitive (as the killer is checked for equality
with currentMove, and that one is non-zero once we're high enough in the stack,
this protects access to ss-5). We can just extend the stack from ss-4 to ss-5,
so we can call update_continuation_histories(ss-1, ..) always in search.

This goes a bit further than #1881 and addresses a comment in #1878.

passed STC:
http://tests.stockfishchess.org/tests/view/5c1aa8d50ebc5902ba127ad0
LLR: 3.12 (-2.94,2.94) [-3.00,1.00]
Total: 53515 W: 11734 L: 11666 D: 30115

passed LTC:
http://tests.stockfishchess.org/tests/view/5c1b272c0ebc5902ba12858d
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 140176 W: 23123 L: 23192 D: 93861

Bench: 3451321

2 years agoImprove endgame KBN vs K (#1877)
protonspring [Mon, 17 Dec 2018 17:25:25 +0000 (10:25 -0700)]
Improve endgame KBN vs K (#1877)

Even when playing without endgame table bases, this particular endgame should
be a win 100% of the time when Stockfish is given a KRBK position, assuming
there are enough moves remaining in the FEN to finish the game without hitting
the 50 move rule.

PROBLEM: The issue with master here is that the PushClose difference per square
is 20, however, the difference in squares for the PushToCorners array is usually
less. Thus, the engine prefers to move the kings closer together rather than pushing
the weak king to the correct corner.

What happens is if the weak king is in a safe corner, SF still prefers pushing the
kings together. Occasionally, the strong king traps the weak king in the safe corner.
It takes a while for SF to figure it out, but often draws the game by the 50 move rule
(on shorter time controls).

This patch increases the PushToCorners values to correct this problem. We also added
an assert to catch any overflow problem if anybody would want to increase the array
values again in the future.

It was tested in a couple of matches starting with random KRBK positions and showed
increased winning rates, see https://github.com/official-stockfish/Stockfish/pull/1877

No functional change

2 years agoUpdate our continuous integration machinery (#1889)
erbsenzaehler [Sun, 23 Dec 2018 17:17:44 +0000 (18:17 +0100)]
Update our continuous integration machinery (#1889)

* Update our continuous integration machinery

Ubuntu 16.04 can now be used with travis. Updating all the other stuff
when there.
Invoking the lld linker seems to save 5 minutes with clang on linux.

No functional change.

* fix

2 years agoUse a bit less code to calculate hashfull() (#1830)
mstembera [Sun, 23 Dec 2018 15:10:07 +0000 (07:10 -0800)]
Use a bit less code to calculate hashfull() (#1830)

* Use a bit less code to calculate hashfull(). Change post increment to preincrement as is more standard
in the rest of stockfish.  Scale result so we report 100% instead of 99.9% when completely full.

No functional change.

2 years agoTurn on random access for Syzygy files in Windows (#1840)
mstembera [Sun, 23 Dec 2018 15:09:03 +0000 (07:09 -0800)]
Turn on random access for Syzygy files in Windows (#1840)

* This is the Windows version of
https://github.com/official-stockfish/Stockfish/pull/1829

No functional change.

2 years agoSimplify generate_castling (#1885)
protonspring [Sun, 23 Dec 2018 15:05:24 +0000 (08:05 -0700)]
Simplify generate_castling (#1885)

Although this is a compile-time constant, we stick the castlingSide into a CastlingRight, then pull it out again. This seems unecessarily complex.

No functional change.

2 years agoSimplify KBNK endgame implementation
protonspring [Sat, 8 Dec 2018 17:08:59 +0000 (10:08 -0700)]
Simplify KBNK endgame implementation

We do not need to change the winnerKSq variable, so we can simplify
a little bit the logic of the code by changing only the loserKSq
variable when it is necessary. Also consolidate and clarify comments.

See the pull request thread for a proof that the code is correct:
https://github.com/official-stockfish/Stockfish/pull/1854

No functional change

2 years agoTweak main killer penalty
Guenther Demetz [Tue, 18 Dec 2018 07:05:09 +0000 (08:05 +0100)]
Tweak main killer penalty

Apply refuted main killer penalty also on early TT cut-offs. This
makes penalty logic more consistent with the logic at normal search.

Failed STC:
http://tests.stockfishchess.org/tests/view/5c121e730ebc5902ba11aad8
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 72193 W: 15848 L: 15625 D: 40720 Elo +1.07

Passed LTC:
http://tests.stockfishchess.org/tests/view/5c17b1b10ebc5902ba123c24
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 35073 W: 5886 L: 5625 D: 23562 Elo +2.59

Closes https://github.com/official-stockfish/Stockfish/pull/1878

bench: 3393939

2 years agoNew voting formula for threads
mstembera [Tue, 18 Dec 2018 07:50:57 +0000 (08:50 +0100)]
New voting formula for threads

We now use a quadratic formula during the vote for threads
when deciding on which thread to pick a move from.

time control 5+0.05, with 8 threads:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 20202 W: 4031 L: 3813 D: 12358
http://tests.stockfishchess.org/tests/view/5c16c8e60ebc5902ba1223e2

time control 20+0.2, with 8 threads:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 14330 W: 2290 L: 2115 D: 9925
http://tests.stockfishchess.org/tests/view/5c16efca0ebc5902ba122993

20000 games match at time control 5+0.05, with 31 threads:
ELO: 5.63 +-2.8 (95%) LOS: 100.0%
Total: 20000 W: 3539 L: 3215 D: 13246
http://tests.stockfishchess.org/tests/view/5c16f07a0ebc5902ba122a20

Closes https://github.com/official-stockfish/Stockfish/pull/1876

No functional change (in simple thread mode)

2 years agoUse stronglyProtected
31m059 [Sat, 15 Dec 2018 06:55:25 +0000 (01:55 -0500)]
Use stronglyProtected

~stronglyProtected is quite similar to ~attackedBy[Them][PAWN] & ~attackedBy2[Them],
the only difference appears to be that the former includes squares attacked twice
by both sides. The resulting logic is simpler, and the change appears to be at least
Elo-neutral at both STC and LTC.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35924 W: 7978 L: 7885 D: 20061
http://tests.stockfishchess.org/tests/view/5c14a5c00ebc5902ba11ed72

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 37078 W: 6125 L: 6030 D: 24923
http://tests.stockfishchess.org/tests/view/5c14ae880ebc5902ba11eed8

Bench: 3646542

2 years agoRefactor king ring calculation
Alain SAVARD [Sat, 15 Dec 2018 17:09:35 +0000 (12:09 -0500)]
Refactor king ring calculation

Compute the "double protection by pawns" expression only once
in initialize(), instead of once for each piece in the piece loop.

Passed STC
http://tests.stockfishchess.org/tests/view/5c1506380ebc5902ba11f3b4
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9494 W: 2191 L: 2045 D: 5258

Inspired by Nick Pelling's test
   http://tests.stockfishchess.org/tests/view/5c144d110ebc5902ba11e4af
and an older test of mine
   http://tests.stockfishchess.org/tests/view/5c0402810ebc5902bcee1fc8

Non functional change.

2 years agoFix a segfault.
Joost VandeVondele [Sun, 16 Dec 2018 08:51:29 +0000 (09:51 +0100)]
Fix a segfault.

this patch fixes a rare but reproducible segfault observed playing a
multi-threaded match, it is discussed somewhat in fishcooking.

From the core file, it could be observed that the issue was in qsearch, namely:

````
   ss->pv[0] = MOVE_NONE;
````

and the backtrace shows the it arrives there via razoring, called from the rootNode:

````
    (gdb) bt
    alpha=-19, beta=682, depth=DEPTH_ZERO) at search.cpp:1247
````

Indeed, ss->pv can indeed by a nullptr at the rootNode. However, why is the
segfault so rare ?

The reason is that the condition that guards razoring:

````
   (depth < 2 * ONE_PLY &&  eval <= alpha - RazorMargin)
````

is almost never true, since at the root alpha for depth < 5 is -VALUE_INFINITE.

Nevertheless with the new failHigh scheme, this is not guaranteed, and rootDepth > 5,
can still result in a depth < 2 search at the rootNode. If now another thread,
via the hash, writes a new low eval to the rootPos qsearch can be entered.
Rare but not unseen... I assume that some of the crashes in fishtest recently
might be due to this.

Closes https://github.com/official-stockfish/Stockfish/pull/1860

No functional change

2 years agoStart a TT resize only after search finished.
Joost VandeVondele [Sat, 8 Dec 2018 22:03:42 +0000 (23:03 +0100)]
Start a TT resize only after search finished.

As noticed in the forum, a crash in extract_ponder_from_tt could result
if hash size is set before the ponder move is printed. While it is arguably
a GUI issue (but it got me on the cli), it is easy to avoid this issue.

Closes https://github.com/official-stockfish/Stockfish/pull/1856

No functional change.

2 years agoRemove Null Move Pruning material threshold
31m059 [Thu, 13 Dec 2018 05:35:00 +0000 (00:35 -0500)]
Remove Null Move Pruning material threshold

On November 30th, @xoto10 experimented with removing this threshold,
but the simplification barely failed LTC. I was inspired to try various
[0, 4] tweaks to increase its value, which would narrow the effects of
this threshold without removing it entirely. Various values repeatedly
led to Elo gains at both STC and LTC, most of which were insufficient
to pass.

After a couple of weeks, I tried again to find an Elo-gaining tweak
but noticed that I could raise the threshold higher and higher without
regression. I decided to try removing it entirely--forgetting that
@xoto10 had already attempted this. However, this now performs much
better at both STC and LTC, producing a STC Elo gain and also potentially
a smaller LTC one.

The reason appears to be a recent change in master (e8ffca3) near
this code, which interacts with this patch. This simplification
governs the conditions under which that patch's effects are applied.
Something non-obvious about that change has significantly improved
the performance of this simplification.

I recognize and thank @xoto10, who originally had this idea. Since
I ran several LTCs recently (to determine whether to open this PR,
or one for a related [0, 4]), I would also like to acknowledge the
other developers and CPU donors for their patience. Thank you all!

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 13445 W: 3000 L: 2862 D: 7583
http://tests.stockfishchess.org/tests/view/5c11f01b0ebc5902ba11a6b8

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33868 W: 5663 L: 5563 D: 22642
http://tests.stockfishchess.org/tests/view/5c11ffe90ebc5902ba11a8a9

Closes https://github.com/official-stockfish/Stockfish/pull/1870

Bench: 3343286

2 years agoA combo of parameter tweaks
SFisGOD [Wed, 12 Dec 2018 19:34:17 +0000 (03:34 +0800)]
A combo of parameter tweaks

Joint work by SFisGOD, xoroshiro and Chess13234.

This combo consists of the following tweaks:
Assorted bonuses and penalties by SFisGOD
Bishop and Rook PSQT by SFisGOD
Tempo Value by xoroshiro
Futility pruning by Chess13234

STC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 9005 W: 2082 L: 1882 D: 5041
http://tests.stockfishchess.org/tests/view/5c11628c0ebc5902ba119e90

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 44207 W: 7451 L: 7157 D: 29599
http://tests.stockfishchess.org/tests/view/5c1172a40ebc5902ba119fa3

Bench: 3332460

2 years agoAsymmetrical 8x8 Pawn PSQT
Kurt [Thu, 13 Dec 2018 12:19:55 +0000 (13:19 +0100)]
Asymmetrical 8x8 Pawn PSQT

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 13323 W: 3015 L: 2818 D: 7490
http://tests.stockfishchess.org/tests/view/5c00a2520ebc5902bcedd41b

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 52294 W: 9093 L: 8756 D:34445
http://tests.stockfishchess.org/tests/view/5c00b2c40ebc5902bcedd596

Some obvious followups to this are to further tune this PSQT, or
try 8x8 for other pieces. As of now I don't plan on trying this
for other pieces as I think the majority of the ELO it brings is
for pawns and kings.

Looking at the new values, the differences between kingside and
queenside are quite significant. I am very hopeful that this a
llows SF to understand and plan pawn structures even better than
it already does. Cheers!

Closes https://github.com/official-stockfish/Stockfish/pull/1839

Bench: 3569243

2 years agoChanges identified in RENAME/REFORMATTING thread (#1861)
protonspring [Tue, 11 Dec 2018 12:47:56 +0000 (05:47 -0700)]
Changes identified in RENAME/REFORMATTING thread (#1861)

I've gone through the RENAME/REFORMATTING thread and changed everything I could find, plus a few more. With this, let's close the previous issue and open another.

No functional change.

2 years agoTweak CMH pruning
VoyagerOne [Thu, 6 Dec 2018 23:14:34 +0000 (18:14 -0500)]
Tweak CMH pruning

STC: (yellow)
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 48919 W: 10625 L: 10517 D: 27777
http://tests.stockfishchess.org/tests/view/5c07e6a20ebc5902bcee7395

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 50360 W: 8424 L: 8102 D: 33834
http://tests.stockfishchess.org/tests/view/5c0812450ebc5902bcee76f4

Bench: 3775064

2 years agoremove extra line.
protonspring [Sun, 9 Dec 2018 00:21:22 +0000 (17:21 -0700)]
remove extra line.

2 years agoremove parenthesis.
protonspring [Sun, 9 Dec 2018 00:19:06 +0000 (17:19 -0700)]
remove parenthesis.

2 years agoadd paren.
protonspring [Sat, 8 Dec 2018 18:08:21 +0000 (11:08 -0700)]
add paren.

2 years agosimplify opposite_colors
protonspring [Sat, 8 Dec 2018 17:57:25 +0000 (10:57 -0700)]
simplify opposite_colors

2 years agoRevert "pseudo_legal() and MOVE_NONE"
Stéphane Nicolet [Thu, 6 Dec 2018 14:00:38 +0000 (15:00 +0100)]
Revert "pseudo_legal() and MOVE_NONE"

This reverts commit 33d95482182e459eb033de47a31f142880aa9afb ,
which crashed in DEBUG mode because of the following assert in position.h

````
Assertion failed: (is_ok(m)), function capture, file ./position.h, line 369.
````

No functional change

2 years agoSimplify Killer Move Penalty
VoyagerOne [Thu, 6 Dec 2018 13:39:41 +0000 (14:39 +0100)]
Simplify Killer Move Penalty

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20816 W: 4525 L: 4402 D: 11889
http://tests.stockfishchess.org/tests/view/5c017cb90ebc5902bcede5b4

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 39287 W: 6401 L: 6309 D: 26577
http://tests.stockfishchess.org/tests/view/5c01825e0ebc5902bcede686

Bench: 3773021

2 years agoSimplify time manager in search()
xoto10 [Sun, 2 Dec 2018 15:29:31 +0000 (15:29 +0000)]
Simplify time manager in search()

Remove the F[] array which I find unhelpful and rename `improvingFactor` to
`fallingEval` since larger values indicate a falling eval and more time use.

I realise a test was not strictly necessary, but I ran STC [-3,1] just to
check there are no foolish errors before creating the pull request:

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 35804 W: 7753 L: 7659 D: 20392
http://tests.stockfishchess.org/tests/view/5bef3a0c0ebc595e0ae39c19

It was then suggested to clean the constants around `fallingEval`
to make it more clear this is a factor around ~1 that adjusts time
up or downwards depending on some conditions. We then ran a double
test with this simplification suggestion:

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 68435 W: 14936 L: 14906 D: 38593
http://tests.stockfishchess.org/tests/view/5c02c56b0ebc5902bcee0184

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 37258 W: 6324 L: 6230 D: 24704
http://tests.stockfishchess.org/tests/view/5c030a520ebc5902bcee0a32

No functional change

2 years agopseudo_legal() and MOVE_NONE
protonspring [Thu, 6 Dec 2018 13:02:11 +0000 (14:02 +0100)]
pseudo_legal() and MOVE_NONE

MOVE_NONE is represented as SQ_A1 to SQ_A1 which is never pseudo_legal.

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 38807 W: 8363 L: 8275 D: 22169
http://tests.stockfishchess.org/tests/view/5c05f11d0ebc5902bcee4c86

No functional change

2 years agoIntroduce concept of double pawn protection.
Vizvezdenec [Sun, 2 Dec 2018 19:18:14 +0000 (20:18 +0100)]
Introduce concept of double pawn protection.

Exclude doubly protected by pawns squares when calculating attackers on
king ring. Idea of this patch is not to count attackers if they attack
only squares that are protected by two pawns.

STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 70040 W: 15476 L: 15002 D: 39562
http://tests.stockfishchess.org/tests/view/5c0354860ebc5902bcee1106

LTC
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 16530 W: 2795 L: 2607 D: 11128
http://tests.stockfishchess.org/tests/view/5c0385080ebc5902bcee14b5

This is third king safety patch in recent times so we probably need
retuning of king safety parameters.

Bench: 3057978

2 years agoPenalize refuted killers in continuation history
Miguel Lahoz [Fri, 30 Nov 2018 05:35:47 +0000 (13:35 +0800)]
Penalize refuted killers in continuation history

Currently we apply a penalty in continuation history for refuted TT moves.
We can use the same idea to also penalize refuted killer moves in continuation
history.

STC:
http://tests.stockfishchess.org/tests/view/5c00ccbd0ebc5902bcedd768
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 54366 W: 12086 L: 11687 D: 30593

LTC:
http://tests.stockfishchess.org/tests/view/5c0107880ebc5902bceddc9c
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 25457 W: 4302 L: 4078 D: 17077

Bench: 3419069

2 years agoRemove Overload bonus
ElbertoOne [Sat, 1 Dec 2018 09:28:10 +0000 (10:28 +0100)]
Remove Overload bonus

Compensate by giving the Hanging bonus to weak doubly-attacked
non pawn enemies pieces.

STC: http://tests.stockfishchess.org/tests/view/5bfd53c40ebc5902bced9237
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 62107 W: 13664 L: 13622 D: 34821

LTC: http://tests.stockfishchess.org/tests/view/5bfd74700ebc5902bced9618
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 86406 W: 14381 L: 14365 D: 57660

A possible follow up would be to tune the hanging bonus and/or try to
simplify the hanging bonus condition.

Bench: 3810849

3 years agoRestore development version
Stéphane Nicolet [Thu, 29 Nov 2018 15:17:23 +0000 (16:17 +0100)]
Restore development version

No functional change

3 years agoStockfish 10
Stéphane Nicolet [Thu, 29 Nov 2018 14:45:26 +0000 (15:45 +0100)]
Stockfish 10

Official release version of Stockfish 10.

This is also the 10th anniversary version of the Stockfish project, which
started exactly ten years ago! I wish to extend a huge thank you to
all contributors and authors in our amazing community :-)

Bench: 3939338

3 years agoUpdate list of authors
Stéphane Nicolet [Thu, 29 Nov 2018 14:15:43 +0000 (15:15 +0100)]
Update list of authors

No functional change

3 years agoUse emplace_back() in TB code
Sebastian Buchwald [Thu, 22 Nov 2018 22:50:03 +0000 (23:50 +0100)]
Use emplace_back() in TB code

The patch was tested for correctness by running bench with and
without the change against current master, and the tablebase hit
numbers were found to be identical in both cases. See the pull
request comments for details:
https://github.com/official-stockfish/Stockfish/pull/1826

No functional change.

3 years agoSimplify casting extension
31m059 [Sat, 24 Nov 2018 06:55:09 +0000 (01:55 -0500)]
Simplify casting extension

On November 16th, before the removal of the depth condition, I tried
revising castling extensions to only handle castling moves, rather than
moves that change castling rights generally. It appeared to be a slight
Elo gain at STC but insufficient to pass [0, 4] (+0.5 Elo), but what I
overlooked was that it made pos.can_castle(us) irrelevant and should
have been a simplification. Recent discussion with @Chess13234 and
Michael Chaly (@Vizvezdenec) inspired me to take a second look, and
the simplification continues to pass when rebased on the current master.

This replaces two conditions with one, because type_of(move) == CASTLING
implies pos.can_castle(Us), allowing us to remove the latter condition.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 110948 W: 24209 L: 24263 D: 62476
http://tests.stockfishchess.org/tests/view/5bf8f65c0ebc5902bced3a63

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 88283 W: 14681 L: 14668 D: 58934
http://tests.stockfishchess.org/tests/view/5bf994a60ebc5902bced4349

Bench: 3939338

3 years agoTurn on MADV_RANDOM for Syzygy mmaps (on Unix-like builds)
Steinar H. Gunderson [Sat, 24 Nov 2018 10:17:12 +0000 (11:17 +0100)]
Turn on MADV_RANDOM for Syzygy mmaps (on Unix-like builds)

When running on a cloud VM (n1-highcpu-96) with several NVMe SSDs and
some non-SSDs for tablebases, I noticed that the average SSD request size was
more than 256 kB. This doesn't make a lot of sense for Syzygy tablebases,
which have a block size of 32 bytes and very low locality.

Seemingly, the tablebase access patterns during probing make the OS,
at least Linux, think that readahead is advantageous; normally, it
gives up doing readahead if there are too many misses, but it doesn't,
perhaps due to the fairly high overall hit rates. (It seems the kernel cannot
distinguish between reading a block that was paged in because the userspace
wanted it explicitly, and one that was read as part of readahead.)

Setting MADV_RANDOM effectively turns off readahead, which causes
the request size to drop to 4 kB. In the aforemented cloud VM test,
this roughly tripled the amount of I/O requests that were able to go
through, while reducing the total traffic from 2.8 GB/sec to 56 MB/sec
(moving the bottleneck to the non-SSDs; it seems the SSDs could have
sustained many more requests).

Closes https://github.com/official-stockfish/Stockfish/pull/1829

No functional change.

3 years agoQsearch simplification. (#1828)
Jörg Oster [Sun, 25 Nov 2018 10:27:40 +0000 (11:27 +0100)]
Qsearch simplification. (#1828)

Don't do an extra TT update in case of a fail-high,
but simply break off the moves loop and let the TT update
at the end of qsearch do this job.
Same workflow/logic as in our main search function now.

Tested for no regression to be on the safe side.
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 30237 W: 6665 L: 6560 D: 17012
http://tests.stockfishchess.org/tests/view/5bf928e80ebc5902bced3f3a

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 51067 W: 8625 L: 8553 D: 33889
http://tests.stockfishchess.org/tests/view/5bf937180ebc5902bced3fdc

No functional change.

3 years agoReintroduce tropism to kingdanger
Vizvezdenec [Sat, 24 Nov 2018 01:13:36 +0000 (02:13 +0100)]
Reintroduce tropism to kingdanger

Tropism in kingdanger was simplified away in this pull request #1821.
This patch reintroduces tropism in kingdanger with using quadratic scaling.

Passed STC http://tests.stockfishchess.org/tests/view/5bf7c1b10ebc5902bced1f8f
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 52803 W: 11835 L: 11442 D: 29526

Passed LTC http://tests.stockfishchess.org/tests/view/5bf816e90ebc5902bced24f1
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17204 W: 2988 L: 2795 D: 11421

How do we continue from there?

I've recently tried to introduce tropism difference term in kingdanger which
passed STC 6 times but failed LTC all the time. Maybe using quadratic scaling
for it will also be helpful.

Bench 4041387

3 years agoRemove the tropism term from kingDanger
31m059 [Sat, 24 Nov 2018 01:09:03 +0000 (02:09 +0100)]
Remove the tropism term from kingDanger

A recent LTC tuning session by @candirufish showed this term decreasing significantly. It appears that it can be removed altogether without significant Elo loss.

I also thank @GuardianRM, whose attempt to remove tropism from king danger inspired this one.

After this PR is merged, my next step will be to attempt to tune the coefficients of this new, simplified kingDanger calculation.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 12518 W: 2795 L: 2656 D: 7067
http://tests.stockfishchess.org/tests/view/5befadda0ebc595e0ae3a289

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 164771 W: 26463 L: 26566 D: 111742
http://tests.stockfishchess.org/tests/view/5befcca70ebc595e0ae3a343

LTC 2, rebased on Stockfish 10 beta:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75226 W: 12563 L: 12529 D: 50134
http://tests.stockfishchess.org/tests/view/5bf2e8910ebc5902bcecb919

Bench: 3412071

3 years agoForce time check on TB probe in search.
Joost VandeVondele [Mon, 4 Jun 2018 08:31:25 +0000 (10:31 +0200)]
Force time check on TB probe in search.

Because of aggressive time management and optimistic assumptions
about move overhead, it's still very easy to get Stockfish to forfeit
on time when we hit an endgame and have Syzygy EGTB on a spinning
drive. The latency from serving a few thousand EGTB probes (~10ms each),
of which there can currently be up to 4000 outstanding before a time
check, will easily overwhelm the default Move Overhead of 30ms.

This problem was first raised by Gian-Carlo Pascutto and some solutions
and improvements were discussed in the following pull requests:
https://github.com/official-stockfish/Stockfish/pull/1471
https://github.com/official-stockfish/Stockfish/pull/1623
https://github.com/official-stockfish/Stockfish/pull/1783

This patch is a minimal change proposed by Marco Costalba to lower
the impact of the bug. We now force a check of the clock right after
each tablebase read.

No functional change.

3 years agoBonus for restricting opponent's piece moves
xoto10 [Tue, 20 Nov 2018 06:45:00 +0000 (07:45 +0100)]
Bonus for restricting opponent's piece moves

STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 51883 W: 11297 L: 10915 D: 29671
http://tests.stockfishchess.org/tests/view/5bf1e2ee0ebc595e0ae3cacd

LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 15859 W: 2752 L: 2565 D: 10542
http://tests.stockfishchess.org/tests/view/5bf337980ebc5902bcecbf62

Notes:

(1) The bonus value has not been carefully tested, so it may be possible
to find slightly better values.

(2) Plan is to now try adding similar restriction for pawns. I wanted to
include that as part of this pull request, but I was advised to do it as
two separate pull requests. STC is currently running here, but may not add
enough value to pass green.

Bench: 3679086

3 years agoStockfish 10-beta
Stéphane Nicolet [Mon, 19 Nov 2018 10:18:21 +0000 (11:18 +0100)]
Stockfish 10-beta

Preparation commit for the upcoming Stockfish 10 version, giving a chance to catch last minute feature bugs and evaluation regression during the one-week code freeze period. Also changing the copyright dates to include 2019.

No functional change

3 years agoTweak Queen PSQT based on tuned values
SFisGOD [Sat, 10 Nov 2018 12:06:05 +0000 (20:06 +0800)]
Tweak Queen PSQT based on tuned values

STC: (Yellow)
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 63140 W: 13433 L: 13353 D: 36354
http://tests.stockfishchess.org/tests/view/5bed42c90ebc595e0ae37cf5

LTC: (Green)
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 47714 W: 7785 L: 7485 D: 32444
http://tests.stockfishchess.org/tests/view/5bec3b8c0ebc595e0ae36dec

Closes https://github.com/official-stockfish/Stockfish/pull/1816

Bench: 3717396

3 years agoTune evaluation scores
Kurt [Thu, 15 Nov 2018 14:16:18 +0000 (09:16 -0500)]
Tune evaluation scores

STC:
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 84697 W: 18173 L: 18009 D: 48515
http://tests.stockfishchess.org/tests/view/5bea366f0ebc595e0ae34793

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 157625 W: 25533 L: 24893 D: 107199
http://tests.stockfishchess.org/tests/view/5be8b69e0ebc595e0ae33024

Personally, I feel like SF has been tuned to death recently and that we
need to step away from existing-parameter tunes for a bit and focus more
on new ideas. I don't really think there's much more ELO in these tunes
(for now). For me at least, this was the last existing-parameter tune I'll
be running for quite a while. Cheers!

Bench: 3572567

3 years agoRemove BlockedStorm array
protonspring [Mon, 19 Nov 2018 09:37:07 +0000 (10:37 +0100)]
Remove BlockedStorm array

Apparently, only RANK_3 is relevant. This removes a look-up and the
BlockedStorm array, but adds another conditional.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 84340 W: 18054 L: 18054 D: 48232
http://tests.stockfishchess.org/tests/view/5bea10f40ebc595e0ae3457b

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 31874 W: 5135 L: 5032 D: 21707
http://tests.stockfishchess.org/tests/view/5beadb6a0ebc595e0ae35542

Closes https://github.com/official-stockfish/Stockfish/pull/1814

Bench: 3799443

3 years agoSimplify Castle Extension
VoyagerOne [Mon, 19 Nov 2018 09:27:52 +0000 (10:27 +0100)]
Simplify Castle Extension

Remove depth condition in castle extension, also don't extend if
Singular Extension and Check Extansion fail to extend.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 42070 W: 9118 L: 9036 D: 23916
http://tests.stockfishchess.org/tests/view/5be899cc0ebc595e0ae32f07

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 78278 W: 12490 L: 12458 D: 53330
http://tests.stockfishchess.org/tests/view/5be8ac420ebc595e0ae33010

Bench: 3611041

3 years agoCode style in search.cpp
protonspring [Fri, 2 Nov 2018 16:49:51 +0000 (10:49 -0600)]
Code style in search.cpp

It does not appear to be not necessary or advantageous to
conditionally initialize kingRing[Us] or kingAttackersCount[Them],
so the 'else' can be removed.

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 22873 W: 4923 L: 4804 D: 13146
http://tests.stockfishchess.org/tests/view/5be9a8270ebc595e0ae33c7e

No functional change

3 years agoUpdate a comment in the evaluate.cpp file to reflect recent change
Nikolay Kostov [Mon, 12 Nov 2018 20:15:17 +0000 (22:15 +0200)]
Update a comment in the evaluate.cpp file to reflect recent change

No functional change

3 years agoRook PSQT Tuned
SFisGOD [Sat, 10 Nov 2018 07:03:15 +0000 (15:03 +0800)]
Rook PSQT Tuned

Failed STC (Yellow )
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 56302 W: 12007 L: 11953 D: 32342
http://tests.stockfishchess.org/tests/view/5be69d210ebc595e0ae3185b

Passed 1st LTC (Green)
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 8745 W: 1480 L: 1301 D: 5964
http://tests.stockfishchess.org/tests/view/5be682960ebc595e0ae31818

Failed 2nd LTC (Red)
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 19398 W: 3040 L: 3133 D: 13225
http://tests.stockfishchess.org/tests/view/5be69b840ebc595e0ae31856

Passed 3rd LTC (Green)
LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 107516 W: 17342 L: 16858 D: 73316
http://tests.stockfishchess.org/tests/view/5bea879a0ebc595e0ae34d80

Closes https://github.com/official-stockfish/Stockfish/pull/1809

How to continue from there?

The values in the rook table now look a bit strange for a human eye
and are hard to explain, maybe it would be nice to simplify them
by hand and see if we can pass another (clean) double green with a
more regular array.

Bench: 3188070

3 years agoChange default contempt from 21 to 24 centipawns
Vizvezdenec [Fri, 9 Nov 2018 01:02:24 +0000 (04:02 +0300)]
Change default contempt from 21 to 24 centipawns

To top the rating lists and get more interesting middle play, it
is a good habit to set the default contempt to the highest value
that does not regress against contempt=0. We recently decreased
PawnValueEg it is logical that to raise a little bit the default
higher contempt because of the following internal dependency in
line 334 of search.cpp :

````
int ct = int(Options["Contempt"]) * PawnValueEg / 100; // From centipawns
````

STC: contempt=24 passed non-regression vs contempt=0
http://tests.stockfishchess.org/tests/view/5bd6d7f80ebc595e0ae21e14

LTC: contempt=24 passed non-regression LTC vs contempt=0
http://tests.stockfishchess.org/tests/view/5bd6e0980ebc595e0ae21f07

On 2018-11-01, we also tested the effects of contempt=21 and contempt=24
against Stockfish 9, and the net result was neutral:

Contempt 21
ELO: 51.68 +-1.9 (95%) LOS: 100.0%
Total: 40000 W: 9487 L: 3581 D: 26932
http://tests.stockfishchess.org/tests/view/5bdb1a140ebc595e0ae2620a

Contempt 24
ELO: 52.21 +-2.0 (95%) LOS: 100.0%
Total: 40000 W: 9759 L: 3793 D: 26448
http://tests.stockfishchess.org/tests/view/5bdb1b680ebc595e0ae2620d

Bench: 3459874

3 years agoClear TableBase mappings in Search::clear()
Nooby [Sat, 27 Oct 2018 20:12:34 +0000 (04:12 +0800)]
Clear TableBase mappings in Search::clear()

This patch will make possible to free mapped TB files with "ucinewgame" command.

We wrote this patch specifically to address a problem that arose while
running Stockfish with 7-piece tablebases as a kibitzer at TCEC for
extended periods of time across multiple games. It was noted that after
some time, the NPS of the kibitzing Stockfish (which is usually 3x faster
than the Stockfish actually competing) would drop precipitously, eventually
falling to preposterously low numbers until restarted.

Their eval bot basically inputs FEN, go infinite, stop and loop, it probably
didn't do ucinewgame either. As time goes it gradually slowed down and OS
starts to use swap, this is not reasonable since the engine only uses 16GB
hash and the machine has 1TB physical RAM and does nothing else.

Author : noobpwnftw

Closes https://github.com/official-stockfish/Stockfish/pull/1790

No functional change.