Skip to content

Commit

Permalink
Basis implementation of using main and capture history for scoring th…
Browse files Browse the repository at this point in the history
…e different possible moves (no functional changes but slower). Bench: 4881443
  • Loading branch information
locutus2 committed Apr 20, 2020
1 parent 221893b commit 82958c9
Show file tree
Hide file tree
Showing 2 changed files with 21 additions and 1 deletion.
20 changes: 19 additions & 1 deletion src/evaluate.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -257,9 +257,11 @@ namespace {
constexpr Bitboard OutpostRanks = (Us == WHITE ? Rank4BB | Rank5BB | Rank6BB
: Rank5BB | Rank4BB | Rank3BB);
const Square* pl = pos.squares<Pt>(Us);
constexpr Piece movedPiece = make_piece(Us, Pt);

Bitboard b, bb;
Score score = SCORE_ZERO;
Thread *thisThread = pos.this_thread();

attackedBy[Us][Pt] = 0;

Expand All @@ -284,10 +286,26 @@ namespace {
kingAttacksCount[Us] += popcount(b & attackedBy[Them][KING]);
}

int mob = popcount(b & mobilityArea[Us]);
bb = b & mobilityArea[Us];
int mob = popcount(bb);

mobility[Us] += MobilityBonus[Pt - 2][mob];

volatile int hist = -std::max(thisThread->mainHistory.divisor, thisThread->captureHistory.divisor);
while (bb)
{
Square to = pop_lsb(&bb);
Piece captured = pos.piece_on(to);
volatile int h;

if (captured)
h = thisThread->captureHistory[movedPiece][to][type_of(captured)];
else
h = thisThread->mainHistory[movedPiece][to];
hist = std::max(h, hist);
}
score += make_score(hist / 100000, hist / 100000);

if (Pt == BISHOP || Pt == KNIGHT)
{
// Bonus if piece is on an outpost square or can reach one
Expand Down
2 changes: 2 additions & 0 deletions src/movepick.h
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,8 @@ struct Stats : public std::array<Stats<T, D, Sizes...>, Size>
{
typedef Stats<T, D, Size, Sizes...> stats;

static constexpr int divisor = D;

void fill(const T& v) {

// For standard-layout 'this' points to first struct member
Expand Down

9 comments on commit 82958c9

@vondele
Copy link

Choose a reason for hiding this comment

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

note that in all likelihood the Elo loss at LTC can be obtained accurately from the Elo loss at STC. See comment here 31m059/Stockfish@a76d059

I think the LTC non-functional tests are a bit of a waste.

@vondele
Copy link

Choose a reason for hiding this comment

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

I've put the prio of the LTC test to -1. Change if you deem necessary.

@locutus2
Copy link
Owner Author

Choose a reason for hiding this comment

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

@vondele
Thats ok. Perhaps later if framework empty we can do the LTC too because above approximations are only for small speedups reliable. Here we have a massive 40 elo loss.

I have started my first try against this base implemenation here. Hopefully i or someone els gets here some out and we can fill the elo gap.
https://tests.stockfishchess.org/tests/view/5e9d74c7caaff5d60a50a872

@vondele
Copy link

Choose a reason for hiding this comment

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

good luck testing the ideas.

@vondele
Copy link

Choose a reason for hiding this comment

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

BTW, the logarithmic function should also cover the 40Elo case.

@vondele
Copy link

Choose a reason for hiding this comment

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

so, using the logarithmic model on https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-speedups

STC: 43.61 Elo -> slowdown x = 100 * (math.exp(43.61 / 210.366) - 1) -> 23.03% slowdown
predicted at LTC -> 142.987 * math.log(1+23.03/100) = 29.63 Elo

STC: https://tests.stockfishchess.org/tests/view/5e9d70e2caaff5d60a50a86b
LTC: https://tests.stockfishchess.org/tests/view/5e9d712acaaff5d60a50a86d

I guess that validates the 'elo-from-speedups' model.

@vondele
Copy link

Choose a reason for hiding this comment

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

btw, these elo difference is a significant overestimation of what the real cost of this is. The trick with volatile here is used a bit in an extreme way. The code will be much more efficient once h and hint are declared normal ints. What I intended would be to use just volatile once, not in a hot loop e.g.

volatile int switchOff = 1; // or 0
score += switchOff * make_score(hist / 100000, hist / 100000);

furthermore, the if in

            if (captured)
                h = thisThread->captureHistory[movedPiece][to][type_of(captured)];
            else
                h = thisThread->mainHistory[movedPiece][to];

can be presumably removed if we would manage to integrate thisThread->mainHistory into thisThread->captureHistory, which should be possible if thisThread->captureHistory[movedPiece][to][0] is still unused ? The latter might be even a useful way to represent stuff in master.

@vondele
Copy link

Choose a reason for hiding this comment

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

So, a first step attempt to make the base branch faster: https://tests.stockfishchess.org/tests/view/5e9fe5b16c9315ea7547beab
Probably ~< 20Elo at STC.

@locutus2
Copy link
Owner Author

Choose a reason for hiding this comment

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

@vondele
Thanks for this useful informations, I have already cleaned up my master from volatile for this experimental branch and started a short regression test to look how far we behind now.
https://tests.stockfishchess.org/tests/view/5ea001d26c9315ea7547bed8

Please sign in to comment.