We implicitly considered the minimum depth stored in TT
to be Depth(0), but because we store values in TT also in
qsearch() where depth is < 0, we need to use a negative
number as minimum depth.
Bug spotted by Joona Kiiski.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
I have just made a new rule that no modification
that increases pruning is allowed if after 1000 games
ELO is not increased by at least 10 point (was +5 in this case)
Yes, I like this kind of nosense rules :-)
Previous setup didn't change anything
After 996 games 1+0: +267 -261 =468 +2 ELO
Now with this new setup we have
After 999 games 1+0: +277 -245 =477 +11 ELO
Seems reasonable...
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Reduce of two plies near the leafs and when we still
have enough depth to go so to limit horizon effects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Try to save space and use the minimum size
possible.
In particular restore int16_t for values and int8_t
for halfOpenFiles.
Use int16_t for storm values insted of int and also
instead of original buggy and too small int8_t.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Note that some pawns and material info has been switched
to int from int8_t.
This is a waste of space but it is not clear if we have a
faster or slower code (or nothing changed), some test should be
needed.
Few warnings still are alive.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
These fields are defined as int8_t but values bigger
then 127 are stored there so that we silently overflow.
Fix bringing up all the fields to a sane int type. This
will increase memory usage, but apart from being safe, it is
not clear if code is slower or faster. Test is needed.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It does not seem to clearly improve things and
in any case is disabled by default, so retire for now.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Prune more moves after a null search because of
a lower beta limit then in main search.
In test positions reduces the searched nodes of 30% !!!!
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It seems that these compilers do not like inline functions
that call a template when template definition is not in scope.
So move functions from header to in *.cpp file
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Quickly filter out some calls to sliders attacks
when we already know that will fail for sure.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Rewritten hidden_checkers() to avoid calling
sliders attacks functions but just a much
faster squares_between()
Also a good code semplification.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of copying all, copy only the fields that
are updated incrementally, not the ones that are
recalcuated form scratch anyway.
This reduces copy overhead of 30%.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is slower the previous uglier but faster code.
So completely restore old one for now :-(
Just leave in the rework of status backup/restore in do_move().
We will cherry pick bits of previous work once we are sure
we have fixed the performance regression.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Another optimization that let us remove another half
of find_hidden_checks(them, DcCandidates) calls.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This let us to calculate only pinners when we now that
dc candidates are not possible.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use a more strict condition to check if we have captured
an opponent pinner or hidden checker.
With this patch the occurrence of checkerCaptured == true are
reduced of 50%.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In do_move() use previous pinned bitboards values to compute
the new one after the move. In particulary we end up with the
same bitboards in most cases. So detect these cases and just
keep the old values.
This should speedup a lot this slow computation in a very hot
path so that we can use this important info everywhere in the
code at very cheap cost.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
There was one occurence when the StateInfo variable went
out of scope before the corresponding Position object.
This yelds to a crash. Bug was not hit before because occurs
only when using an UCI interface and not the usual benchmark.
The fix consists in copying internally the content of the
about to stale StateInfo.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Remove pinned pieces from attacks when calculating
SEE value.
Algorithm is not perfect, there should be no false
positives, but can happen that we miss to remove a
pinned piece. Currently we don't cach 100% of cases,
but is a tradeoff between speed and accuracy. In any
case we stay on the safe side, so we remove an attacker
when we are sure it is pinned.
About only 0,5% of cases are affected by this patch, not
a lot given the hard work: this is a difficult patch!
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of copy the old state in the new one, copy only
fields that will be updated incrementally, not the ones
that will be recalculcated anyway.
This let us copy 13 bytes instead of 28 for each do_move()
call.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Probably is slightly slow, but code is surely better
in this way. We will optimize later for speed.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We don't backup anymore but use the renamed StateInfo
argument passed in do_move() to store the new position
state when doing a move.
Backup is now just revert to previous StateInfo that we know
because we store a pointer to it.
Note that now backing store is up to the caller, Position is
stateless in that regard, state is accessed through a pointer.
This patch will let us remove all the backup/restore copying,
just a pointer switch is now necessary.
Note that do_null_move() still uses StateInfo as backup.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We store it now in the same UndoInfo struct as 'previous'
field, so when doing a move we also know where to get
the previous info when undoing the back the move.
This is needed for future patches and is a nice cleanup anyway.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Also templetize compute_value() can be simpler now that
the above is templetized too.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
