killer index by "ply" or "ply"

[xr_a_y]

In Minic I index killer table by "real ply" (count of half move of the position) but I see some engines using "ply" as ply from the root position being search.

Xiphos is even clearing next killer slot by

Code: Select all

sd->killer_moves[ply + 1][0] = sd->killer_moves[ply + 1][1] = 0;

at the beginning of move loop in pvs.

I was thinking that it might help to save killer indexed by real ply but I am now wondering if it's the good thing to do ...

[hgm]

Killers are a very local thing. The more positions differ, the less likely it is that the same move will work in both of them. Sibblings are already separated by 2 half-moves. If you don't clear the killer slots of the next level at the start of a node, they would recommend moves that worked in positions that differ by four ply. That could be a waste of time more often than not.

[xr_a_y]

I do clear all killers when search begins but not each ply+1 killers at each pvs node.

Writting this I understand that it is worthless to store killers index by "real half move" as I fully clear the killer table ...

But I still don't get why Xiphos is clearing ply+1 killers.

[xr_a_y]

Writting this I understand that it is worthless to store killers index by "real half move" as I fully clear the killer table ...

in fact I use this in MoveSorter in order to get "current" killers without knowing the current ply ... halfmove is used. Anyway

[D Sceviour]

I do clear all killers when search begins but not each ply+1 killers at each pvs node.

Writting this I understand that it is worthless to store killers index by "real half move" as I fully clear the killer table ...

But I still don't get why Xiphos is clearing ply+1 killers.

Xiphos change log noted the idea was taken from Stockfish or Ethereal, but it did not produce much elo difference. It is probably unnecessary.

[RubiChess]

This was discussed here: viewtopic.php?f=7&t=69744
I tested myself clearing the killers at ply+1 but couldn't make it work.

- Andreas

[xr_a_y]

This was discussed here: viewtopic.php?f=7&t=69744
I tested myself clearing the killers at ply+1 but couldn't make it work.

- Andreas

Thanks

[hgm]

Even if it doesn't produce any Elo, I like the clearing, because it means that no killers can leak from one search into another. This improves reproducibility, which helps debugging.

[xr_a_y]

Cleaning at each search begin is OK and done already, for reproducibility indeed.
On the other hand, cleaning ply+1 slots before the move loop at pvs(ply) is not improving anything in Minic at least.

[bob]

I remember when Dave Slate wrote the first paper I saw on this topic. He gave a position where black was on move, and white had the move Nxc7+ forking the black king and rook. As black tries different moves, almost ALL are refuted by the same move, Nxc7. Except for say Rac8 and Kd8 or Kd7 or even Kf8 to avoid the check. This is an example where clearing killers at ply+1 actually hurts significantly. And over the years it seems to me that while killers are pretty local, If you clear killers ply+1 before searching at ply, then the above won't happen, but back up two plies where white plays Nb5 and then Nxc7+ Black has to stop either Nb5 or Nxc7. Which are killer moves for most black replies. Zeroing ply+1 would at the very least wipe out the Nxc7+ move over and over whenever white plays Nb5. If he doesn't, that move is not legal and has no negative effect to speak of.

I've tried zeroing them but always found a small cost in tree size. In fact, I even try killers[ply-2] before giving up on trying killer moves, and that tested positive for me.

YMMV of course.