PV-move ordering necessary if you have TT-move ordering?

[hgm]

To store in the TT you need the hash key for all positions along the PV. (Note the full hash key is usually not in the entry, so you would have to store that next to the data that you want to store.) You could of course store all that information in the triangular array, but then you would be juggling around a lot more info than just the move. I don't think that would be a good tradeoff. And you would have to make the decision what to overwrite in the bucket, which might be different when you stuff it back then when you did the original store during search.

[mvanthoor]

To store in the TT you need the hash key for all positions along the PV. (Note the full hash key is usually not in the entry, so you would have to store that next to the data that you want to store.) You could of course store all that information in the triangular array, but then you would be juggling around a lot more info than just the move. I don't think that would be a good tradeoff.

So you think it would be better to run through the PV, make and unmake the move on the board (to get the Zobrist hash belonging to each position), and then putting the position back into the TT? In that case, how do you get the alpha value that belonged to that move? The only alpha you're left with is the one coming from alpha-beta, which would be your current best evaluation.

[lithander]

Over night I have run two versions of MMC on 879 positions from the Encyclopedia of Chess Combinations. Each position was searched to depth 11.

One version plays the PV move from the tri-table between the TT move and the first capture. (MMC 0.5 with no changes)
It searched 879 positions to depth 11. 32.749.036K nodes visited. Took 27008.855 seconds!

The other (modified) version just plays the TT move if available and followed by the MVV-LVA sorted best capture.
Searched 879 positions to depth 11. 32.629.574K nodes visited. Took 27991.072 seconds!

You can see that playing the PV move from the tri-table concludes the search a little faster. But it also searched more nodes.
That searching more positions still reduces the total runtime by 4% can be explained by the fact that playing and cutting on the PV move from the tri-table allows the engine to skip generating moves for that position.

---

What these detailed tests also show is that a 4% speed gain is probably not worth the extra complexity. I will try to remove the tri-table from minimal chess in a future version.

[mvanthoor]

You can see that playing the PV move from the tri-table concludes the search a little faster. But it also searched more nodes.
That searching more positions still reduces the total runtime by 4% can be explained by the fact that playing and cutting on the PV move from the tri-table allows the engine to skip generating moves for that position.

Then you'd get different results, if you don't have staged move generation.

What these detailed tests also show is that a 4% speed gain is probably not worth the extra complexity. I will try to remove the tri-table from minimal chess in a future version.

You'd still need something to collect the PV so you can send it to the GUI.

PS: I've run a test where I store and retrieve information in the TT in QSearch (storing everything at depth 0, because there's no depth parameter in QSearch). Rustic becomes considerably weaker. It looks like storing and probing in the TT costs so much time that QSearch is slowed to such an extent that the engine is weaker.

[hgm]

So you think it would be better to run through the PV, make and unmake the move on the board (to get the Zobrist hash belonging to each position), and then putting the position back into the TT?

That is what I do in Joker, a special recursive routine to follow the PV. Not to stuff it in the TT, but to extract it. (Joker doesn't use the triangular method.)

In that case, how do you get the alpha value that belonged to that move? The only alpha you're left with is the one coming from alpha-beta, which would be your current best evaluation.

All nodes of the PV have the same score as the root; they supplied it to the root.

[hgm]

You can see that playing the PV move from the tri-table concludes the search a little faster. But it also searched more nodes.
That searching more positions still reduces the total runtime by 4% can be explained by the fact that playing and cutting on the PV move from the tri-table allows the engine to skip generating moves for that position.

That doesn't seem a likely explanation. There should not be any cut in a PV node; you always search all moves there. Besides, only 11 nodes of each search should have a PV move from the triangular array available, which should be a completely negligible fraction of the nodes.

[mvanthoor]

That doesn't seem a likely explanation. There should not be any cut in a PV node; you always search all moves there. Besides, only 11 nodes of each search should have a PV move from the triangular array available, which should be a completely negligible fraction of the nodes.

Thomas also said he got only 10% hit on the TT-move. I think it's possible. I assume the number of all-nodes is HUGE compared to the number of pv-nodes and cut-nodes. Over the weekend I'll probably add some stats to my engine to verify.

[hgm]

I don't follow your logic. On average his search trees have 37K nodes. You think that what happens in 55 of those (1 + 2 + ... + 10) could measurably affect the timing?

And how would it be relevant how many hash hits he gets? Or which fraction of the nodes is all nodes?

[mvanthoor]

I don't follow your logic. On average his search trees have 37K nodes. You think that what happens in 55 of those (1 + 2 + ... + 10) could measurably affect the timing?

And how would it be relevant how many hash hits he gets? Or which fraction of the nodes is all nodes?

He has mentioned several times that he only got a move back (pv-move or cut-move) from the TT in 10% of probes. He thought this to be too low, where I think it's plausible that 90% of all positions in the TT are all-nodes, where a position is stored in the TT, but without a move because alpha was never raised.

[hgm]

I think that in Joker only 15% of the TT probes were hits in the first place, in the middle-game. If 10% of the probes give a move, then most hits would be for cut-nodes.

I still don't see how this is relevant for the question of why using the PV from the triangular array would increase the nps.