bob wrote:I have never seen that kind of result with MVV/LVA vs SEE. You can find old discussions on this topic on r.g.c.c back in the early 90's. I ran a bunch of tests and even distributed a version of Crafty where one could choose between SEE and MVV/LVA for q-search move ordering, and others ran lots of tests as well. The net outcome was that SEE produced a tree roughly 10% smaller over a large test set. But when SEE was augmented with the "cull losing captures in q-search idea" then the difference went up dramatically, reducing the size of the tree by 50% (after that original 10% reduction). Numerically, if MVV/LVA searched a tree of size 100,000,000 nodes, SEE would search 90,000,000 nodes. But if SEE was used to eliminate losing q-search captures completely, the tree size was reduced to 45,000,000 nodes.
I've _never_ seen MVV/LVA out-perform SEE, except for the occasional pathological case (atypical).
Strange how you seem to stop reading at the very point were you encounter the acronym MVV/LVA. That also happened in the thread the other month, where you went on fighting at nauseam what no one was actually claiming
First, read the following sentence, quoted verbatim from Tord's comments:
"However, among the winning and equal captures, MVV/LVA move ordering performs better than SEE move ordering, which is counter-intuitive to me. "
Now, please point out exactly _where_ I managed to misread something? Or maybe are you the one that did the misreading this time around???
I reacted specifically to the above sentence. Which, on the surface, contradicts everything I have ever found when comparing the two ordering strategies...
Tord does not say that MVV/LVA outperforms SEE. He says that it is better to order the good captures that way. To know what good captures are, SEE must already have been done on them. How else would you know what good captures are? You would not consider this MVV/LVA, as that has a very specific meaning since etcetcetc. But he does order the good captures such that those with the most valuable victim goes first, and amongst equal victims the least valuable attacker goes first, even if you don't want to call that MVV/LVA...
So you think he uses SEE to get a _real_ estimate of whether a capture wins or not, and then orders winning captures using MVV/LVA, adding more overhead? Even if that is what was implied, it seems contradictory to me. I have two captures to make:
QxR (wins a pawn because of RxQ RxR, two rooks for a queen)
RxN (wins a knight).
And somehow searching QxR first is going to be better?
I don't think so.
Pure SEE order is in general inferior, as about every one I talked to seems to know. I have also measured this myself, where you can beat the pure SEE ordering by about 30% by the more clever move ordering that Tord suggest.
Because my SEE is rather expensive, I do it slightly different than Tord: I first order the captures MVV/LVA, but than replace the primary sort key (the victim value) by the SEE value for the Higer x Lower captures. L x H or equal takes equal can never be bad captures, and if I am going to order the non-bad captures MVV/LVA anyway, there is no reason to SEE them at all if I can see that they are non-bad even without SEE.
Now that I can recognize threats from the null-move search I even refined this a little bit: I do not only replace MVV/LVA by SEE/LVA if victim<capturer, but also if victim<piece under threat. In addition I add the amount that the null-move score was below eval (the threat value) to captures that might solve the threat (i.e. captures of the attacker, or captures with the piece under threat). And I slip in that single non-capture safe withdrawal amongst the captures, with as sort key the threat value.
You can say that all you want, but pure SEE is not an inferior way to order captures. One can avoid SEE overhead here and there, since RxQ is good whether it is SEE evaluated or MVV/LVA evaluated, generally (there are exceptions to that obviously).
I certainly find it impossible that the MVV/LVA piled on top of SEE is a 30% improvement. However, I can run this test here easily enough on a few thousand positions, and see what it does. More to follow. But I doubt I am going to be surprised here...