Workaround value-initialization in MSVC

The syntax splitPoints() should force the compiler to
value-initialize the array and because there is no
user defined c'tor it falls back on zero-initialization.

Unfortunatly this is broken in MSVC compilers, because
value initialization for non-POD types is not supported,
so left splitPoints un-initialized and add in split()
initialization of slavesPositions, that is the only
member not already set at split time.

This fixes an assert under MSVC when running with
more than one thread.

Spotted and reported by Jundery.

No functional change.

Add KBPKP endgame

It is a draw if pawns are on G or B files, weaker pawn is
on rank 7 and bishop can't attack the pawn.

No functional change (because it is very rare and does not appear in bench)

Change slave_available() API

To return a pointer to the available
thread instead of a bool. This allows
to simplify the core loop in split().

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Rename posKey stored in the transposition table

[Edit: Slightly extended by me]

No functional change.

Add const qualifer to check_is_dangerous

No functional change.

Slightly change split() API

This function "returns" two values: bestValue and bestMove

Instead of returning one and passing as pointer the other
be consistent and pass as pointers both.

No functional change.

Derive ThreadPool from std::vector

Prefer sub-classing to composition in this case.

No functional change.

Move split() under Thread

Previous renaming patch suggested this reformat:
when a better naming leads to a better code!

No functional change.

Some renaming in split()

Naming suggested by jundery.

No functional change.

Be clear about not LMR the ttMove

Currently a ttMove is reduced with ss->reduction = DEPTH_ZERO,
so it is actually not reduced (as it should be), but the
trick works just becuase it happens that ttMove is the first
to be tried and

reduction(depth, 1)

Always returns zero. So explicitly forbid reduction of ttMove
in the LMR condition. This is much clear and self-documented.

No functional change.

Templetize score_xxx() functions

So to be style-wise aligned with the corresponding
generate() functions.

No functional change.

Rename prevents_move() to refutes()

Better! From DiscoCheck.

No functional change.

Correctly score enpassant captures

Surprisingly this rare case was not considered
when scoring a capture.

Also take in account that in the promotion case
we gain a new piece (typically a queen) but we
lose the promoting pawn.

These small issues were present since Glaurung times!

Found while browsing DiscoCheck sources

bench: 5400063

Unify History and Gains under a single Stats class

Handling of History and Gains is almost the same, with
the exception of the update logic, so unify both
classes under a single Stats struct.

No functional change.

Retire history.h

And move the contents to movepick.cpp, where they are
mostly used.

Idea from DiscoCheck.

No functional change (bench 5379503)

Restore "fail-low of reduced" and close regression

This reverts "Threat Extensions" and is the last of
this revert series.

In single-thread tests we should now be on par with 2.3.1

Revert "Simplify Evaluation"

This reverts commit 496c7497cb81de4383

Revert "Extend full 3 fold detection to PvNodes"

Rewrite do_castle_move()

And handle the castle directly in do/undo_move().
This allow to greatly simplify the code.

Here the beast is the nasty Chess960 that is
really tricky to get it right because could be
that 'from' and 'to' squares are the same or
that king's 'to' square is rook's 'from' square.

Anyhow should work: verified on all Chess960
starting positions.

No functional and no speed change also in Chess960.

Rewrite do_null_move()

Use a more traditional approach, along the same lines
of do_move().

It is true that we copy more in do_null_move(), but we
save the work in undo_null_move(). Speed test shows the
new code to be even a bit faster.

No functional change.

Get rid of some locals in do_castle_move()

Rewrite the logic to get rid of kBefore and rBefore.

No functional change.

Don't prefetch if not needed

Prefetch access to hash tables only in case we
have changed pawn or material hash keys.

No functional change.

Retire generate_king_moves()

We have only one call place so inline its content.
BTW, function is already declared as FORCE_INLINE.

Also some small refactoring while there.

No functional change.

Clarify slavesMask usage

When a thread is allocated a bit is set in slavesMask.
This bit corresponds to the thread's index field that,
because it happens to be the position in the threads
array, eventually it is equal to the loop index 'i'.

But instead of relying on this 'coincidence', explicitly
use the 'idx' field so to clarify slavesMask usage.

Backported from c++11 branch.

No functional change.

Revert "Further push singular extension"

This reverts commit 4c91dbc28e8bb6265f8

Seems a regression on extended test by both Gary and me.

Merge branch 'simplify_eval' of https://github.com/glinscott/Stockfish

Test results are looking good after 12500 games.

ELO: 6.55 +- 99%: 8.02 95%: 6.09
LOS: 99.99%
Wins: 1968 Losses: 1732 Draws: 8813

Also, here are the noise.py results, which seem to have stabilized:
Games: 12526 , result: [1969, 1734, 8823]
Estimated ELO: 6.94963842777
Noise as function of number of games:
['81.89', '565.26', '110.87', '104.39', '38.22', '49.98', '18.56', '16.76',
'11.02', '8.90', '17.36', '9.84', '10.81', '5.13', '6.22', '3.32', '5.83',
'7.21', '15.27', '1.63', '4.04', '9.51', '0.54', '0.75', '1.06', '2.93',
'4.59', '6.85', '13.62', '9.87', '14.74', '20.46', '22.18', '24.33', '31.02',
'34.99', '35.22', '33.22', '32.46', '37.02', '29.10', '36.34', '42.11', '39.33',
'26.16', '28.25', '35.42', '31.04', '29.26', '23.91', '22.52', '23.49', '20.00',
'24.39', '17.22', '16.50', '10.69', '9.15', '9.57', '4.77', '6.67', '3.87', '2.57',
'2.84', '2.60', '3.32', '2.08', '2.93', '4.47', '4.41', '4.83', '4.86', '6.40',
'5.98', '6.10', '6.83', '5.83', '6.22', '5.71', '8.52', '9.25', '5.98', '7.52',
'7.76', '8.76', '8.55', '8.64', '7.19', '5.83', '4.59', '4.77', '4.26', '4.98',
'5.29', '5.41', '4.92', '5.59']

bench: 5229106

Simplify evaluation

Small reformat of split()

No functional chhange.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix an idiotic icc warning

Intel Compiler has 'invented' this pearl:

warning #1476: field uses tail padding of a base class

Just becuase we have subclassed MainThread and added
the field 'bool thinking'.

Pure nosense. Silence the warning.

No functional change.

Futher renaming in thread.cpp

No functional change.

Big renaming in thread stuff

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix race while exiting

Fix again TimerThread::idle_loop() to prevent a
theoretical race with 'exit' flag in ~Thread().

Indeed in Thread d'tor we raise 'exit' and then
call notify() that is lock protected, so we
have to check again for 'exit' before going to
sleep in idle_loop().

Also same change in Thread::idle_loop() where we
now check for 'exit' before to go to sleep.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Remove Threat Extension

Great code simplification: - instead do not futility
prune threat refutations. allows_move() is therefore removed.

4000 games at 50,000 nodes/move:
1085-989-1926 [51.2%] LOS=98.3%

4000 games in 10"+0.1"
756-751-2493 [50.1%] LOS=55.1%

EDIT: I have retested the patch of Lucas in a slightly different form
(without pruning in PvNode) and test mre or less confirms that
60 lines of code are totally unuseful:

After 6195 games at 15"+0.05"
1333 - 1325 - 3537 ELO 0

bench 5140990

Fix a bug in timer loop

Silly logic bug introduced in dda7de17e74d7e8

Timer thread, when msec = 0, instead of going
to sleep, calls check_time() in an endless loop.

Spotted and reported by snino64 due to abnormally
high CPU usage.

No functional change.

Polymorphic Thread hierarchy

Subclass MainThread and TimerThread and declare
idle_loop() virtual. This allow us to cleanly
remove a good bunch of hacks, relying on C++
polymorphism to do the job.

No functional change.

Don't use do_sleep flag

Rename it is_finished and use it only in main
thread to signal search is finished. This allows
us to simplify the complex SMP logic.

Ultra tricky patch: deep test is required under
wide conditions like pondering on and option
"Use Sleeping Threads" set to false.

No functional change.

Re-add the hack

This reverts commit 869c9244101

I misunderstood here. Actually it can happen that
thread is created but still not entered idle_loop
and at the same time start_searching() is called.

Becuase 'do_sleep' is set start_searching() will
set it to false and start the search, but when,
at last, the thread enters idle_loop(), resets
the flag and goes to sleep: not what we want.

Revert the hack waiting for a better solution
in the next patches.

No functional change.

Retire set_timer()

Also assure in Thread::timer_loop() that when
timer interval is 0 (timer is disabled) we
never call check_time()

No functional change.

Retire obsolete race hack

This hack was introduced in d282cf6964d493
to workaround a race with start_searching(),
but these days is no more needed.

No functional change.

Retire Threads wake_up() and sleep()

These functions are used in just one place.
And generalize wait_for_stop()

No functional change.

Rename wake_up() to notify_one()

To align to C++ std::thread conventions.

No functional change.

Unify 'ponderhit' handling

Finally we can now merge the 'ponderhit' case with
'stop' and 'quit'.

The patches have been done step by step to help debugging
becuase this is really tricky code.

No functional change.

Small change to "ponderhit" handling

Reset Limits.ponder only if search continue, but if
we are going to stop the search there is no need
(and is also confusing) to clear the 'ponder' flag.

This mimics the behaviour upon rceiving 'stop' when
pondering.

No functional change.

Simplify and rename wait_for_stop_or_ponderhit()

Setting stopOnPonderhit is now done by the caller.

No functional change.

Simplify a condition in search()

And rearrange best value update in case of SpNode.

No functional change.

Clarify SAN disambiguation in case of a pinned piece

In SAN notation when two pieces of the same type can
move to a given destination square, a disambiguation
additional info (like starting file) shall be added
to the SAN move.

If one of the two pieces is pinned, the corresponding
move _could_ be illegal and in this case disambiguation
is not needed. But to be pinned alone it is not enough
to deduce that the move is illegal, for instance in this
position:

R3rk2/2r6/8/8/8/8/8/K7 b - - 0 1

The move Rc8 is ambiguous although the rook in e8 is pinned
and the correct SAN notation should be Rcc8.

No functional change.

Async 'stop' command

Don't wait for the search to finish after a 'stop'
command, but keep processing the GUI input if any.

Also explicitly wake up the main thread (that could be
sleeping) after a 'stop' or 'quit' command and do not
rely on wait_for_search_finished() doing it for us.

This patch cleans up the code and functions's definitions,
but it is risky and needs a good test under different
conditions to be sure it does not introduces hungs up.

No functional change.

Revert so called "fromNull patch"

Revert patch c581b7ea3627482

Seems a regression after testing from Gary:
ELO: 7.24 +- 99%: 17.03 95%: 12.93
LOS: 97.86%
Wins: 439 Losses: 381 Draws: 1962

And mine:
After 5410 games at 15"+0.05
Wins: 936 Losses: 1141 Draws: 3333  ELO -13

Moreover we know that there is a regression in the range
of patches which include the fromNull patch.

Probably this is not the only regression since 2.3.1 and
perhaps the idea under fromNull is good, but at the moment,
while in deep regression hunting, better to be on the safe
side and revert it entirely.

My guess on why this is a regression is that using the
negated evaluation of previous ply in case of null search
fails to take in account the king safety asymmetry between
the two colors. This is of course just a guess.

bench 5503830

Have fun with union in book.cpp

Fancy way to use an union to map polyglot
zobrist keys in one go.

Also some renaming while there.

No functional change.

Retire 'Cowardice' and 'Aggressiveness' UCI options

They are not self-describing and create a lot of user
requests about them.

Given that the values are already well tuned there
is no need to expose them as UCI options.

No functional change.

Retire 'mate in x' hack

Sometimes is faster, but not always and on very long mates
produces strange scores probably due to truncation of PV
artifacts.

So simply perform normal search also in case of UCI 'mate x'
command, with the only difference that when a mate in x is
found search returns immediately.

No functional change.

Don't exit if unable to find bench file

Now that we can call 'bench' command also from
interactive terminal it makes no more sense to
exit the application if the user types a wrong
file name.

No functional change.

Teach file_to_char() about upper/lower case

This allows to further simplify Position::fen()

No functional change.

Reformat FEN construction

Simplify and shrink code.

No functional change.

Remove some obsolete asserts on TT values

Now that insert_pv_in_tt() stores VALUE_NONE in
TT's position evaluation those 2 asserts are
obselete.

No functional change.

Allow to pass a 'seed' to RKISS

This somewhat simplifies the code.

Suggested by Lucas Braesch.

No functional change.

Micro-optimization in evaluate_space()

Since &-ing with SpaceMask restricts the set to the home
half of the board, it is possible to use just one popcount
instead of 2 by shifting "safe" to the other half of the
board. This gives a small speedup especially on systems
where hardware popcount is not available.

Patch kindly sent by Richard Vida.

No functional change.

Add 'mate' limit to 'bench' command

It is now possible to run SF on a 'mate in x' testsuite.

For instance in case of a file with fen strings of
positions with mate in 10 we can now 'bench' on it:

stockfish bench 128 1 10 mate_in_10.epd mate

No functional change.

Handle UCI command "mate in x moves"

Following a user request I added the handling of UCI:

go mate x

Currently we just return from a PV node if x moves have been
done. Probably not the best approach. I have looked at Fruit/Toga
sources and there is even simpler: engine falls back on a fixed
depth search.

No functional change.

Revert evaluation cache

And return on using TT as backing store for position
evaluations.

Tests (even on single thread) show eval cache was a regression.
In multi thread result should be even worst because eval cache
is a per-thread struct, while TT is shared.

After 4957 games at 15"+0.05 (single thread)
eval cache vs master 969 - 1093 - 2895  -9 ELO

So previous reported result of +18 ELO was probably due to an
issue in the testing framework (a bug in cutechess-cli) that
has been fixed in the meanwhile.

bench: 5386711

Add list of legal moves to Position::pretty()

Along the same lines of previous patch now we add
the list of the legal moves in the given position.

No functional change.

Add checkers info to Position::pretty()

In case current position is under check, list the
squares of the checker(s) pieces.

This should satisfy a specific user request.

No functional change.

Remove two obsolete asserts in prevents_move

Now that this function is called also to calculate
move's extensions the asserts are no more valid.

No functional change.

Rename yields_to_threat and prevents_threat

Follow Lucas suggestions and better name these
two functions.

No functional change.

Introduce Null Threat extension

In case of null search at low depths returns a fail low
due to a threat then, rather than return beta-1 (to cause
a re-search at full depth in the parent node), we set a flag
threatExtension = true (false by default) that will cause
moves that prevent the threat to be extended of one ply
in the following search.

Idea and patch is by Lucas Braesch.

Lucas also did the tests:
1500 games in 5"+0.05":
SF_threatExtension vs SF_20121222: 366 - 331 - 803 [51.2%] LOS=90.8%

3000 games in 10"+0.1":
SF_threatExtension vs SF_20121222: 610 - 559 - 1831 [50.8%] LOS=93.2%

Tests confirmed by Gary after 10570 games,
ELO: 2.79 +- 99%: 8.72 95%: 6.63
LOS: 94.08%
Wins: 1523 Losses: 1438 Draws: 7607

And finally by me at 15"+0.05, single thread, 3824 games
threatExtension vs master 768 - 692 - 2364  +7 ELO

bench 4918443

Fix a couple of extra spaces

No functional change.

Retire Position::in_check()

It is redundant with Position::checkers()

No functional change.

Retire Position::move_is_legal()

Use the new contains() method of struct MoveList

No functional change.

Small tweak in is_pseudo_legal()

This is difficult code becuase a bug here could lead
to very subtle crashes in case of SMP games where we
have TT move corruption due to concurrent access.

Anyhow I have fully verified te code throwing at it
random moves. It shoudl work.

No functional change.

Introduce namespace Pawns

And retire old struct PawnTable along the same lines
of previous patch.

No functional change.

Introduce namespace Material

And retire old struct MaterialTable simplifying the code.

No functional change.

Don't need to check for bestValue < beta to split

With rearrangement of fail high code this condition
is no more necessary.

Found by Jörg Oster.

No fuctional change.

Remove an extra semicolon

No functional change.

Revert store of distinct upper and lower bounds

Test by Joona prooves the new feature don't value 70 added lines of code.

Grand totals after 10040 games (crashes: 0) for tt_both

master_9edc7 - 6a93488_6a934: 1756 - 1688 - 6596 ELO +2 (+- 2.7)

Confirmed by test of Gary:

After 8680 games:
ELO: 0.80 +- 99%: 9.62 95%: 7.31
LOS: 65.38%
Wins: 1288 Losses: 1268 Draws: 6130

Thanks a lot to both for testing it !!!

bench 5149248

Merge branch 'eval_cache'

Unusually good result. Defenitly needs further verifications.

After 2160 games at 15"+0.05
Mod vs Orig 486 - 367 - 1307 ELO +19

bench: 6261882

Fix comparison with alpha, not beta

This silly bug seems the reason of the unsual bench
value.

bench: 6261882

Ensure valueLower <= valueUpper

In case a TTEntry stores both an upper and a lower bound
ensure that upper bound is not smaller than lower bound.

bench 1813815

Store distinct upper and lower bound scores

This is more complex than what I'd like but I
was unable to split in small chunks.

Here we add 2 slots to TTEntry (valueUpper and depthUpper)
so that sizeof(TTEntry) returns to the original 16 bytes
and we can pack exactly 4 entries in a 64 bytes cache line.

Now we save an upper bound score alongside a lower (exact)
score. The idea is to increase TT cut-offs rates becuase
there is now an higher probability for a node to use TT info.

This patch is highly experimental and probably needs further
steps as is hinted by an unrealistic bench number:

bench: 2022385

Micro-optimize color_of()

In almost all cases we already know in advance that
color_of() argument is different from NO_PIECE.

So avoid the check for NO_PIECE in color_of() and
test at caller site in the very few places where
this case could occur.

As a nice side effect, this patch fixes a (bogus)
warning under some versions of gcc.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Update Readme.txt now that we support 64 threads

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Merge branch 'eval_cache'

Use an eval cache instead of TT to store node
position evaluations.

It is already an improvment and, because it frees
two TT entry slots, paves the way to extend TT to
store both upper and lower bounds.

After 4855 games, single thread, 15"+0.05
Mod vs Orig 1165 -920 - 2770 ELO +18

bench: 5149248

Increase MAX_THREADS to 64

And document why this is an hard limit. It
seems for some (lucky) people 32 threads
are not enough.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Reintroduce eval optimizaion from null search

Now that conversion to eval cache is finished
we can reintroduce this optimization.

bench: 5149248

Don't save eval score in TT

This patch completes the removal of eval info
in TT table.

No functional change.

Don't use TT just to save a node evaluation

In search(), after we evalute the position, in case there
isn't any TT entry we create one with just the evaluation
score.

This patches removes that code. The reason becuase the patch
deserves a single commit it is becuase introduces a (very small)
functional change due to the fact that the total number of
TT stores is less now and this slightly alters the TT hits
of our benchmark.

bench: 4983262

Don't read eval from TT anymore

Rely fully on eval cache. Note that we still save eval
info to TT, this is not needed at this moment and will be
removed in future patches. We keep it so to have a "non
functional change" patch.

No functional change.

Retire eval optimization from null search

Simplify things preparing for further changes.

bench: 4983282

Add eval cache infrastructure

With this patch series we want to introduce a per-thread
evaluation cache to store node evaluation and do not
rely anymore on the TT table for this.

This patch just introduces the infrastructure.

No functional change.

Don't double check for move legality

In case of a RootNode or a SpNode move has
been already checked for legality so we can
skip a redundant check.

Spotted by Frank Genot.

No functional change.

Update bestValue when futility pruning

In qsearch we should update the bestValue as we do
in case of futilityValue < beta, also when pruning
moves with non-positive see.

Spotted by Lucas Braesch

Bench: 5695710

Avoid spamming the GUI in multipv search

Send the PV lines to GUI only once at the end of the
PV search loop or just in case of long searches.

We need to sync also sending of "currmove" info to
avoid sending info on current move without first
informing the GUI on the PV line we are searching on.

No functional change.

Triviality in move_gives_check()

It seems even a bit faster, although handling of the special
cases is not the hot path.

No functional change.

Better document fail-high condition

At this point we have already verified (value > alpha)
and this implies, in case of a non-PV node, where search
window size is zero, that value >= beta.

This is not so self-evident, so document the code with
an assert condition.

No functional change.

Don't access std::cout from Position::print()

Let the caller to decide where to redirect (cout or cerr) the
ASCII representation of the position. Rename the function to
reflect this.

Renamed also from_fen() and to_fen() to set() and fen() respectively.

No functional change.

Restore old BOUND_EXACT logic in qsearch

In case a PvNode node has a static evaluation above alpha but
no available moves we want to flag the node as BOUND_EXACT,
not as BOUND_UPPER as is currently.

The behaviour was recently introduced with patch d471c49700fbe8281
of 3/10/2012

Spotted by Hongzhi Cheng.

bench: 5558464

Revert "Don't prune discovered checks"

Both Lucas re-test and Jean-Francois confirrm it
is a regression.

Here Jean-Francois's results after 3600 games :
Score of 96d3b1c92b8 vs 3b87314: 690 - 729 - 2181 [0.495] 3600
ELO: -3.86 +- 99%: 14.94 95%: 11.35
LOS: 15.03%
Wins: 690 Losses: 729 Draws: 2181 Total: 3600

Bench: 5404066

Don't prune discovered checks

Don't prune and eventually extend check moves of type
DISCO_CHECK (pun intended, Lucas will understand :-) ).

Patch from Lucas Braesch that has also tested it:

Result: 879-661-2137, score=52.96%, LOS=100.00% (time 10"+0.1")

I have started a verification test right now.

bench: 6004966

Previous patch test results

From Jean-Francois's

Final result after 5000 games :
Score of c581b7e vs a878312: 1163 - 970 - 2867 [0.519] 5000
ELO: 13.35 +- 99%: 12.71 95%: 9.65
LOS: 100.00%
Wins: 1163 Losses: 970 Draws: 2867 Total: 5000

From me

After 3266 games at 20"+0,05
Score of c581b7e vs a878312: 612 - 607 - 2047

So no regression at longer TC and perhaps a little gain at
fast TC.

Another attempt at evaluation shortcut

In this case we try a rather drastic
approach: we simply don't futility prune
in qsearch when arriving from a null move.

So we save evaluating and also save to mess
with eval margins at all because margin is used
only in futility.

Also accuracy should not be affected, actually it
improves because we don't prune anything anymore.

bench: 5404066

Temporary revert previous patch

Performs well at very short TC of 40/4+0.05 (courtesy of Jean-Francois):
Wins: 2503 Losses: 2146 Draws: 5581 Total: 10230 +12 ELO

But is poor at longer TC of 20"+0.05
Wins: 321 Losses: 373 Draws: 1141 Total: 1808 -10 ELO

The patch was clearly a tradoff between speed and accuracy and
the most interesting part of it are test results that can be
commented as follows:

- A short TC is very sensible to any speed increase
- A longer TC is more sensible to accuracy and less to speed

So a patch that does not change speed is suitable to be tested at
short TC, while a speed/accuracy compromise patch is IMO better to
be tested at longer TC to verify loss of accuracy can be tolerated.

In this case the revert is only temporary. We will come back again
once we will be able to preserve the evaluation margin.

bench: 5809010