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>
This is the best place because when we split we do a
copy of the position and also threadID, once set in a
given position, never changes anymore.
Forbid use of Position's default and copy c'tor to avoid
nasty bugs in case a position is created without explicitly
setting the threadID.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Do it once at the beginning becuase they are always reset
after use in the calling place where are set.
No functional change also with faked split.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Also renamed allowNullmove in skipNullMove to reverse
the logic so that the field is initialized to 0 (false)
instead of 1 (true).
No functional change also with faked split.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use log() instead because we are not in speed
critical paths.
Also a bit of renaming and code shuffle while there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Has been remained the same from ages also with the FIXME.
Retire for now and rearrange the conditions order for
maximum performance.
Also a small touch at null zugzwang verification.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is more up to the point. Also small speedup
due to checking for threat move before calling
the function. This saves more then 90% of function calls.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In 44% of cases we call search() just to call
qsearch() one moment later, avoid this double dispatch.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
And avoid a redundant one passed as argument in
search calls.
Also renamed gamePly in ply to better clarify this
is used as search ply and is set to zero at the
beginning of the search.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In RootMoveList c'tor we call qsearch() with
ply == 1 but SearchStack at 0.
We never noticed before because in qsearch we don't access
previous's ply SearchStack, otherwise we would have got
a nice crash ;-)
This bug is a fall down of previous patch.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use a pointer to current SearchStack to avoid ss[ply]
address calculation.
Gives 1% speedup on Intel compiler
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In case tte->depth() is far lower the current depth
and we are in a PV node.
Almost 45% of researches give a different ttMove !
After 999 games at 1+0
Mod vs Orig +174 =694 -131 +15 ELO !!!!!!!
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Do not search immediately at full depth, but try a second
chance at lower depth. This is a feature that should scale
well because become important at high depths where we have
big reductions and also big savings in avoiding a costly
full depth search.
After 942 games at 1+0
Mod vs Orig +158 =645 -139 +7 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It does not seem to increase anything even with a QUAD,
so revert.
After 1000 games with a QUAD
Mod - Orig: 500 - 497 (+1 elo)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
No gain in the worst case of 2 threads, but also no
loss and good potential for QUAD or OCTAL machines.
After 922 games at 1+0 with 2 threads
Mod vs Orig +143 =533 -143 +0 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
