MVV/LVA move ordering and qSearch

Discussion of chess software programming and technical issues.

Moderator: Ras

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: MVV/LVA move ordering and qSearch - real data - more dat

Post by bob »

bob wrote:Running the test with mvv/lva+SEE in normal search, but pure SEE ordering in q-search. Appear to be dead even. SEE is very slightly slower (since it is applied before sorting moves, where in MVV/LVA SEE is deferred until just before a move is actually searched), mvv/lva+see in q-search produces slightly larger trees. It looks like the gain here is in the normal search rather than in the q-search. Have to wait until the tests complete for confirmation, but some quick tests on specific positions shows very little difference.

This is becoming quite convincing that the gain here is due to eliminating a heavy piece with the increased capture potential it has, rather than because QxQ is better than PxN in general.
OK, jury is back in. MVV/LVA in q-search is no better than normal ordering using plain SEE. Looks like the primary advantage here seems to be that MVV/LVA in the normal search reduces the resulting tree size to get a quicker cutoff.

Think I am done with this topic finally, on to the next.
frankp
Posts: 233
Joined: Sun Mar 12, 2006 3:11 pm

Re: MVV/LVA move ordering and qSearch - real data - more dat

Post by frankp »

bob wrote: OK, jury is back in. MVV/LVA in q-search is no better than normal ordering using plain SEE. Looks like the primary advantage here seems to be that MVV/LVA in the normal search reduces the resulting tree size to get a quicker cutoff.

Think I am done with this topic finally, on to the next.
Are you saying that your test show MVV/LVA (alone) is better than SEE or mixed MVV/LVA and SEE in the main (non Qsearch)?

I do a simple score first capture-recapture if > 0, or try SEE
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: MVV/LVA move ordering and qSearch - real data - more dat

Post by bob »

frankp wrote:
bob wrote: OK, jury is back in. MVV/LVA in q-search is no better than normal ordering using plain SEE. Looks like the primary advantage here seems to be that MVV/LVA in the normal search reduces the resulting tree size to get a quicker cutoff.

Think I am done with this topic finally, on to the next.
Are you saying that your test show MVV/LVA (alone) is better than SEE or mixed MVV/LVA and SEE in the main (non Qsearch)?

I do a simple score first capture-recapture if > 0, or try SEE
No. In the main search, moves sorted by MVV/LVA, and screeded by SEE is a little better. Not huge, but better. The advantage is that (a) MVV/LVA removes heavy pieces first while (b) SEE is used to avoid searching those moves that appear to lose material outright (Q x defended rook rather than knight takes undefended pawn, as an example). Those moves still get searched, just not in the capture part of the search. Doing this in the q-search seems to have no benefit at all I can measure. I use the above since I do the same thing in all parts of the search, which makes the code look a little more understandable, but using pure SEE scores to order in the q-search doesn't do anything. It is a little slower, but the trees are a little smaller. Hence no gain. But in the normal search, there is a definite gain, just not a big one.