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>
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 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>
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>
Pass value as an argument instead or recalculating it.
Altough call is cheap this is a very hot path so with
this patch total time spent for move_is_capture() is almost
halved.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This is somewhat taken from Stockfish 1.2 Default,
only the razoring thresold are updated, not the
razoring depth.
At the end razoring is a bit more aggressive. Results
seems slightly positive.
After 999 games +239 =536 -224 Elo +5
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Optimistic razoring settings. It is stronger with
most engines but weaker with someones.
The default is instead more solid and uniform with all
the opponents.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Add also the possibility to razor at ply one.
It is disable dby default but it seems stronger
against Stockfish itself. It is still not clear if
is stronger against other engines. By now leave
disabled.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Less prune at the bottom and at the middle, a bit more
at the top.
After 747 games: +215 =345 -187 +13 elo
Also introduced a vector of margins, now that start to be a lot
it is a more flexible solution.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Because razoring verification after qsearch() cuts more
then 40% of candidates, do not waste a costly qsearch for
nodes at depth one that will be probably discarded anyway
by futility.
Also tight razoring conditions to keep dangerous false
negatives below 0,05%. Still not clear if it is enough.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Bug fix merged from Glaurung 2.2 for search_pv()
Added the same fix also to sp_search_pv() where
was missing.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use a margin to compare with beta so that positions
that after the verifying qsearch have gained a lot of points
are not discarded just becasue not above beta.
Also remove the second condition on depth <= OnePly, it
was too risky and added only a 2% more of pruned nodes.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Fix the logic in search_pv and sp_search_pv
An additional issue to consider is that a castle move
is not a capture but destination square is not empty.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of number of searched nodes use the number of
opponent beta-cutoff occurred under the move subtree.
After 570 games 1+0 we have: +150 =288 -132 (+11 ELO)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When a null move fails low due to a capture, try
to detect if without the capture we are above beta,
in this case there is a good possibility this is
a cut-node and the capture is just a null move
artifact due to side to move change. So if we still
don't have a TT move it's a good time to start an IID.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Null move can fail low because of a capture artifact due
to the side to move change. Try to detect this condition
and fail high instead.
This pruning is very powerful, around 7% of nodes, but is
still experimental so is disabled by default.
Set UseNullCapturePruning to true to enable.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Strength increase was due to an hidden bug introduced
by the patch, namely the time per move to /30 instead
of /40 (see previous patch).
After testing this feature do not add any substantial
increase so is removed.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
