Move the code to the caller and also move mob_area
computation out of evaluate_pieces(). It is more clear
the code flow and it is also faster.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When false (common case) we avoid to update checkers
bitboard that although not so costly slows down a bit
this very hot and critical path.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Avoid a 64 bit load using a pointer. It saves a couple of push/pop
instructions so advantage is only theorical, but anyway we use
pop_1st_bit() as a reference implementation for 32 bit systems so
we keep it more for documentation purposes then for other reasons.
Idea of pointer is of Eric Mullins.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It will be overwritten anyway.
Also other little small touches that seem to increase
speed more then the whole enum Score patch series :-(
Optimization is really a black art.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Increases performance because now we use one integer
for both midgame and endgame scores.
Unfortunatly the latest patches seem to have reduced a bit
the speed so at the end we are more or less at the same
performance level of the beginning. But this patch series
introduced also some code cleanup so it is the main reason
we commit anyway.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of MgPieceSquareTable[16][64] and EgPieceSquareTable[16][64]
This allows to fetch mg and eg values from adjacent words in memory.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Save mid and end game scores in an union so to
operate on both values in one instruction.
This patch just introduces the infrastructure and changes
EvalInfo to use a single Score value instead of mgValue
and egValue.
Speed is more or less the same because we still don't use
unified midgame-endgame tables where the single assignment
optimization can prove effective.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Try an internal iterative deepening not only when we don't
have a TT move but also if search depth is more then 4*OnePly
higher then TT move depth.
On some tests it seems that in around 20% of cases ttMove changes !
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Also remove some fallback templates that prevent a
compile error in case the user runs 'make icc-profile-popcnt'
from a non supported machine.
We want to loudly fail in that case instead of silently
fallback in a non-popcount compilation.
Updated documentation too.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Variable 'f' in 'for' loop scope hides same named
one in outer scope.
Of curse no functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Thanks to Eric Mullins we have now endian friendly
pop_1st_bit() and also is removed the need to use
-fno-strict-aliasing compiler option with GCC.
Speed is almost as fast, very small difference if any in
perft test, so I assume almost no difference in real games.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This allow us to avoid the generation of the
evasion moves if we already have a TT move, and
in case we have a cut-off we skip evasion generation
altoghter.
Node count is changed because now we try TT move _before_
to generate evasions. The search on the TT move alters the
piece lists so that when we come back to generate evasions
we build the move list with a diferent order and this alters
the node count.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is now no more needed to know dc candidates
inside MovePicker, so avoid calculating there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Big cleanup and semplification of pawns evasions that
now are pseudo-legal as the remaining moves. This
allow us to remove a lot of tricky code.
Verified against perft: no functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This allow a big semplification in move generation
that will be committed with the next patch. And makes
handling of evasions similar to the other type of moves.
This patch plus the next seem to improve also on
the performance side because after 640 games to
verify there are no hidden regressions we are at +9 ELO
Verified with perft no functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Generate captures of checking piece and blocking
evasions in one go.
Also reduce of one indentation level early returning
when we have a double check.
Verified with perft no functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Don't seem to help, perhaps because we
return an approximate SEE score instead of the
real negative score so that we have some bad capture
or evasion sub-optimal ordering that compensates
the speed up.
Anyhow after 999 games at 1+0
Mod vs Orig +240 =514 -245 -2 ELO
So almost no harm to remove and make the code simpler.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Always try ttMove as first. Then try good captures ordered
by MVV/LVA, then non-captures if destination square is not
under attack, ordered by history value, and at the end
bad-captures and non-captures with a negative SEE. This
last group is ordered by the SEE score.
After 999 games at 1+0
Mod vs Orig +254 =546 -199 +19 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Because we only generate legal moves we can assume
a king cannot be recaptured, so we can safely return
immediately with the captured piece score. If the move
turns out to be illegal it will be pruned anyhow,
independently from SEE value. This gives a good speed up
especially now that we SEE-test all the evasions that
are always legal and very often are king moves.
Another optimization catches almost 15% of cases, unfortunatly
we have already calculated the very expensive attacks, so
benefits are not so big anyway.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This patch cuts 30% of SEE calculations, as a drawback
a returned negative value is no more always correct if
a shortcut is found.
This could impact move order when based on negative see
score as example bad captures and evasions.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Check generation is used only in qsearch and
only at Depth(0), castling moves that give check
are very rare overall and even almost not exsistent
at Depth(0).
So retire this almost never used code that adds
a small but consistent slow down in the normal path.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
