more curiosities in looking at modified glaurung source

[AndrewShort]

noticed a couple more curiosities in the modified glaurung source:

(1) null-move is NOT used in pv nodes. why not? (I use them everywhere). Perhaps he doesn't use null move there for the same reason he doesn't use the hash to prune pv nodes... to keep pv nodes pure...

(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?

[hgm]

How is a PV node defined? If it is only when beta = INF, then doing a null move is pointless, as it could not possibly fail high. In Joker, I only do null move if the current evaluation is above beta, otherwise any useless move of the opponent would already be sufficient to refute it.

IID can be an insurance noticing a cut move too late. Even with null window you would discover good moves, because they will fail high in stead of low.

[bob]

noticed a couple more curiosities in the modified glaurung source:

(1) null-move is NOT used in pv nodes. why not? (I use them everywhere). Perhaps he doesn't use null move there for the same reason he doesn't use the hash to prune pv nodes... to keep pv nodes pure...

(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?

I have tried this in the past. For me, trying null move _everywhere_ has always been fastest. The idea is that null-moves should never fail high on a PV node search, but that is only true if the move you look at first is really the best one. It is not uncommon to change your mind at deep PV nodes just as often as you change your mind at the root.

As a result, I'd almost suspect it would be faster if this restriction was lifted, based on my past testing.

[mcostalba]

(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

[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.

[Zach Wegner]

Is it? I do IID on CUT nodes, and it helps for me.

[jwes]

(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 ?

[bob]

[quote="Zach Wegner"]Is it? I do IID on CUT nodes, and it helps for me.[/quote

I have tried it in every possible variation and none worked for me except for along the primary PV. There are way too many other CUT nodes where a move "good enough" will do the job, most notably a capture. I don't need to do a search to find that the best move is a capture...

Not sure why it is better for you, but it was not for me. I even tested it a month or so back when someone else was talking about it, and it was a rating killer on cluster testing.

[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...

Along the PV we have pretty good moves along the way, and hash moves are good moves to try. But away from the PV, most moves get refuted by captures, and I can find those with far less effort than IID...

[jwes]

(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).