Ok, then there's a reasoning behind it. I thought that maybe you hadn't considered it.ZirconiumX wrote:You *can*, but the overhead of doing it at low depths starts to outweigh its benefits. Dorpsgek is an incredibly slow program at ~700knps. An extra 2 million nodes of overhead costs Stockfish little, but it costs Dorpsgek a lot more.elpapa wrote:Yes, but you can still do null move pruning, even if the remaining depth is less than 4.ZirconiumX wrote:Nullmove reduces by R + 1. My R is 3, so 3 + 1 = 4. I'll fiddle about with it after this latest test (requiring 4 or more pieces for the side to move) runs to completion.elpapa wrote:How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.ZirconiumX wrote:if (depth >= 4 && nodetype != NodeTypePV && !incheck && PopCount(b->sidemask[b->side] > 2)) {
[/code]
Nullmove bugs
Moderators: hgm, Rebel, chrisw
-
- Posts: 211
- Joined: Sun Jan 18, 2009 11:27 pm
- Location: Sweden
- Full name: Patrik Karlsson
Re: Nullmove bugs
-
- Posts: 349
- Joined: Sat Aug 06, 2016 8:31 pm
- Location: United States
Re: Nullmove bugs
Question about this. Does this mean the benefit of only checking the null move in eval > beta cases outweighs the cost of calculating the static evaluation at every node (vs just qsearch nodes)?elcabesa wrote: 2: aren't you trying calling null move pruning when it's not necessary? for example when static_eval << beta
-
- Posts: 1334
- Joined: Sun Jul 17, 2011 11:14 am
Re: Nullmove bugs
The proof will lie in the Elo, I suppose.
Though really I should do something about the performance of it. If TSCP had a smarter search, it would outsearch Dorpsgek easily.
While a conversion to Make/Unmake would probably be a good idea, there is an awful lot of information and board state that needs to be updated, so I suspect the recalculation may offset the memory bandwidth.
Though really I should do something about the performance of it. If TSCP had a smarter search, it would outsearch Dorpsgek easily.
While a conversion to Make/Unmake would probably be a good idea, there is an awful lot of information and board state that needs to be updated, so I suspect the recalculation may offset the memory bandwidth.
Some believe in the almighty dollar.
I believe in the almighty printf statement.
I believe in the almighty printf statement.
-
- Posts: 94
- Joined: Thu Feb 27, 2014 8:19 pm
Re: Nullmove bugs
As a data point, Sunfish is only around 30knps and it still benefits from doing null moves all the way down to depth=1. For slow engines as much as fast, pruning is key.ZirconiumX wrote: You *can*, but the overhead of doing it at low depths starts to outweigh its benefits. Dorpsgek is an incredibly slow program at ~700knps. An extra 2 million nodes of overhead costs Stockfish little, but it costs Dorpsgek a lot more.
-
- Posts: 1334
- Joined: Sun Jul 17, 2011 11:14 am
Re: Nullmove bugs
Well the "4 or more pieces to nullmove" patch is a slight loss, but now within error bounds.
I suppose you're right, Thomas.
Now I'll see if lowering the depth requirement helps.
Code: Select all
Score of New vs Old: 1311 - 1343 - 719 [0.495] 3373
ELO difference: -3.30 +/- 10.39
SPRT: llr -2.95, lbound -2.94, ubound 2.94 - H0 was accepted
Now I'll see if lowering the depth requirement helps.
Some believe in the almighty dollar.
I believe in the almighty printf statement.
I believe in the almighty printf statement.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Nullmove bugs
This is wrong. NULL-MOVE should NOT "add extra overhead". It reduces the size of the tree, which is why we use it. Otherwise it would be worthless.ZirconiumX wrote:You *can*, but the overhead of doing it at low depths starts to outweigh its benefits. Dorpsgek is an incredibly slow program at ~700knps. An extra 2 million nodes of overhead costs Stockfish little, but it costs Dorpsgek a lot more.elpapa wrote:Yes, but you can still do null move pruning, even if the remaining depth is less than 4.ZirconiumX wrote:Nullmove reduces by R + 1. My R is 3, so 3 + 1 = 4. I'll fiddle about with it after this latest test (requiring 4 or more pieces for the side to move) runs to completion.elpapa wrote:How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.ZirconiumX wrote:if (depth >= 4 && nodetype != NodeTypePV && !incheck && PopCount(b->sidemask[b->side] > 2)) {
[/code]
-
- Posts: 1334
- Joined: Sun Jul 17, 2011 11:14 am
Re: Nullmove bugs
I was referring to null move fail lows.
Also, if somebody found a way of ordering moves perfectly, I suspect people would use that instead of theoretically unsound pruning that causes imperfections.
But that's besides the point.
Current SPRT progress on depth >= 3:
We have a positive elo result! But it's nothing earth shattering. More testing to be done later.
Also, if somebody found a way of ordering moves perfectly, I suspect people would use that instead of theoretically unsound pruning that causes imperfections.
But that's besides the point.
Current SPRT progress on depth >= 3:
Code: Select all
Score of New vs Old: 837 - 761 - 632 [0.517] 2230
ELO difference: 11.85 +/- 12.20
SPRT: llr 1.76, lbound -2.94, ubound 2.94
Some believe in the almighty dollar.
I believe in the almighty printf statement.
I believe in the almighty printf statement.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Nullmove bugs
Ordering is not the issue here, it is effort, as in search space. null-move searches a MUCH smaller tree than a single normal move would search, because of the reduced depth. The null-move observation, as defined by Beal, actually works and is not nearly as speculative in nature as forward-pruning approaches.ZirconiumX wrote:I was referring to null move fail lows.
Also, if somebody found a way of ordering moves perfectly, I suspect people would use that instead of theoretically unsound pruning that causes imperfections.
But that's besides the point.
Current SPRT progress on depth >= 3:We have a positive elo result! But it's nothing earth shattering. More testing to be done later.Code: Select all
Score of New vs Old: 837 - 761 - 632 [0.517] 2230 ELO difference: 11.85 +/- 12.20 SPRT: llr 1.76, lbound -2.94, ubound 2.94
Last time I tested, removing null-move cost me 40 Elo. Removing LMR cost me 40 Elo. Removing both cost me 120 Elo. That has probably increased over the last few years...
-
- Posts: 349
- Joined: Sat Aug 06, 2016 8:31 pm
- Location: United States
Re: Nullmove bugs
Is the nodetype != NodeTypePV condition a requirement of null move pruning? I ask because when I added that restriction, my search became painfully slow.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Nullmove bugs
Shouldn't matter that much. There aren't that many PV nodes, but if the null-move fails high (which might get backed up to the root and trigger a research with a larger aspiration window) it might be costly, especially if the fail-high is undeserved. I guess it will depend a lot on how you handle your aspiration window and other minor details.zenpawn wrote:Is the nodetype != NodeTypePV condition a requirement of null move pruning? I ask because when I added that restriction, my search became painfully slow.
EDIT: I just tried with Jazz; allowing null-move in the PV adds about 2% to the node count for a fixed depth search (NPS is constant, so the time to depth increases by a similar 2%). Seems it should just be a speed optimisation to not do it in PV nodes.