If singular extension search was succesful in the past then
skip another the SE search and extend of one ply.
Another way to mitigate the cost of SE at the price of
some more spurious extension, but on 90% of cases info
is correct.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Renamed in OptimumSearchTime and MaximumSearchTime,
should be more clear now.
Suggested by Joona.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of ss->currentMove. It is more consistent and
clear to understand.
Remark by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
To compensate for the extra work skip singular
searches deemed to fail because excluded node
failed high already in the past.
After 1200 games at 1+0
Mod vs Orig +387 =1274 -339 (+8 ELO)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Let be explicit about what this functions do, and
we save some code lines too.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
After we set ss->threatMove we could go under a IID step that
resets SearchStack ss and so also ss->threatMove.
When later we use that field in futility pruning we have this
set to MOVE_NONE !
The fix is to use a local variable and add threatMove to SplitPoint
to pass this move to slaves.
Spotted by Ralph Stoesser, fix suggested by Richard Vida.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
These functions have little to do with TranspositionTable
class and more with the search and in particular with the PV
handling. So move them where they belong.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
So to maximize the possibility to avoid to recalculate it
in the future. A small speed-up of 0.8%
Idea by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
The seocond check is no more needed now and
anyhow is wrong to overwrite a TT entry if
present.
Spotted by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
KILLER_MAX in search.h is quite pointless, because
we already hardcode this to 2 in MovePicker anyway.
By hard-coding this to 2 we can keep code simpler.
No functional change
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Almost no change so commit because is a pruning
reduction patch.
After 1088 games at 1'+0 with QUAD
Mod vs Orig +178 =727 -183 (-2 ELO)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We don't need to pass side_to_move because we can get
it directly from the position object.
Note that in benchmark we always used to pass '0' and
it was a bug, but with no effect because was used only
in time[] and increment[], set always to 0 for both
colors.
Also additional small cleanup while there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Currently starting from depth 12*OnePly on we have a verification
search deeper then the null search.
Note that, although reduction is R we start from one ply less then
null search, so actually we reach a depth that is OnePly shallower
then null search.
After 1130 games at 1'+0 on QUAD
Mod vs Orig +202 =756 -172 +9 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Unfortunatly the source of this issue is not in the
different handling of log(0) illegal value.
No functional change on MSVC.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It happens that when d == 0 we calculate:
log(double(0 * 0) / 2)
Unfortunately, log(0) is "illegal" and can generate either a
floating point exception or return a nonsense "huge" value
depending on the platform.
This fixs in the proper way the GCC/ICC rounding difference,
bug was from our side, not in the intel compiler.
Also fixed some few other warnings.
Bug spotted by Richard Lloyd.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Extract PV info from TT instead of using
a set of arrays. This is almost equivalent
except for cases when TT is full and the PV entry
is overwritten, but this is very rare.
(Almost) No functional change
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Search ply and game ply are rwo different things !
Revert bogus commit.
No functional change on bench, but it changes in real games
when engine sends all the moves up to current one.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
If we are there it means we already had that info stored in TT,
so we don't need to overwrite with the same content !
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is more clear and should be a bit faster too.
Reverted also previous optimization patch because
seems do not increase actual speed.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Almost no change, but it is in sync with what we do in search
and in any case the ELO difference is very small (because the
events when the intermediate research triggers are very rare),
too small to be measured, we just verify we don't have any
unexpected regressions.
After 802 games at 1+0 full QUAD
Mod vs Orig +114 =581 -107 +3 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
If we have pruned one capture due to its final value
we can prune also following ones because captures are
MVV ordered.
Also avoid a compare when not in PV because in that
case is always false.
No functional change.
Get it from the position instead.
A good semplification of function calling and a speedup too.
No functional change also with faked split.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
