Skip to content

Commit

Permalink
Optimize order of a few conditions in search
Browse files Browse the repository at this point in the history 
Also fix size of KingDanger array to reduce memory footprint.

Small speed up of around 0.5%

No functional change.
  • Loading branch information
@ajithcj @mcostalba
ajithcj authored and mcostalba committed Aug 31, 2016
1 parent 2731bba commit 5cffc03
Show file tree
Hide file tree
Showing 2 changed files with 5 additions and 5 deletions.
2 changes: 1 addition & 1 deletion src/evaluate.cpp
View file
Expand Up @@ -210,7 +210,7 @@ namespace {
// in KingDanger[]. Various little "meta-bonuses" measuring the strength
// of the enemy attack are added up into an integer, which is used as an
// index to KingDanger[].
Score KingDanger[512];
Score KingDanger[400];

// KingAttackWeights[PieceType] contains king attack weights by piece type
const int KingAttackWeights[PIECE_TYPE_NB] = { 0, 0, 7, 5, 4, 1 };
Expand Down
8 changes: 4 additions & 4 deletions src/search.cpp
View file
Expand Up @@ -725,8 +725,8 @@ namespace {
// Step 6. Razoring (skipped when in check)
if ( !PvNode
&& depth < 4 * ONE_PLY
&& eval + razor_margin[depth / ONE_PLY] <= alpha
&& ttMove == MOVE_NONE)
&& ttMove == MOVE_NONE
&& eval + razor_margin[depth / ONE_PLY] <= alpha)
{
if ( depth <= ONE_PLY
&& eval + razor_margin[3 * ONE_PLY] <= alpha)
Expand Down Expand Up @@ -924,8 +924,8 @@ namespace {
&& !captureOrPromotion
&& !inCheck
&& !givesCheck
&& !pos.advanced_pawn_push(move)
&& bestValue > VALUE_MATED_IN_MAX_PLY)
&& bestValue > VALUE_MATED_IN_MAX_PLY
&& !pos.advanced_pawn_push(move))
{
// Move count based pruning
if (moveCountPruning)
Expand Down

5 comments on commit 5cffc03

@syzygy1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some doubt about the second condition, because bestValue > VALUE_MATED_IN_MAX_PLY should be quite rare unless the game is over anyway and speed stops to matter...

@ajithcj
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@syzygy1 bestValue > VALUE_MATED_IN_MAX_PLY is almost always true(not rare like you say). VALUE_MATED_IN_MAX_PLY is a negative value.

VALUE_MATE_IN_MAX_PLY = VALUE_MATE - 2 * MAX_PLY,
VALUE_MATED_IN_MAX_PLY = -VALUE_MATE + 2 * MAX_PLY,

@ajithcj
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the result when I do a
dbg_hit_on(bestValue > VALUE_MATED_IN_MAX_PLY);

Total 143538024 Hits 127883669 hit rate (%) 89

@syzygy1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are absolutely right that bestValue > VALUE_MATED_IN_MAX_PLY is the common case. I confused it with VALUE_MATE_IN_MAX_PLY and was not thinking.

However, I kind of made two mistakes that cancel each other out.
If the condition is almost always true, it might be faster to first test the more expensive condition which might more often be false. Since the conditions are chained together with && it makes sense to first test conditions that are more often false.

On the other hand, the bestValue test is really cheap. So if this has tested faster...

Btw, I am a bit surprised to see the tMove == MOVE_NONE condition for razoring. Of course that was already there and I'm sure it has been tested, but it seems funny to prune more just because we don't have a tt move.

@ajithcj
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you are right, that it might be faster to test the more expensive condition since its true most of the time. Thats why I measured how frequently it is true. I expected it be around 99% of the time. But it was only 89%. So I guess we have to rely on the bench measurements which did give a small speedup for me and lucas.
Regarding the razoring condition, I too don't know the history behind why it was added. maybe there is a reason.

Please sign in to comment.