more curiosities in looking at modified glaurung source

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

[bob]

Ran two sets of 32,000 games with IID disabled. Already had the results for identical version with IID in. Removing it reduced Crafty's Elo by 3, +/- 4, so this is not a "biggee".

Off to more important testing now...

[Tord Romstad]

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

Yes, basically that's it. I want the PV node search to be as pure and simple as possible. I have sometimes used a null move search without any actual pruning at PV nodes, in order to find a threat move, but at the moment I don't use threat moves for anything at PV nodes, therefore there is no null move search in my current public source code.

(2) IID is used in nonpv (zero window) nodes.

Only if you change the value of the constant UseIIDatNonPVNodes to 'true'.

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?

You don't get a best move, but you do get a move which is likely to be good enough to get a beta cutoff, which is really all you need.

In Glaurung 1, IID at non-PV nodes did seem to help. In Glaurung 2, I have never been able to measure any difference, but it is possible that IID everywhere would still be useful at very slow time controls.

Tord

[mcostalba]

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?

You don't get a best move, but you do get a move which is likely to be good enough to get a beta cutoff, which is really all you need.

In Glaurung 1, IID at non-PV nodes did seem to help. In Glaurung 2, I have never been able to measure any difference, but it is possible that IID everywhere would still be useful at very slow time controls.

Tord

Hi Tord,

I would like to ask you one doubt I have regarding IID at non-pv nodes.

But doesn't it is redundant with null move searching ?

I try to expleing myself better. For what I have understood the big plus of null move, apart from the legacy of avoid searching not interesting nodes, is that it populates the history for the next moves.

After null moves search history is well populated and this helps in the following search _also_ in the case of moves that fail the null move test and so are researched.

So isn't IID just another way of populating the history?

Thanks
Marco

[Tord Romstad]

Hi Tord,

I would like to ask you one doubt I have regarding IID at non-pv nodes.

But doesn't it is redundant with null move searching ?

I try to expleing myself better. For what I have understood the big plus of null move, apart from the legacy of avoid searching not interesting nodes, is that it populates the history for the next moves.

After null moves search history is well populated and this helps in the following search _also_ in the case of moves that fail the null move test and so are researched.

Yes, the killer move found by the null move search is useful for the move ordering, but it is less likely to be optimal than the move found by an IID search. The killer move was found by the search of a position similar to, but not quite identical to the position on the board. A move found by a reduced-depth search of the current position is even more likely to be good. Whether this increased probability of an early beta cutoff is worth the expense of the IID search is of course not obvious.

Some programs allow two (but not three) consecutive null moves. With this technique, the null move searches do have almost the same effect as an IID search. Glaurung currently doesn't do this.

Tord