Marco Costalba [Tue, 10 Nov 2009 07:55:52 +0000 (08:55 +0100)]
Small update to pop_1st_bit()
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>
Marco Costalba [Sat, 7 Nov 2009 21:21:50 +0000 (22:21 +0100)]
Define Score as an enum
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>
Marco Costalba [Thu, 5 Nov 2009 13:40:51 +0000 (14:40 +0100)]
Enable PH_TT_MOVES during evasion generation
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>
Marco Costalba [Mon, 2 Nov 2009 17:27:26 +0000 (18:27 +0100)]
Generate pseudo-legal moves in generate_evasions()
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>
Marco Costalba [Sun, 1 Nov 2009 21:09:53 +0000 (22:09 +0100)]
Remove SEE optimizations
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>
Marco Costalba [Sat, 31 Oct 2009 09:51:04 +0000 (10:51 +0100)]
Reorder evasions
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>
Marco Costalba [Sat, 31 Oct 2009 10:16:40 +0000 (11:16 +0100)]
Another see() shortcut
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>
Marco Costalba [Sun, 1 Nov 2009 16:19:04 +0000 (17:19 +0100)]
Remove castling moves in check generation
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>
Marco Costalba [Tue, 20 Oct 2009 15:14:57 +0000 (16:14 +0100)]
Don't prune TT move in qsearch even if SEE < 0
Even if SEE is negative there is always a good possibility
that TT move is a cut move anyway. For instance a lot of
BXN exchanges that have negative SEE can very easily be
good exchanges.
A nice side effect is a bit reduced frequency of
see_sign() calls.
After 643 games at 1+0
Mod vs Orig +174 =327 -142 52.49% 337.5/643 +17 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba [Tue, 20 Oct 2009 10:38:20 +0000 (11:38 +0100)]
Pick best moves one per cycle instead of sorting
When the move list is very small, like captures normally
are, it is faster to pick the best move with a linear
scan, one per cycle.
This has the added advantage that the picked capture move is
very possibly a cut-off move, so that other searches are
avoided. For non-captures it is still faster to sort in
advance.
Because scan-and-pick alghortim is not stable, node count
has changed.
After 885 games at 1+0
Mod vs Orig +196 =510 -179 50.96% 451.0/885
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Joona Kiiski [Sat, 17 Oct 2009 05:42:42 +0000 (08:42 +0300)]
Similarize pruning code in search() and sp_search()
Use futility pruning also in split points.
Do not use history pruning in split points when
getting mated.
After 1000 games on Joona QUAD
Orig - Mod: 496 - 504
Added an optimization to avoid a costly lock in the
very common case that sp->futilityValue <= sp->bestValue.
A test on a dual CPU shows only 114 hits on 23196 events,
so avoid a lock in all the other cases.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba [Wed, 14 Oct 2009 08:18:16 +0000 (09:18 +0100)]
Do not prune the move if we are still under mate
If after the first tried 2 + int(depth) moves we still
have no any move that takes us out of a mate then do
not prune the following move, it is more important to
escape mate then speed up search.
This fixes an odd behaviour regarding mates, as example
the following diagram is a mate in 4, not in 3 as bogusly
reported before this patch.
1B2n3/8/2R5/5p2/3kp1n1/4p3/B3K3/8 w - - bm #4;
The performance impact should be minimal, the increment
in searched nodes is less then 0.1 %%
Idea and patch by Joona
After 999 games at 1+0
Mod vs Orig +193 =604 -202 -3 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Tord Romstad [Thu, 15 Oct 2009 10:39:55 +0000 (12:39 +0200)]
Minor improvement in eval of unstoppable pawns promoting one ply apart.
Marco's new code for evaluating two unstoppable passed pawns where
one pawn promotes a single ply before the other tried to detect
cases where the pawn that promotes first could immediately capture
the pawn that promotes a ply later, but didn't work in cases where
the two pawns are on the same file. An example of this is the
following position:
8/8/3K4/2P5/2p5/3k4/8/8 w - -
With the new code, such positions are handled correctly.
Marco Costalba [Mon, 12 Oct 2009 06:38:21 +0000 (08:38 +0200)]
Add a new rule on promoting pawns in evaluate_passed_pawns()
Add a rule about the situation when one side queens exactly
one ply before the other. To avoid difficult (but luckly rare)
cases we only handle the case of free paths to queen for
both sides.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba [Sun, 11 Oct 2009 16:30:35 +0000 (18:30 +0200)]
Fix x-ray attack from behind in evaluate_passed_pawns()
Fix a condition for x-ray attack of a queen or
a rook behind a pawn of us. Previous condition does
not check if the enemy slider behind our pawn is
really attacking the pawn.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba [Sun, 11 Oct 2009 08:35:41 +0000 (10:35 +0200)]
Revert "Use std::stable_sort() instead of std::sort()"
Unfortunatly std::stable_sort() implementation in gcc is
horrendously slow. We have a big performance regression on
Linux systems (-20% !)
So revert the commit and wait to fix the issue in a different
way, perhaps with an our home grown sorting, that should be
comparable in speed with std::sort()
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba [Sat, 10 Oct 2009 14:29:43 +0000 (15:29 +0100)]
Use std::stable_sort() instead of std::sort()
Standard does not mandate std::sort() to be stable, so we
can have, and actually do have different node count on
different platforms.
So use the platform independent std::stable_sort() and gain
same functionality on any platform (Windows, Unix, Mac OS)
and with any compiler (MSVC, gcc or Intel C++).
This sort is teoretically slower, but profiling shows only a very
minimal drop in performance, probably due to the fact that
the set to sort is very small, mainly only captures and with
less frequency non-captures, anyhow we are talking of 30-40 moves
in the worst average case. Sorting alghortims are build to work on
thousands or even milions of elements. With such small sets
performance difference seems not noticable.
After 999 games at 1+0
Mod vs Orig +234 =523 -242 -3 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba [Sat, 10 Oct 2009 08:48:02 +0000 (09:48 +0100)]
Fix pieceList initialization in Position::clear()
We want piece list to be terminated with SQ_NONE.
This happens with all the pieces but the pawns that
being 8 make the inner loop exit just before writing
the SQ_NONE value at the tail of the list.
This bug was hidden because currently we don't use
piece list to scan pawns, but this will change in the
future and in any case an initialization should be done
correctly for the whole array to avoid subtle bugs in
the future.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba [Thu, 8 Oct 2009 08:09:19 +0000 (09:09 +0100)]
Fix the polling frequency when pondering
When pondering InfiniteSearch == false but myTime == 0 so that
NodesBetweenPolls = 1000 instead of the standard.
The patch fixes the bug and is more robust because checks
directly myTime for a non-zero value, without relying on
an indirect test (InfiniteSearch in this case).
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Tord Romstad [Thu, 8 Oct 2009 06:55:25 +0000 (08:55 +0200)]
Use slightly lower polling frequency in the last few seconds.
Instead of checking the time every 100 nodes in the last second,
and every 1000 nodes in the last five seconds, Stockfish now checks
every 1000 nodes in the last second and every 5000 nodes in the last
five seconds. This was tested in 1036 games at a time control of
40 moves/10 seconds, and no losses on time occured.
Also fixed a bug pointed out by Marco: In infinite mode, myTime
is actually 0, but of course we still don't want to check the time
more frequently than the standard once per 30000 nodes in this
case.
projects / stockfish / log