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>
The one in evaluate_passed_pawns() is just a micro
optimization, the other in evaluate_unstoppable_pawns()
is indeed a fix, although almost unmeasurable in real
games.
Bugs report and fixes by Marek Kwiatkowski
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Broken by recent patch. Also better document what's
happening there.
Verified to restore original behaviour.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Square and piece colors are two different things,
so use different types to avoid misunderstandings.
Suggested by Tord.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Less invasive then previous patches, but still a good
enhancement.
Also some indulge on STL algorithms :-)
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Complete rewrite the function and extend compatibility
also to X-FEN notation for Chess960.
We are now able to read standard FEN, Shredder-FEN and X-FEN.
No functional change.
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>
Improvement is easily in error bar and there is
some added complexity making future changes more
difficult.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Because not all backward pawns are the same ;-) if the
blocking enemy pawn is near then our pawn is more backward
than another whose enemy pawn is far away so that can advance
for some sqaures.
After 2925 games at 30"+0 on my QUAD
Mod vs Orig +602 =1745 -578 +3 ELO
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>
It is more clear and also more correct because we
consider enemy pawns only in fornt of us and not just
on our file.
Very small functional change, almost not measurable, but
keep the patch for documenting purposes.
Spotted by Marek Kwiatkowski.
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>
Considering only VALUE_TYPE_EXACT nodes is too
restrictive and has a number of side-effects, most
notably the truncation of PV line after a fail high
at root.
Note that in this way we are no more guaranteed that
PV line is built up with PV nodes only, because
it could happen that a side search overwrites with a
cut-off move a PV node and this cut-off move ends up
in PV.
Change should be almost not measurable, perhaps with
ponder on we could have some beneficial effect.
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>
After the previous patch, it's impossible to build
anything else than x86 32-bit binary!
So revert.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Tested with Orig set at f5ef5632f so to evaluate
direct gain against 1.8
After 3239 games at 10"+0.1
Mod vs Orig +701 =1906 -632 +7 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>
Also renamed history access value in something more
in line with the meaning.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It seems there is absolutely no difference in using gains.
After 7025 games at 5"+0
Mod vs Orig +1903 =3236 -1886 (+1 ELO)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When first condition is met then second one is
always true.
Spotted by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This should allow to skip overwritten nodes because
only in PV we store in TT with VALUE_TYPE_EXACT flag.
Test result for the whole series is:
After 3627 games at 5"
Mod vs Orig +1037 =1605 -985 +5 ELO
After 1311 games at 1'+0"
Mod vs Orig +234 =850 -227 +2 ELO
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>
Due to rounding errors in apply_weight() where we divide
by 0x100 it is not possible to keep some functionality.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
A pawn is unstoppable also if enemy king can reach it
but path to queening is protected.
Original idea by Ralph Stoesser fixed by me.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Many killers moves, around 40%, are not legal, so
skip earlier in this case.
Some Movepicker c'tor cleanup while there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This code is platform specific and has nothing to
do with TT class, so move to misc.cpp
This patch is a prerequisite to use extend prefetch use
also to other hash tables apart from Transposition Table.
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>
In statement:
*tte = TTEntry(posKey32, v, t, d, m, generation, statV, kingD);
We first create a TTEntry, then we copy the temporary entry to
its final destination in *tte then we discard the TTEntry.
Instead of this assign the fields directly to the destination TTEntry.
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>
And remove from main do_move() flow. Just a small speedup
because we avoid two branches in the common case.
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>
Marco Costalba