* New version is documented and logic should be easier to follow
* Add extra check to not use LSN with x moves / y seconds time control
* New code fixes some rear cases where old code (still) causes program to lose on time at move 1.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
* The function is called only in one place
* It must not be called elsewhere
* The function call easily replaced with simple one line condition
No functional change (tested with usual set + 2000 random positions)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
* First one is without any documentation, code is working just fine,
so there seems to be nothing that really should be fixed.
* Second one requesting emergency measures on aspiration fail low
when we are running out of time and we are without good move.
After very long time, I've come to conclusion that this is
impossible to fix, so remove request.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use an exponenital law instead of a linear one for
history pruning.
This should prune more at low depths and a bit less
at high depths.
After 965 games
Mod vs Orig +233 =504 -228 +2 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Correct beta by razor margin when callin qsearch
After 1019 games on Joona's QUAD
Mod - Orig: 524 - 495 (+10 elo)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Call directly 'perft 6' to search up to depth 6*OnePly
instead of the old 'perft depth 6'.
It is more in line to what other engines do. Also a bit
of cleanup while there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When false (common case) we avoid to update checkers
bitboard that although not so costly slows down a bit
this very hot and critical path.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Try an internal iterative deepening not only when we don't
have a TT move but also if search depth is more then 4*OnePly
higher then TT move depth.
On some tests it seems that in around 20% of cases ttMove changes !
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is now no more needed to know dc candidates
inside MovePicker, so avoid calculating there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Patch from Joona with extension to benchmark and inclusion
of Depth(0) moves generation by me.
Note that to test also qsearch and in particulary checks
generations a change in the end condition is needed.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Small code cleanup and a bit faster too.
The only functional change is that in extension
in pv node we extend promotions and not only captures
when condition met.
This is practically an undetectable change and has
no impact on strenght.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Even if SEE is negative there is always a good possibility
that TT move is a cut move anyway. For instance a lot of
BXN exchanges that have negative SEE can very easily be
good exchanges.
A nice side effect is a bit reduced frequency of
see_sign() calls.
After 643 games at 1+0
Mod vs Orig +174 =327 -142 52.49% 337.5/643 +17 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Only in less then 2% of cases we have a new sp->bestValue,
so check before to lock and save a costly locking
most of the times.
Patch suggested by Joona.
No functional search.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use futility pruning also in split points.
Do not use history pruning in split points when
getting mated.
After 1000 games on Joona QUAD
Orig - Mod: 496 - 504
Added an optimization to avoid a costly lock in the
very common case that sp->futilityValue <= sp->bestValue.
A test on a dual CPU shows only 114 hits on 23196 events,
so avoid a lock in all the other cases.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
If after the first tried 2 + int(depth) moves we still
have no any move that takes us out of a mate then do
not prune the following move, it is more important to
escape mate then speed up search.
This fixes an odd behaviour regarding mates, as example
the following diagram is a mate in 4, not in 3 as bogusly
reported before this patch.
1B2n3/8/2R5/5p2/3kp1n1/4p3/B3K3/8 w - - bm #4;
The performance impact should be minimal, the increment
in searched nodes is less then 0.1 %%
Idea and patch by Joona
After 999 games at 1+0
Mod vs Orig +193 =604 -202 -3 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In this case we call evaluate() being in check and this
is not allowed.
Bug found testing with reduced PLY_MAX value as suggested
by Miguel A. Ballicora on talkchess.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When pondering InfiniteSearch == false but myTime == 0 so that
NodesBetweenPolls = 1000 instead of the standard.
The patch fixes the bug and is more robust because checks
directly myTime for a non-zero value, without relying on
an indirect test (InfiniteSearch in this case).
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of checking the time every 100 nodes in the last second,
and every 1000 nodes in the last five seconds, Stockfish now checks
every 1000 nodes in the last second and every 5000 nodes in the last
five seconds. This was tested in 1036 games at a time control of
40 moves/10 seconds, and no losses on time occured.
Also fixed a bug pointed out by Marco: In infinite mode, myTime
is actually 0, but of course we still don't want to check the time
more frequently than the standard once per 30000 nodes in this
case.
In RootMoveList c'tor we allocate a search stack and then
call directly qsearch.
There is called init_node() that clears all the fields of the search
stack array that refers to current ply but not the the killer moves.
The killer moves cleared correspond to ply+2.
In id_loop() this is not a problem because killer moves of
corresponding ply are cleared anyway few instructions later,
but in RootMoveList c'tor we leave them uninitialized.
This patch fixes this very old bug. It comes direclty
from Glaurung age.
Bug spotted by Valgrind.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In particular don't use an array of StateInfo, this
avoids a possible overflow and is in any case redundant.
Also pass as argument the pv[] array size to avoid a second
possible overflow on this one.
Fix suggested by Joona.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
