more curiosities in looking at modified glaurung source

[hgm]

Indeed, that is how I do it in Joker. It is kind of automatic anyway, wheter you explicitly exclude the hash move or not: in any iteration of the IID, even the final one, you will get a sufficient-depth hash hit on the hash move, as it was already searched to nominal depth. But the score will be a fail low, so that other good moves now have an opportunity to maniffest themselves by exceeding alpha. (Which, apparently, they were not able to do on the previous iteration.)

Joker does this in every node (PV, CUT or ALL), and furthermore increases IID depth in steps of 1 ply.

I did re-measure the effect of IID on Joker in connection with the previous discussion as well: I switched off most of it by suppressing any iteration except the d=1. (The d=1 iteration is in practice equivaland to ETC.) This should eliminate almost all overhead associated with it. I played the IID and non-IID version against each other, and the non-IID lost. Not by enough for the number of games to be sure that it is worse, but by enough so that it can be safely ruled out that it is much better.

[bob]

(2) IID is used in nonpv (zero window) nodes. I don't understand that. (I only use them in pv nodes) How can you get a best move from IID when the IID is searching with a zero window?

Actually if you look at the flag UseIIDAtNonPVNodes at the beginning of the IID if:

Code: Select all

if (    UseIIDAtNonPVNodes
    && ttMove == MOVE_NONE
    && depth >= 8*OnePly
    && evaluate(pos, ei, threadID) >= beta - IIDMargin)
    {
        search(pos, ss, beta, Min(depth/2, depth-2*OnePly), ply, false, threadID);
        ttMove = ss[ply].pv[ply];
    }

You will see that is a constant set to false, so actually no IID is done on non-pv nodes.

I have enabled IID and tweaked a bit that code but with no luck, so I have reverted to the original disabled IID.

Marco

IID is _way_ too expensive on non-PV nodes. Most nodes won't have a hash hit, much less a best move from hash, and doing IID there is too much overhead. At ALL nodes you can't possibly get a cutoff anyway, so IID to choose the best move is a waste of time.

Would it make sense to do IID at PV nodes when the hash move fails low ?

I don't think so. This move came from the previous iteration, and an IID search will be at least a ply shallower than that, so I am not sure how it would help...
.

The idea is that when the hash move fails low, you don't know which move to try next, so you do an IID (excluding the hash move).

And quite often _all_ moves fail low, so the IID would be completely wasted...

[hgm]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

[bob]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

You should check your hash statistics more often. I usually see 20% total hits, but most are not sufficient draft. 20% is a long way from 100%, which means 80% of the IID searches are not going to get a hash hit to terminate them. We didn't get a hash hit to provide a best move, so what are we going to get from hashing to cut the cost?

[jwes]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

You should check your hash statistics more often. I usually see 20% total hits, but most are not sufficient draft. 20% is a long way from 100%, which means 80% of the IID searches are not going to get a hash hit to terminate them. We didn't get a hash hit to provide a best move, so what are we going to get from hashing to cut the cost?

Your statistics may be misleading here (and your have removed all the hash logging code from crafty). I ran some tests on crafty to see how often IID is ueed on some epd positions taken from GM games and got:

Code: Select all

Total nodes: 4,142,218,015
PV nodes:           25,173
Pv nodes using IID:    485

This suggests that you are getting better than 95% hssh hits on PV nodes and IID is used so infrequently that it might be better not to use it.

I also saw that you have three different tests for PV nodes in search.c.

Code: Select all

line 214;
  if (do_null && alpha == beta - 1) {

Line 264:
      int abound = (ply & 1) ? root_alpha : -root_beta;
      int bbound = (ply & 1) ? root_beta : -root_alpha;

      if (alpha != abound || beta != bbound)
        break;

Line 446:
    if (alpha != o_alpha) {

[bob]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

You should check your hash statistics more often. I usually see 20% total hits, but most are not sufficient draft. 20% is a long way from 100%, which means 80% of the IID searches are not going to get a hash hit to terminate them. We didn't get a hash hit to provide a best move, so what are we going to get from hashing to cut the cost?

Your statistics may be misleading here (and your have removed all the hash logging code from crafty). I ran some tests on crafty to see how often IID is ueed on some epd positions taken from GM games and got:

Code: Select all

Total nodes: 4,142,218,015
PV nodes:           25,173
Pv nodes using IID:    485

This suggests that you are getting better than 95% hssh hits on PV nodes and IID is used so infrequently that it might be better not to use it.

Think about this for a moment. I intentionally _guarantee_ that the PV from the last search is in the table. So yes, I get mostly hits and IIDs are rare. Where they happen is on the positions where I fail high, but can not find the real score before running out of time. So I have no PV to store in the hash, and although at every other ply I might have a beta cutoff move saved, at every other ply I have nothing since they were ALL nodes. And that is where IID happens. If you turn it on more liberally, and it is easy to do, the tree will explode...

I also saw that you have three different tests for PV nodes in search.c.

Code: Select all

line 214;
  if (do_null && alpha == beta - 1) {

Line 264:
      int abound = (ply & 1) ? root_alpha : -root_beta;
      int bbound = (ply & 1) ? root_beta : -root_alpha;

      if (alpha != abound || beta != bbound)
        break;

Line 446:
    if (alpha != o_alpha) {

Those are not the same tests. The first simply asks "is this a PVS node or not (PVS = null-window). I only do null-move there, not on nodes with a more "open" window. So that doesn't test for PV explicitly although PV nodes are included.

THe second is a _real_ PV node where the bounds at the current node are identical to the bounds at the root.

The last just asks "did we improve the score or not?"

[jwes]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

You should check your hash statistics more often. I usually see 20% total hits, but most are not sufficient draft. 20% is a long way from 100%, which means 80% of the IID searches are not going to get a hash hit to terminate them. We didn't get a hash hit to provide a best move, so what are we going to get from hashing to cut the cost?

Your statistics may be misleading here (and your have removed all the hash logging code from crafty). I ran some tests on crafty to see how often IID is ueed on some epd positions taken from GM games and got:

Code: Select all

Total nodes: 4,142,218,015
PV nodes:           25,173
Pv nodes using IID:    485

This suggests that you are getting better than 95% hssh hits on PV nodes and IID is used so infrequently that it might be better not to use it.

Think about this for a moment. I intentionally _guarantee_ that the PV from the last search is in the table. So yes, I get mostly hits and IIDs are rare. Where they happen is on the positions where I fail high, but can not find the real score before running out of time. So I have no PV to store in the hash, and although at every other ply I might have a beta cutoff move saved, at every other ply I have nothing since they were ALL nodes. And that is where IID happens. If you turn it on more liberally, and it is easy to do, the tree will explode...

Thinking about this - You have an unresolved fail high and no PV to stuff. You make the move and start pondering at depth 1. You find a PV node with no best move in hash, but the depth is too low to do IID, so you just continue searching. Nest iteration at this PV node, there is a best move in hash.

I also saw that you have three different tests for PV nodes in search.c.

Code: Select all

line 214;
  if (do_null && alpha == beta - 1) {

Line 264:
      int abound = (ply & 1) ? root_alpha : -root_beta;
      int bbound = (ply & 1) ? root_beta : -root_alpha;

      if (alpha != abound || beta != bbound)
        break;

Line 446:
    if (alpha != o_alpha) {

Those are not the same tests. The first simply asks "is this a PVS node or not (PVS = null-window). I only do null-move there, not on nodes with a more "open" window. So that doesn't test for PV explicitly although PV nodes are included.

THe second is a _real_ PV node where the bounds at the current node are identical to the bounds at the root.

The last just asks "did we improve the score or not?"

[bob]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

You should check your hash statistics more often. I usually see 20% total hits, but most are not sufficient draft. 20% is a long way from 100%, which means 80% of the IID searches are not going to get a hash hit to terminate them. We didn't get a hash hit to provide a best move, so what are we going to get from hashing to cut the cost?

Your statistics may be misleading here (and your have removed all the hash logging code from crafty). I ran some tests on crafty to see how often IID is ueed on some epd positions taken from GM games and got:

Code: Select all

Total nodes: 4,142,218,015
PV nodes:           25,173
Pv nodes using IID:    485

This suggests that you are getting better than 95% hssh hits on PV nodes and IID is used so infrequently that it might be better not to use it.

Think about this for a moment. I intentionally _guarantee_ that the PV from the last search is in the table. So yes, I get mostly hits and IIDs are rare. Where they happen is on the positions where I fail high, but can not find the real score before running out of time. So I have no PV to store in the hash, and although at every other ply I might have a beta cutoff move saved, at every other ply I have nothing since they were ALL nodes. And that is where IID happens. If you turn it on more liberally, and it is easy to do, the tree will explode...

Thinking about this - You have an unresolved fail high and no PV to stuff. You make the move and start pondering at depth 1. You find a PV node with no best move in hash, but the depth is too low to do IID, so you just continue searching. Nest iteration at this PV node, there is a best move in hash.

Depends. When I start pondering, I often don't start at ply=1. Nothing is as simple as it seems...

I can disable IID and it makes almost no difference (that is measurable) in playing on the cluster... I just ran this test a month ago in fact as I was playing with the razoring/futility/extended-futility/reductions/extensions analysis...

I also saw that you have three different tests for PV nodes in search.c.

Code: Select all

line 214;
  if (do_null && alpha == beta - 1) {

Line 264:
      int abound = (ply & 1) ? root_alpha : -root_beta;
      int bbound = (ply & 1) ? root_beta : -root_alpha;

      if (alpha != abound || beta != bbound)
        break;

Line 446:
    if (alpha != o_alpha) {

Those are not the same tests. The first simply asks "is this a PVS node or not (PVS = null-window). I only do null-move there, not on nodes with a more "open" window. So that doesn't test for PV explicitly although PV nodes are included.

THe second is a _real_ PV node where the bounds at the current node are identical to the bounds at the root.

The last just asks "did we improve the score or not?"

[jwes]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

You should check your hash statistics more often. I usually see 20% total hits, but most are not sufficient draft. 20% is a long way from 100%, which means 80% of the IID searches are not going to get a hash hit to terminate them. We didn't get a hash hit to provide a best move, so what are we going to get from hashing to cut the cost?

Your statistics may be misleading here (and your have removed all the hash logging code from crafty). I ran some tests on crafty to see how often IID is ueed on some epd positions taken from GM games and got:

Code: Select all

Total nodes: 4,142,218,015
PV nodes:           25,173
Pv nodes using IID:    485

This suggests that you are getting better than 95% hssh hits on PV nodes and IID is used so infrequently that it might be better not to use it.

Think about this for a moment. I intentionally _guarantee_ that the PV from the last search is in the table. So yes, I get mostly hits and IIDs are rare. Where they happen is on the positions where I fail high, but can not find the real score before running out of time. So I have no PV to store in the hash, and although at every other ply I might have a beta cutoff move saved, at every other ply I have nothing since they were ALL nodes. And that is where IID happens. If you turn it on more liberally, and it is easy to do, the tree will explode...

Thinking about this - You have an unresolved fail high and no PV to stuff. You make the move and start pondering at depth 1. You find a PV node with no best move in hash, but the depth is too low to do IID, so you just continue searching. Nest iteration at this PV node, there is a best move in hash.

Depends. When I start pondering, I often don't start at ply=1. Nothing is as simple as it seems...

AFICT, the only time that you don't start at ply=1 is when you have a PV from the previous search.

[bob]

"Quite often" is not very precise, and does suggest that this is not a serious objection at all. Because the time 'wasted' on IID in those cases is also "quite small":

"Nearly always" IID it totally free, as all moves were already searched to every depth lower than the currently requested final depth, so that all requests are directly satisfied from the hash table. In the rare cases that it is not, depending on which steps you take for deepening, it might only cost ~10% of the search effort of the final search. So in total perhaps 1% extra effort in a case where all moves fail low. This 1% can be easily earned back even if it would be 'not wasted' only 5% of the time.

You should check your hash statistics more often. I usually see 20% total hits, but most are not sufficient draft. 20% is a long way from 100%, which means 80% of the IID searches are not going to get a hash hit to terminate them. We didn't get a hash hit to provide a best move, so what are we going to get from hashing to cut the cost?

Your statistics may be misleading here (and your have removed all the hash logging code from crafty). I ran some tests on crafty to see how often IID is ueed on some epd positions taken from GM games and got:

Code: Select all

Total nodes: 4,142,218,015
PV nodes:           25,173
Pv nodes using IID:    485

This suggests that you are getting better than 95% hssh hits on PV nodes and IID is used so infrequently that it might be better not to use it.

Think about this for a moment. I intentionally _guarantee_ that the PV from the last search is in the table. So yes, I get mostly hits and IIDs are rare. Where they happen is on the positions where I fail high, but can not find the real score before running out of time. So I have no PV to store in the hash, and although at every other ply I might have a beta cutoff move saved, at every other ply I have nothing since they were ALL nodes. And that is where IID happens. If you turn it on more liberally, and it is easy to do, the tree will explode...

Thinking about this - You have an unresolved fail high and no PV to stuff. You make the move and start pondering at depth 1. You find a PV node with no best move in hash, but the depth is too low to do IID, so you just continue searching. Nest iteration at this PV node, there is a best move in hash.

Depends. When I start pondering, I often don't start at ply=1. Nothing is as simple as it seems...

AFICT, the only time that you don't start at ply=1 is when you have a PV from the previous search.

Depends on the version. I am not sure what I do now, but in the past I have started at the previoud depth -1 whether I had a PV or not, so long as I had an exact score. When I removed IID when testing a month or so ago, I didn't see any change in the rating for Crafty, and I had it on my to-do list to check it further and see if it should simply be removed...