Killer moves?

[petero2]

Has anyone tried the idea to update killers when you get a hash hit that gives a beta cut off? Doing this seems logical to me, but it seems like neither crafty nor stockfish does this.

[michiguel]

Has anyone tried the idea to update killers when you get a hash hit that gives a beta cut off? Doing this seems logical to me, but it seems like neither crafty nor stockfish does this.

Yes, it makes sense if it is not a capture, but it did not work for me. I tried it actually a couple of weeks ago inspired by some of the threads. Possibly, it may give a 0.1 elo improvement that the noise hid.

Miguel

[Uri Blass]

I think that there should be many cases when it is better not to try killers first even when there is no good captures or hash moves.

For example suppose that the null move killer move is Bb4 but the last move of white was a3 and you have not a good capture and no move in the hash.
It seems stupid to try Bb4 first.

[PK]

in Glass, Edmund implemented using killer moves only if their static exchange evaluation was not too bad, which excluded moving a bishop on a square protected by a pawn. It helped indeed.

[mcostalba]

I think that there should be many cases when it is better not to try killers first even when there is no good captures or hash moves.

For example suppose that the null move killer move is Bb4 but the last move of white was a3 and you have not a good capture and no move in the hash.
It seems stupid to try Bb4 first.

This is a special case of the more general pruning/reducing step.

Form the point of view of code modularity it is important to disjoint:

1) Move generation

2) Move ordering

3) Move pruning/reduction

Killer moves ordering is done in step 2, while reducing/pruning a move if it is considered bad (for instance if SEE score is negative) is done in step 3.

When developing an engine it is important to have clear in mind what is the sequence of (largely independent) steps that from move generation arrive at making a move. Otherwise if you have a mess in your mind also the resulting engine will be a mess.

[bob]

Has anyone tried the idea to update killers when you get a hash hit that gives a beta cut off? Doing this seems logical to me, but it seems like neither crafty nor stockfish does this.

Have not, but will, since it is easy enough to test...

[bob]

Has anyone tried the idea to update killers when you get a hash hit that gives a beta cut off? Doing this seems logical to me, but it seems like neither crafty nor stockfish does this.

Have not, but will, since it is easy enough to test...

OK, tested this SEE limit on killers. -25 Elo, tested twice at 30K games.

Very simple change, but it doesn't seem to work...

[bob]

It's working nicely now and the improvement is noticeable. I'm still not where I want it to be but I'm moving in the right direction.

Take care not to have the same killer twice.

Here is the code I use where "mv" is the move that produced a beta (fail hi) cutoff and it's not a capture move:

Code: Select all

    
if (mv != ka[ply])  {
  kb[ply] = ka[ply];
  ka[ply] = mv;
}

Just for the record, that's not a very good way to do this. That makes kb[ply] and ka[ply] separated by sizeof(ka). Which pretty much guarantees that each killer will be in a different cache line. Much better is to put em in a structure, that is subscripted. Something like killer[ply].a and killer[ply].b so that the two killers for a single ply are in consecutive memory addresses. And generally in the same cache line.

[hgm]

Indeed. I use Move_t killer[MAXPLY][2]; for the same reason.

[jwes]

It's working nicely now and the improvement is noticeable. I'm still not where I want it to be but I'm moving in the right direction.

Take care not to have the same killer twice.

Here is the code I use where "mv" is the move that produced a beta (fail hi) cutoff and it's not a capture move:

Code: Select all

    
if (mv != ka[ply])  {
  kb[ply] = ka[ply];
  ka[ply] = mv;
}

Just for the record, that's not a very good way to do this. That makes kb[ply] and ka[ply] separated by sizeof(ka). Which pretty much guarantees that each killer will be in a different cache line. Much better is to put em in a structure, that is subscripted. Something like killer[ply].a and killer[ply].b so that the two killers for a single ply are in consecutive memory addresses. And generally in the same cache line.

Speaking of this, I noticed that struct tree in crafty contains 8 arrays[MAXPLY] and 3 [MAXPLY+2] . Wouldn't it be better to combine these into structs?