New engine: LazySMP

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

Ras
Posts: 2582
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: New engine: LazySMP

Post by Ras »

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.

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.
Rasmus Althoff
https://www.ct800.net
User avatar
Guenther
Posts: 4712
Joined: Wed Oct 01, 2008 6:33 am
Location: Regensburg, Germany
Full name: Guenther Simon

Re: New engine: LazySMP

Post by Guenther »

Ras wrote: Wed Oct 30, 2024 11:00 am ...snip...
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.
Back to some facts, first snippet from the OP himself for startpos showed around 8.5 Mnps, while a later pgn file also from the OP suddenly just showed around 4.4 Mnps (surprisingly using FRC positions for a test) , so it is completely unkown and also hardware was never mentioned too.
And BTW the 10 Mnps just come from you, even the OP only claimed about 9 Mnps, so much about some numbers... quite some inflation with a million here or there.

viewtopic.php?p=969453#p969453
viewtopic.php?p=970028#p970028
https://rwbc-chess.de

[Trolls n'existent pas...]
Ras
Posts: 2582
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: New engine: LazySMP

Post by Ras »

Guenther wrote: Wed Oct 30, 2024 12:04 pmAnd BTW the 10 Mnps just come from you
This is not true:
LazySMP wrote: Fri Oct 25, 2024 2:32 amAlthough my engine is 1800 elo, but it is very fast. My engine speed is about 10 million NPS on a single thread.
Rasmus Althoff
https://www.ct800.net
User avatar
Guenther
Posts: 4712
Joined: Wed Oct 01, 2008 6:33 am
Location: Regensburg, Germany
Full name: Guenther Simon

Re: New engine: LazySMP

Post by Guenther »

Ras wrote: Wed Oct 30, 2024 12:18 pm
Guenther wrote: Wed Oct 30, 2024 12:04 pmAnd BTW the 10 Mnps just come from you
This is not true:
LazySMP wrote: Fri Oct 25, 2024 2:32 amAlthough my engine is 1800 elo, but it is very fast. My engine speed is about 10 million NPS on a single thread.
I didn't read all dozens of posts of the OP entity, but he started with this in his first post:
(so all the number bending/stretching/vagueness comes from the OP entity, this fits more, sorry that I thought you were involved in this mess)
Currently there are only Windows and Mac versions for my chess engine. I'm not familiar with computer ratings, but based on FIDE ratings, I'd guess my engine is currently at 2300 Elo. Although my engine is not strong, it is very fast. My engine speed is about 9 million NPS on a single thread.
viewtopic.php?p=969453#p969453
https://rwbc-chess.de

[Trolls n'existent pas...]
User avatar
hgm
Posts: 28144
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: New engine: LazySMP

Post by hgm »

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.
Ras
Posts: 2582
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: New engine: LazySMP

Post by Ras »

hgm wrote: Wed Oct 30, 2024 1:47 pmPerft has always been utterly useless to me for verifying correctness in gameplay
I found a move generation bug that had been there for years already in NG-Play where I forked from. That was when a castling-enabled rook was captured and then re-captured by another rook (i.e. along the vertical line). Then the castling rights would still be set. Probably not that important in gameplay, given that it had been there for so long, but still a correctness issue.
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.
Correct - it does so with pretty inefficient ray scanner loops and dedicated knight offset checks (but still faster than move generation using the same loop approach).
Are you claiming now you have a perft that does 80M move generations per second?
No. 80M legal perft end nodes per second. Given the high branching factor, we can just ignore the earlier part of the tree. Means, 80M moves can be generated (but not executed) per second.
Compared to that 10M looks indeed fast.
Depends on how many of the generated moves actually make it into a node, which in turn depends on how good the static move ordering works together with pruning (both safe and unsafe).
Rasmus Althoff
https://www.ct800.net
User avatar
hgm
Posts: 28144
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: New engine: LazySMP

Post by hgm »

Ras wrote: Wed Oct 30, 2024 2:27 pm Correct - it does so with pretty inefficient ray scanner loops and dedicated knight offset checks (but still faster than move generation using the same loop approach).
In practice this turned out to be not so bad at all, if you start the scan at the King. Because usually it bumps into a piece immediately.
No. 80M legal perft end nodes per second. Given the high branching factor, we can just ignore the earlier part of the tree. Means, 80M moves can be generated (but not executed) per second.
Right. So that is what I would call slightly over 2Mnps.
Depends on how many of the generated moves actually make it into a node, which in turn depends on how good the static move ordering works together with pruning (both safe and unsafe).
I don't get that. The speed of move generation should be independent from what you do with the moves. Otherwise it would be the speed of move usage, not that of move generation. In the leaves by definition no move makes it to a new node.
Ras
Posts: 2582
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: New engine: LazySMP

Post by Ras »

hgm wrote: Wed Oct 30, 2024 3:02 pmI don't get that. The speed of move generation should be independent from what you do with the moves.
The benchmarking is not independent because gameplay NPS only count up once you enter a new node, and you do so by making a (legal) move. The more moves you use out of a generated list, the fewer move generation calls you need for the same resulting NPS. In turn, you need to look at fewer moves if the static move ordering is good - things like late move pruning in particular have an impact here.
Rasmus Althoff
https://www.ct800.net
User avatar
hgm
Posts: 28144
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: New engine: LazySMP

Post by hgm »

Ras wrote: Wed Oct 30, 2024 3:34 pm
hgm wrote: Wed Oct 30, 2024 3:02 pmI don't get that. The speed of move generation should be independent from what you do with the moves.
The benchmarking is not independent because gameplay NPS only count up once you enter a new node, and you do so by making a (legal) move. The more moves you use out of a generated list, the fewer move generation calls you need for the same resulting NPS. In turn, you need to look at fewer moves if the static move ordering is good - things like late move pruning in particular have an impact here.
No. Because after every move you make you would again do a move generation to see if you should search even deeper. When futility pruning would be perfect, the number of make/unmakes would be the number of move generations minus 1. (Because there is no make/unmake to the root.) This is not dependent on the fraction of generated moves that would be considered worth searching.
Ras
Posts: 2582
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: New engine: LazySMP

Post by Ras »

hgm wrote: Wed Oct 30, 2024 3:47 pmNo. Because after every move you make you would again do a move generation to see if you should search even deeper.
I'm speaking about the breadth, you're speaking about depth. On the same depth level, you would not do another move generation if you want to examine the second move in your move list. You would get that one for free. Compare that to an approach where you ever only examine one move per depth level, then you don't get to reuse the move list for a second move at that depth. The same NPS then needs more move generation calls.
Rasmus Althoff
https://www.ct800.net