Ras wrote: ↑Wed Oct 30, 2024 11:00 am
hgm wrote: ↑Wed Oct 30, 2024 8:43 amA perft with bulk counting is much more similar to an engine search: the branches there also end in move generation.
That depends on how the engine determines the legality of a move. If that is done via make / check verification / unmake, or via generating reply moves and seeing whether one of them captures the king, then this also is done at the perft leaves simply because the engine doesn't
have another way that would enable bulk counting. It also doesn't make sense to use a different method for perft than for gameplay because then perft is mostly pointless, given that it would be unsuited to verify the correctness of gameplay.
Indeed, this is why perft in micro-Max would be excessively slow (and even then produce wrong values because it does not support underpromotion). So I never implemented it. Perft has always been utterly useless to me for verifying correctness in gameplay, even in engines where I did try it. Because an engine does many things other than generating moves. In particular I have seen engines blunder because of move errors caused by sorting, or premature update of the killer slots. Not to mention that for most engines I have written correct perft values are not even known.
But all that is really a bit off-topic: it is a safe bet that the perft you quote the 35Mnps for does not do legality verification through move generation testing for king capture.
You showed that make / check / unmake in perft leaves isn't representative for gameplay NPS, given that e.g. MVV-LVA in quiescence often cuts after the first move. To circle back to how that started, then the relevant comparison isn't 35MNPS (perft), but 80MNPS, so that is even more drastic relative to the claimed 10MNPS in gameplay being due to a super fast move generator.
It is not just a matter of early cutoffs. Leaves in search typically generate moves just for the reason of concluding none of those is a capture, or that all remaining captures are bad or futile. They would not know that without first generating them. Only a stand-pat cutoff would prevent move generation, but futility pruning causes this to almost never happen. So that these fast 'nodes' are not counted either.
Are you claiming now you have a perft that does 80M move generations per second? (As opposed to generating 80M moves/sec?) If not, I don't understand your argument. To put a claim for fast move generation in perspective one should compare it with measurements of other move generators. Not with thinks that are orders of magnitude faster, but in a poor design could have been replaced by move generations. So the question has been from the outset: how many move generations per second you can do? The perft you quoted probably only does ~1M per second, assuming the average leaf has 35 moves. Compared to that 10M looks indeed fast.