Devlog of Leorik

[Mike Sherwin]

But this little case-study gives me new ideas for the eval, now!

So one of the ideas is that Mike mentioned backward pawns and I had to look up what that is. Wikipedia says: "In chess, a backward pawn is a pawn that is behind all pawns of the same color on the adjacent files and cannot be safely advanced."

My implementation of this with bitboards looks like this:

Code: Select all

        public static ulong GetBackwardWhitePawns(BoardState board)
        {
            ulong blackPawns = board.Black & board.Pawns;
            ulong whitePawns = board.White & board.Pawns;
            ulong blackAttacks = LeftDown(blackPawns) | RightDown(blackPawns);
            ulong whiteAttacks = LeftUp(whitePawns) | RightUp(whitePawns);
            //white pawns behind all friendly adjacent pawns whose up-square is attacked by black pawns are backward
            return Down(Up(whitePawns) & blackAttacks & ~FillUp(whiteAttacks));
        }

[fen]rn2k2r/1pp1nb2/3p1pqp/2b1p1p1/p1P1P1P1/P1NP2Q1/1P3PP1/R1B1KBNR w KQkq - 0 1[/fen]

Code: Select all

BackwardPawns:
- - - - - - - -
- - - - - - - -
- - - - - B - B
- - - - - - - -
- - - - - - - -
- - - W - - - -
- W - - - - - -
- - - - - - - -

This is what the example where I found this position also identifies as backward pawns. I tested a few more positions from the internet and they all seemed correctly identified so hopefully my implementation is correct. I assume for 'backwardness' it doesn't matter if the target square is actually empty or not?

Then I changed my pawn structure code to give a -5 cp malus to all backward pawns. After retuning the PSQTs this gave better MSE than -4 or -6 and so I stuck with it. I made a build and ran a selftest overnight:

Code: Select all

Score of Leorik 2.2.2 vs Leorik 2.2: 1689 - 1598 - 2416  [0.508] 5703
...      Leorik 2.2.2 playing White: 945 - 654 - 1253  [0.551] 2852
...      Leorik 2.2.2 playing Black: 744 - 944 - 1163  [0.465] 2851
...      White vs Black: 1889 - 1398 - 2416  [0.543] 5703
Elo difference: 5.5 +/- 6.8, LOS: 94.4 %, DrawRatio: 42.4 %

I used the GMIS tool I received from Günther to make sure that the thus extended pawn structure eval isn't significantly slower:

Code: Select all

 nr                           player    games  pts%      sumTime aveDep    aveTime
  1                     Leorik 2.2.2     5713  50.8  00:09:49:23  11.71  00:00:399
  2                       Leorik 2.2     5713  49.2  00:09:44:55  11.71  00:00:396

I usually don't get super excited about 5 Elo gains. Every change to the evaluation followed by re-tune could give +5 Elo in self-play just because you're lucky or something. So for now I pushed the changes into a branch instead of right into the master.

Not all backward pawns are equal. Backward pawns in the center are often worse. Backward pawns on a semi-open file are worse. Backward pawns restricted by an enemy pawn on adjacent file are worse.

And now that you have the backward pawns you also have outpost for your pieces.

Let's say the simplistic -5 is worth a positive change then +5.5 to +12.3 is very promising. Especially since -5 seems way to low imo. A knight on a good center outpost can be worth more than a rook. And considering the whole idea why a backward pawn is bad is just because the pawn is often simply lost which is -100.

[Modern Times]

30th July CCRL blitz update preview:

Code: Select all

CCRL Blitz Rating List - Custom engine selection
Computed on July 23, 2022 with Bayeselo based on 657'413 games
Tested by CCRL team, 2005-2022, http://ccrl.chessdom.com/ccrl/404/

Rank                 Engine                   Elo   +    -   Score  AvOp  Games
1 Leorik 2.2 64-bit                       2730  +22  -22  53.5%  -25.6   698
  Leorik 2.1 64-bit                       2615  +19  -19  51.5%  -11.3   990
  Leorik 2.0.2 64-bit                     2587  +19  -19  49.7%   +3.1   976
  Leorik 1.0 64-bit                       2193  +21  -21  47.6%  +16.2   819

And opponents

Code: Select all

Leorik 2.2 64-bit in CCRL Blitz, 2022-07-23
Leorik 2.2 64-bit is #153 with rating of 2730 Elo points (+22 -22),
based on 698 games: 277 wins, 228 losses and 193 draws
Score: 53.5%, Average opponent: −25.6, Draws: 27.7%

Pairwise results:
     Opponent                              Elo     Score                  LOS   Perf
 - Arminius 2018-12-23 64-bit              2782  35.5-64.5  (+20-49=31)    0.0   -47
 - Shield 2.1 64-bit                       2764  40.0-60.0  (+25-45=30)    0.7   -34
 - Dumb 1.9 64-bit                         2731  43.0-56.0  (+30-43=26)   48.1   -47
 - Supernova 2.4 64-bit                    2717  59.0-40.0  (+49-30=20)   82.6   +58
 - Blunder 8.0.0 64-bit                    2700  56.0-44.0  (+34-22=44)   97.1    +7
 - Movei 00.8.438                          2619  67.0-33.0  (+58-24=18)  100.0   +15
 - Pharaon 3.5.1                           2618  73.0-27.0  (+61-15=24)  100.0   +5

[lithander]

30th July CCRL blitz update preview:

Code: Select all

CCRL Blitz Rating List - Custom engine selection
Computed on July 23, 2022 with Bayeselo based on 657'413 games
Tested by CCRL team, 2005-2022, http://ccrl.chessdom.com/ccrl/404/

Rank                 Engine                   Elo   +    -   Score  AvOp  Games
1 Leorik 2.2 64-bit                       2730  +22  -22  53.5%  -25.6   698
  Leorik 2.1 64-bit                       2615  +19  -19  51.5%  -11.3   990
  Leorik 2.0.2 64-bit                     2587  +19  -19  49.7%   +3.1   976
  Leorik 1.0 64-bit                       2193  +21  -21  47.6%  +16.2   819

Wow, 2730 would be really an amazing! That's 150 Elo since Leorik 2 that can be mostly attributed to adding a simplistic pawn structure and mobility evaluation.

[lithander]

Let's say the simplistic -5 is worth a positive change then +5.5 to +12.3 is very promising.

What "5.5 +/- 6.8" means is that there's a 95% confidence that the "real" Elo is in the range of [-1.3..12.3] so if I rerun the test 100 times only in 5 runs I should see predicted Elo fall outside this range. But this result is not 100% guaranteed to be an improvement, especially not considering the variance introduced by playing on different computers against other engines or at different time controls.

Especially since -5 seems way to low imo.

I felt so too and have tried tuning on a bigger data-set where the best value for the backward pawn seemed to be -7 and it gave me +9.2 Elo on my AMD at 5s + 500ms but was a clear loss (-12 Elo) on 40/20 time controls on an Intel. And each test involved several thousand games, too.

But the main reason I won't commit to master are the other things you said about not all backward pawns being equal. So my result of this experiment is that one apparently can't assign a big flat malus for having a backward pawn. Whether it's really a disadvantage and by how much seems to depend on a lot of additional information that I don't have at my disposal in a pawn-structure only eval term.

The result I got from my tuner look like this:

Code: Select all

BackwardPawns - MG
    0,    0,    0,    0,    0,    0,    0,    0,
    0,    0,    0,    0,    0,    0,    0,    0,
    0,    0,    0,    0,    0,    0,    0,    0,
    6,   -4,    4,    1,   -5,    7,    1,    7,
   -3,   -4,  -12,  -11,   -2,   -6,   -6,    3,
   -1,   -4,   -6,   -8,   -2,   -3,  -15,    1,
   -8,   -4,   -1,   -8,  -11,   -3,   -2,    0,
    0,    0,    0,    0,    0,    0,    0,    0,

BackwardPawns - EG
    0,    0,    0,    0,    0,    0,    0,    0,
    0,    0,    0,    0,    0,    0,    0,    0,
    0,    0,    0,    0,    0,    0,    0,    0,
   -4,   -6,   -2,    6,    5,    0,   -3,   -4,
    3,   -3,   15,   14,    0,    8,   -4,    2,
   -3,   -3,    1,    7,   -7,   -3,    7,   -1,
    7,    2,   -7,   -6,   -4,   -6,   -5,    5,
    0,    0,    0,    0,    0,    0,    0,    0,

It's apparently more often bad than good but -5cp on average doesn't mean I should have a dumb line of code giving -5cp for every backward pawn it sees. Or at least that's what my gut is trying to tell me after seeing the above result! (By the same reason I don't consider doubled pawns...)

I think the reason why NNUE evals do so well is that they have the entire state of the board as an input and can work out these nuances and all the subtle rules you also describe automatically.

[lithander]

The original post resonates strongly with me. I've just had a few weeks vacation that I could have spent on a thousand things but instead I've invested my spare time mostly into making zero progress with Leorik. I tried dozens of things that seem to work for everyone else but for me nothing sticks. Now the sunk cost fallacy causes me to orbit my computer in ever shrinking intervals. I'm desperate to get *something* working so that it doesn't feel like I wasted a huge part of my vacation on nothing. My wife is losing patience with my "hobby" at inflationary speed and I can't blame her.

I think there needs to be a public health warning to not get involved with chess programming.

If you don't mind sharing, I'd be curious to know what you've tried that hasn't worked for you.

Don't want to hijack the thread and will reply in Leoriks Devlog instead...

I don't mind sharing, it's just that I'd rather share good news than bad ones. Version 2.2 released a months ago and it was mostly about improving the evaluation. So I thought for version 2.3 I should revisit the search. It's mostly the same as what I did in MinimalChess so not very sophisticated.

Things I tried:

• Using SEE to prune bad captures in QSearch. (maybe my implementation is too slow but it was just less nodes searched but not stronger)
• Using SEE to sort captures in normal search
• Using SEE to prune bad captures in frontier nodes
• Extending by 1 ply when being in check (and other simple extensions)
• Using float instead of integers to store the remaining depth, then try extensions like check-extensions with different non-integer values (half a ply etc)
• A history heuristic but not for good quiets but for bad captures. It predicted bad captures well enough but like with SEE I didn't manage to use the knowledge to my advantage.
• Making sure that no move is played twice (e.g. the PV move or the killer moves could come up again later if they are not causing a beta cutoff)
• Tried to improve my history heuristic in a bazillion ways. The most significant change was to make it use much more storage and not only use the current move as key but also the previous (counter move) and the one before that (follow up)...

When all this didn't work out I started to suspect that a few exotic choices I made *earlier* where to blame. Leorik does late move reductions in a somewhat peculiar way. I use a staged move generation: First the hash-move, than the captures, then killers... The remaining quiets are plenty and I pick a few based on the history value and play them first. When the history score is below average I decide that the remaining quiets must be quite bad: I play with a null-window around alpha to prove that they are bad but I also reduce by 2 plys so this proof is cheaper. When it does not result in an alpha-cut I search the move again with the normal window and full depth.

This means that the history heuristic not only decides the order of quiet moves but also which ones get reduced. This makes it complicated to test because when I make a change that is supposed to improve the move ordering but this somehow moves the point where I transition between sorted quiets and unsorted quiets this will influence the behavior and strength of the engine significantly.

So I tried moving away from this and employ a Late-Move-Reduction scheme that is literally just about how late a move is so that even captures and killers could be reduced in which case their order would matter much more and then maybe SEE-move ordering etc would finally be worthwhile.

But whatever I tried it never got stronger than my old way of doing things. A reduction always risks missing something important. My old way of reducing only quiet moves that have a bad history score was apparently not missing a lot. And the threshold when to start reducing was not constant and stupid based on the #number of the move but based on statistics so it served me well. But apparently it's a dead-end because now I can't improve the search by better move-ordering.

Or maybe I do improve the engine? But it takes a certain search depth before it really becomes beneficial... and my 5s + 100ms increment tests are just too shallow?
Sure, I could just use longer time controls but I had it often enough that a change looked like +10 Elo after 1000 games only to end up as 0 Elo after 3000 more games. So longer time controls and thousands of games... that's just not very practical on my PC.

To compensate for that I tried to understand the internal workings of my engine better to maybe improve the engine by improving some critical metrics first.

I can for example search the 300 positions from the WAC testset (I should probably replace it because it's become too easy) and get a summary after each position or at the end that looks like this:

Code: Select all

[BETA CUTOFFS]
Ply:  0 || New:        0 | Captures:        0 | Killers:        0 | SortedQuiets:        0 | Quiets:        0 |
Ply:  1 || New:    41861 | Captures:     8992 | Killers:     2023 | SortedQuiets:      195 | Quiets:      236 |
Ply:  2 || New:    53047 | Captures:    16386 | Killers:     3956 | SortedQuiets:     1073 | Quiets:     1006 |
Ply:  3 || New:   275257 | Captures:   236892 | Killers:    28429 | SortedQuiets:     4320 | Quiets:     2311 |
Ply:  4 || New:   237416 | Captures:   215854 | Killers:    29048 | SortedQuiets:     7891 | Quiets:     4510 |
Ply:  5 || New:   537570 | Captures:   897825 | Killers:   127725 | SortedQuiets:    23261 | Quiets:     9040 |
Ply:  6 || New:   310939 | Captures:   548935 | Killers:    81977 | SortedQuiets:    20649 | Quiets:    12123 |
Ply:  7 || New:   322937 | Captures:  1180096 | Killers:   203449 | SortedQuiets:    55270 | Quiets:    16856 |
Ply:  8 || New:   136848 | Captures:   373096 | Killers:    64783 | SortedQuiets:    20424 | Quiets:    13786 |
Ply:  9 || New:   102770 | Captures:   529976 | Killers:    91696 | SortedQuiets:    43087 | Quiets:    12339 |
Ply: 10 || New:    22994 | Captures:    86525 | Killers:    19309 | SortedQuiets:     7023 | Quiets:     5616 |
Ply: 11 || New:    10388 | Captures:   103679 | Killers:    19079 | SortedQuiets:    11585 | Quiets:     3626 |
=============================================================
Cutoffs || New:  2052027 | Captures:  4198256 | Killers:   671474 | SortedQuiets:   194778 | Quiets:    81449 |
        || New:   28,51% | Captures:   58,33% | Killers:    9,33% | SortedQuiets:    2,71% | Quiets:    1,13% |
        
[MOVE COUNTS]
Ply:  0 || New:     3300 | Captures:    11124 | Killers:     4994 | SortedQuiets:     5223 | Quiets:   122203 | Sorted:4,10%
Ply:  1 || New:    46681 | Captures:    26208 | Killers:     8236 | SortedQuiets:     7631 | Quiets:    91221 | Sorted:7,72%
Ply:  2 || New:    67859 | Captures:   289608 | Killers:    77351 | SortedQuiets:   140307 | Quiets:  2731299 | Sorted:4,89%
Ply:  3 || New:   291849 | Captures:   463777 | Killers:    95777 | SortedQuiets:   147686 | Quiets:  1327562 | Sorted:10,01%
Ply:  4 || New:   266614 | Captures:  2210364 | Killers:   382294 | SortedQuiets:   941776 | Quiets: 19050529 | Sorted:4,71%
Ply:  5 || New:   565322 | Captures:  1984591 | Killers:   429918 | SortedQuiets:   926100 | Quiets:  7804688 | Sorted:10,61%
Ply:  6 || New:   341521 | Captures:  3513645 | Killers:   586502 | SortedQuiets:  1392035 | Quiets: 27717614 | Sorted:4,78%
Ply:  7 || New:   340072 | Captures:  2340983 | Killers:   552765 | SortedQuiets:  1166212 | Quiets:  9113605 | Sorted:11,34%
Ply:  8 || New:   153965 | Captures:  1776047 | Killers:   358085 | SortedQuiets:   789929 | Quiets: 13156616 | Sorted:5,66%
Ply:  9 || New:   110619 | Captures:  1003462 | Killers:   245941 | SortedQuiets:   552742 | Quiets:  3979038 | Sorted:12,20%
Ply: 10 || New:    28266 | Captures:   413179 | Killers:   103572 | SortedQuiets:   227419 | Quiets:  3382287 | Sorted:6,30%
Ply: 11 || New:    12207 | Captures:   192467 | Killers:    50642 | SortedQuiets:   117751 | Quiets:   771339 | Sorted:13,24%
=============================================================
Total   || New:  2228275 | Captures: 14225455 | Killers:  2896077 | SortedQuiets:  6414811 | Quiets: 89248001 | Sorted:6,71%
        || New:    1,94% | Captures:   12,37% | Killers:    2,52% | SortedQuiets:    5,58% | Quiets:   77,60% |
        
[BETA CUTOFF RATIOS]
Ply:  0 || New:    0,00% | Captures:    0,00% | Killers:    0,00% | SortedQuiets:    0,00% | Quiets:    0,00% |
Ply:  1 || New:   89,67% | Captures:   34,31% | Killers:   24,56% | SortedQuiets:    2,56% | Quiets:    0,26% |
Ply:  2 || New:   78,17% | Captures:    5,66% | Killers:    5,11% | SortedQuiets:    0,76% | Quiets:    0,04% |
Ply:  3 || New:   94,31% | Captures:   51,08% | Killers:   29,68% | SortedQuiets:    2,93% | Quiets:    0,17% |
Ply:  4 || New:   89,05% | Captures:    9,77% | Killers:    7,60% | SortedQuiets:    0,84% | Quiets:    0,02% |
Ply:  5 || New:   95,09% | Captures:   45,24% | Killers:   29,71% | SortedQuiets:    2,51% | Quiets:    0,12% |
Ply:  6 || New:   91,05% | Captures:   15,62% | Killers:   13,98% | SortedQuiets:    1,48% | Quiets:    0,04% |
Ply:  7 || New:   94,96% | Captures:   50,41% | Killers:   36,81% | SortedQuiets:    4,74% | Quiets:    0,18% |
Ply:  8 || New:   88,88% | Captures:   21,01% | Killers:   18,09% | SortedQuiets:    2,59% | Quiets:    0,10% |
Ply:  9 || New:   92,90% | Captures:   52,81% | Killers:   37,28% | SortedQuiets:    7,80% | Quiets:    0,31% |
Ply: 10 || New:   81,35% | Captures:   20,94% | Killers:   18,64% | SortedQuiets:    3,09% | Quiets:    0,17% |
Ply: 11 || New:   85,10% | Captures:   53,87% | Killers:   37,67% | SortedQuiets:    9,84% | Quiets:    0,47% |
=============================================================

 300. [X] g5g6 h7h6 h5h6 g7h6 g6g7 h8g8 g7f8q g8f8 d7d8 e6e8 d8e8 f8e8 = +250,00, 473434 nodes, 130ms
     142240703 nodes, 49 seconds, 285 solved.

Searched 300 positions with (12)
142240703 nodes visited. Took 49,625 seconds!
2866K NPS.
Best move found in 285 / 300 positions!

So... when I'm using a simple history heuristic that just uses [piece, to-square] as an index for the lookup I would expect some good quiets to slip from the sorted (and unreduced) ones into the normal quiets and drive up the cut-off ratio there. When I try to improve the history heuristic I wouldn't want more sorted-quiets (because that means it takes an higher number nodes to reach a fixed depth, not noticable at shallow searches but a real problem at very long time controls) but I'd want the sorted quiets to produce more cutoffs and the unsorted ones less. Or the number of sorted-quiets to increase proportionally without causing more nodes to be searched in total, which is going to happen if the heuristic really helps me to pick the good quiets in the given position.

And based on these metrics it looks like I can improve upon my simplistic history heuristic (Cutoffs in SortedQuiets: 3,08%, Quiets: 1,33%) to something like SortedQuiets: 3,17%, Quiets: 1,22% and have the number of sorted quiets go up from 4,81% to 5,39% and *still* search less nodes total when I search all 300 positions to a fixed depth of 18 for example. All this are signs of better move ordering of non-captures...

But then I make a build and test that and at least at fast time controls it's not better. The more complicated heuristic is of cause making the engine a bit slower in total. And maybe that speed-loss is eating up whatever gain I should otherwise see...

[Mike Sherwin]

Possibly one way to improve history tables is to have one table with a long period and one with a short period. Then experiment how to best use the two values.

[lithander]

I'm trying a new strategy where I'm looking into Leorik's blunders at the CCRL games at long time controls.

Here's an interesting one...

[fen]2brr1k1/5pp1/p2P3p/q3p3/2B1N3/1P1Q1PP1/P5KP/3R4 b - - 2 33[/fen]


Leorik want's to play Qxa2+ (a5a2) and evaluates it as +0.00 but this move changes the eval from +1.2 to +4.6 if you ask Stockfish.

Code: Select all

position fen 2brr1k1/5pp1/p2P3p/q3p3/2B1N3/1P1Q1PP1/P5KP/3R4 b - - 2 33
go
info depth 23 score cp 0 nodes 1089866797 nps 4071270 time 267697 pv a5a2 d1d2 a2a5 e4f6 g7f6 d3g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8

If you play the PV you arrive at this position...

[fen]2brr2k/5p2/p2P1pQp/q3p3/2B5/1P3PP1/3R2KP/8 w - - 2 37[/fen]


...where Leorik originally thought the continuation would be a 3-fold-repetition that should be valued as 0.0: g6h6 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8

But if you ask the engine again from this position Leorik slowly realizes that this is actually going to end quiet bad for black.

Code: Select all

position fen 2brr2k/5p2/p2P1pQp/q3p3/2B5/1P3PP1/3R2KP/8 w - - 2 37
go
info depth 1 score cp -131 nodes 139 nps 139000 time 0 pv g6f6
info depth 2 score cp -128 nodes 223 nps 223000 time 0 pv g6f6 h8h7
info depth 3 score cp -34 nodes 755 nps 755000 time 0 pv g6h6 h8g8 h6g6
info depth 4 score cp -41 nodes 1092 nps 1092000 time 0 pv g6h6 h8g8 h6g6 g8h8
info depth 5 score cp -50 nodes 2525 nps 2525000 time 0 pv g6h6 h8g8 h6g6 g8h8 g6f6
info depth 6 score cp 0 nodes 4693 nps 4693000 time 1 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8
info depth 7 score cp 0 nodes 8066 nps 4033000 time 2 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6
info depth 8 score cp 0 nodes 12914 nps 4304666 time 3 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8
info depth 9 score cp 0 nodes 26015 nps 5203000 time 5 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6
info depth 10 score cp 0 nodes 47283 nps 4728300 time 10 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8
info depth 11 score cp 0 nodes 102758 nps 4467739 time 23 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6
info depth 12 score cp 0 nodes 199731 nps 4539340 time 44 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8
info depth 13 score cp 0 nodes 451970 nps 4263867 time 106 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6
info depth 14 score cp 0 nodes 779792 nps 4284571 time 182 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8
info depth 15 score cp 0 nodes 1814349 nps 4068047 time 446 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6
info depth 16 score cp 0 nodes 3371695 nps 4057394 time 831 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8
info depth 17 score cp 0 nodes 7261402 nps 4007396 time 1812 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6
info depth 18 score cp 0 nodes 11843759 nps 4014833 time 2950 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8
info depth 19 score cp 0 nodes 22478163 nps 3954638 time 5684 pv g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6 g8h8 g6h6 h8g8 h6g6
info depth 20 score cp 74 nodes 36609368 nps 3881400 time 9432 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 c8e6 c4d3 h7h8 g5h6 h8g8 d3h7 g8f7 h7g6 f7g8
info depth 21 score cp 90 nodes 68915398 nps 3802019 time 18126 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 c8e6 c4d3 h7h8 g5h6 h8g8 d3h7 g8f7 h7g6 f7g8 g6e8
info depth 22 score cp 74 nodes 128933801 nps 3710965 time 34744 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 c8e6 c4d3 h7h8 g5h5 h8g8 h5g6 g8f8 g6h6 f8f7 d3g6 f7g8
info depth 23 score cp 225 nodes 232268489 nps 3638176 time 63842 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b6 c4f7 d8d6 d2d6 b6d6 f7e8 d6e6 e8h5 e6h3 g2g1 c8f5 h5f7
info depth 24 score cp 213 nodes 395830681 nps 3542045 time 111752 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b6 c4f7 d8d6 d2d6 b6d6 f7e8 d6e6 g5h5 h7g7 e8a4 e6f6 b3b4 c8f5
info depth 25 score cp 240 nodes 776613168 nps 3522662 time 220462 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b6 c4f7 d8d6 d2d6 b6d6 f7e8 d6e6 e8a4 e6h3 g2g1 h3e6 g5h4 h7g8 b3b4
info depth 26 score cp 214 nodes 1452225689 nps 3453889 time 420461 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b6 c4f7 d8d6 d2d6 b6d6 f7e8 d6e6 e8a4 c8b7 g5h5 h7g7 h2h4 e6f6 h5g5 f6g5
info depth 27 score cp 234 nodes 3044653051 nps 3440449 time 884958 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b6 c4f7 d8d6 d2d6 b6d6 f7e8 d6e6 e8a4 e6h3 g2g1 h3e6 g5h4 h7g7 h4e4 e6f5 a4c6
info depth 28 score cp 217 nodes 5546525472 nps 3443994 time 1610492 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b6 c4f7 d8d6 d2d6 b6d6 f7e8 d6e6 e8a4 c8b7 g5h5 h7g7 h2h4 e5e4 h5g5 g7f7 g5h5 f7g7

So I'm wondering how could I speed that realization up? It takes 10 seconds before Leoriks evaluation changes to be finally in favor for white and then only a little. Stockfish realizes this immediately already at depth 1!!!

Code: Select all

info depth 1 seldepth 2 multipv 1 score cp 332 nodes 119 nps 119000 tbhits 0 time 1 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8g8 f6f7 g8h8
info depth 2 seldepth 4 multipv 1 score cp 361 nodes 200 nps 200000 tbhits 0 time 1 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7
info depth 3 seldepth 6 multipv 1 score cp 361 nodes 271 nps 135500 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7
info depth 4 seldepth 8 multipv 1 score cp 322 nodes 414 nps 207000 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6
info depth 5 seldepth 10 multipv 1 score cp 322 nodes 512 nps 256000 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7
info depth 6 seldepth 11 multipv 1 score cp 308 nodes 727 nps 363500 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5
info depth 7 seldepth 20 multipv 1 score cp 322 nodes 8820 nps 1470000 tbhits 0 time 6 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7
info depth 8 seldepth 22 multipv 1 score cp 212 nodes 19926 nps 1532769 tbhits 0 time 13 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b4 c4f7 e8f8
info depth 9 seldepth 22 multipv 1 score cp 265 nodes 23484 nps 1677428 tbhits 0 time 14 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b4 c4f7
info depth 10 seldepth 16 multipv 1 score cp 262 nodes 25379 nps 1691933 tbhits 0 time 15 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5a1 c4d5 e8f8 d5e4 h7h8 g5h6 h8g8
info depth 11 seldepth 21 multipv 1 score cp 275 nodes 26422 nps 1651375 tbhits 0 time 16 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b4 c4f7
info depth 12 seldepth 18 multipv 1 score cp 315 nodes 26801 nps 1675062 tbhits 0 time 16 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b6 c4f7 e5e4
info depth 13 seldepth 22 multipv 1 score cp 393 nodes 27515 nps 1618529 tbhits 0 time 17 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5a1 c4d5
info depth 14 seldepth 22 multipv 1 score cp 496 nodes 29309 nps 1724058 tbhits 0 time 17 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b4 c4f7 d8d6

What ist Stockfish doing to get such a deep PV including the critical f6f7 move at depth 1!?

[Witek]

What ist Stockfish doing to get such a deep PV including the critical f6f7 move at depth 1!?

Are you sure you didn't run analysis with some data already cached in transposition table? I've just run this position on Stockfish 15 and it reports Qxh6+ at depth 4, not 1:

Code: Select all

Stockfish 15 by the Stockfish developers (see AUTHORS file)
position fen 2brr2k/5p2/p2P1pQp/q3p3/2B5/1P3PP1/3R2KP/8 w - - 2 37
go
info string NNUE evaluation using nn-6877cd24400e.nnue enabled
info depth 1 seldepth 1 multipv 1 score cp 285 nodes 63 nps 3500 tbhits 0 time 18 pv g6f6 h8h7 f6f7 h7h8
info depth 2 seldepth 2 multipv 1 score cp 285 nodes 113 nps 6277 tbhits 0 time 18 pv g6f6 h8h7 f6f7 h7h8
info depth 3 seldepth 3 multipv 1 score cp 285 nodes 169 nps 9388 tbhits 0 time 18 pv g6f6 h8h7 f6f7 h7h8
info depth 4 seldepth 4 multipv 1 score cp 285 nodes 249 nps 13833 tbhits 0 time 18 pv g6f6 h8h7 f6f7 h7h8
info depth 5 seldepth 5 multipv 1 score cp 328 nodes 445 nps 24722 tbhits 0 time 18 pv g6h6 h8g8 h6g6 g8h8

What makes Stockfish report win for white so quickly is probably NNUE evaluation which was trained on billions of positions.

Also remember "depth 1" is not just current position, but it's all child positions + quiescence search of those, so even at depth 1, there's quite a lot of positions being evaluated.

[lithander]

Are you sure you didn't run analysis with some data already cached in transposition table? I've just run this position on Stockfish 15 and it reports Qxh6+ at depth 4, not 1:

I was using Stockfish 13 and this is the full output:

Code: Select all

Stockfish 13 by the Stockfish developers (see AUTHORS file)
position fen 2brr2k/5p2/p2P1pQp/q3p3/2B5/1P3PP1/3R2KP/8 w - - 2 37
go depth 10
info string NNUE evaluation using nn-62ef826d1a6d.nnue enabled
info depth 1 seldepth 2 multipv 1 score cp 332 nodes 119 nps 119000 tbhits 0 time 1 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8g8 f6f7 g8h8
info depth 2 seldepth 4 multipv 1 score cp 361 nodes 200 nps 100000 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7
info depth 3 seldepth 6 multipv 1 score cp 361 nodes 271 nps 135500 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7
info depth 4 seldepth 8 multipv 1 score cp 322 nodes 414 nps 207000 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6
info depth 5 seldepth 10 multipv 1 score cp 322 nodes 512 nps 256000 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7
info depth 6 seldepth 11 multipv 1 score cp 308 nodes 727 nps 363500 tbhits 0 time 2 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5
info depth 7 seldepth 20 multipv 1 score cp 322 nodes 8820 nps 1260000 tbhits 0 time 7 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7
info depth 8 seldepth 22 multipv 1 score cp 212 nodes 19926 nps 1660500 tbhits 0 time 12 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b4 c4f7 e8f8
info depth 9 seldepth 22 multipv 1 score cp 265 nodes 23484 nps 1677428 tbhits 0 time 14 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5b4 c4f7
info depth 10 seldepth 16 multipv 1 score cp 262 nodes 25379 nps 1691933 tbhits 0 time 15 pv g6h6 h8g8 h6g6 g8h8 g6f6 h8h7 f6f7 h7h6 f7f6 h6h7 f6g5 a5a1 c4d5 e8f8 d5e4 h7h8 g5h6 h8g8
bestmove g6h6 ponder h8g8

[Mike Sherwin]

Try disabling null move and see what happens.
Then try disabling LMR. Etc.