We need to scrap Perft()

[Mike Sherwin]

And replace it with Accut() and Speedt(). At least for pseudo legal engines. They both should have their own set of numbers to verify that they are working properly. In Accut() speed can be measured but primarily we are interested in accuracy. In Speedt() we care about accuracy but not so much as the raw speed of the move generators and Make()/Unmake(). The biggest problem with Perft() on pseudolegal engines is they are forced to make calls to InCheck() when they are not designed to work that way. And Speedt() would end every leaf with a call to Quiessence(). Nothing defines an engines raw speed more than the captures only generator. And yet it is never considered in calculating speed!

[dangi12012]

And replace it with Accut() and Speedt(). At least for pseudo legal engines. They both should have their own set of numbers to verify that they are working properly. In Accut() speed can be measured but primarily we are interested in accuracy. In Speedt() we care about accuracy but not so much as the raw speed of the move generators and Make()/Unmake(). The biggest problem with Perft() on pseudolegal engines is they are forced to make calls to InCheck() when they are not designed to work that way. And Speedt() would end every leaf with a call to Quiessence(). Nothing defines an engines raw speed more than the captures only generator. And yet it is never considered in calculating speed!

Well first of all if your movegenerator is pseudolegal you are losing 50% of performance at least. You spend time to make unmake a move thats not possible. Why not make the case that every movegen should be legal in the first place? That would make it a lot faster.

I dont see you point? In a bitboard movegen the difference between a moves = uint64_t. and only moves that are taking is: taking = moves & enemies
So literally a single AND instruction. Why would you create a different metric for that?

[R. Tomasi]

And replace it with Accut() and Speedt(). At least for pseudo legal engines. They both should have their own set of numbers to verify that they are working properly. In Accut() speed can be measured but primarily we are interested in accuracy. In Speedt() we care about accuracy but not so much as the raw speed of the move generators and Make()/Unmake(). The biggest problem with Perft() on pseudolegal engines is they are forced to make calls to InCheck() when they are not designed to work that way. And Speedt() would end every leaf with a call to Quiessence(). Nothing defines an engines raw speed more than the captures only generator. And yet it is never considered in calculating speed!

A very interesting idea, in principle. I kind of struggle with the leaves calling QS. QS implementation may vary widely accross engines (some search all captures, some consider pawn-moves to be tactical, some stop QS after a few plies and resort to SEE, some engines may examine checking-sequences and some don't, etc.). Unless you specify exactly how the QS part has to be done results will not be comparable.

[Chessnut1071]

And replace it with Accut() and Speedt(). At least for pseudo legal engines. They both should have their own set of numbers to verify that they are working properly. In Accut() speed can be measured but primarily we are interested in accuracy. In Speedt() we care about accuracy but not so much as the raw speed of the move generators and Make()/Unmake(). The biggest problem with Perft() on pseudolegal engines is they are forced to make calls to InCheck() when they are not designed to work that way. And Speedt() would end every leaf with a call to Quiessence(). Nothing defines an engines raw speed more than the captures only generator. And yet it is never considered in calculating speed!

Don't you need to also classify them by how much information you take for the pseudo move list. For example, I include the 5 immediately available variables: piece, move, capture or protected, move direction and check. A lot of these cowboys take the first two. I also have discovered check, ent passant and pin before I get the legal move. I think it's the final product, legal moves, that really needs to be compared. Faster pseudo move engines will probably give back some off that speed to find the legal subset, unless they're giving up accuracy for speed.

[Ras]

Well first of all if your movegenerator is pseudolegal you are losing 50% of performance at least. You spend time to make unmake a move thats not possible.

First, that's not true because most of the generated moves are never made. In an actual engine, you generate them to select the best one as per your move sorting and aim for an early beta cut-off. Second, you don't need make/in-check for the vast majority of the moves, i.e. moves other than king moves, en passant, or get-out-of-check moves, all of which are rather rare.

Why not make the case that every movegen should be legal in the first place?

Because in an actual engine, you would waste that effort on moves that will never even be tried.

[dangi12012]

Well first of all if your movegenerator is pseudolegal you are losing 50% of performance at least. You spend time to make unmake a move thats not possible.

First, that's not true because most of the generated moves are never made. In an actual engine, you generate them to select the best one as per your move sorting and aim for an early beta cut-off. Second, you don't need make/in-check for the vast majority of the moves, i.e. moves other than king moves, en passant, or get-out-of-check moves, all of which are rather rare.

Why not make the case that every movegen should be legal in the first place?

Because in an actual engine, you would waste that effort on moves that will never even be tried.

You generate them. You put them into the movelist. You sort the bigger movelist. Sometimes you even get to the point where you test them.
Worst of all you need a seperate "IsLegal" call for every move. Even when they would legal to begin with.

So its not an argument that holds to scrutiny. It needs much more useless cpu time.

[Ras]

So its not an argument that holds to scrutiny.

It does, and most engines use pseudo-legal generators because doing the legality check for moves that you will never do anyway, but only need for sorting, would not only move the waste from one place elsewhere, but also be slower overall. Even Stockfish uses pseudo-legal moves in most places except e.g. at root or in special conditions. You're certainly free to commit a patch to Stockfish for improving its performance via a fully legal move generator.

[R. Tomasi]

Thinking about all this, I really am convinced that Mike has a point when he says that some sort of "perft" for QS would be good. I can only speak for myself, but I think having perft-like numbers that include all possible capturing sequences that are possible at the (classical perft) leaves would be good and helpful. I just think that simply doing a plain QS at the leaves will not provide that. My engine certainly does not explore every possible capturing sequence in QS, and I would think that many other engines don't either.

[R. Tomasi]

Well first of all if your movegenerator is pseudolegal you are losing 50% of performance at least. You spend time to make unmake a move thats not possible.

First, that's not true because most of the generated moves are never made. In an actual engine, you generate them to select the best one as per your move sorting and aim for an early beta cut-off. Second, you don't need make/in-check for the vast majority of the moves, i.e. moves other than king moves, en passant, or get-out-of-check moves, all of which are rather rare.

Why not make the case that every movegen should be legal in the first place?

Because in an actual engine, you would waste that effort on moves that will never even be tried.

You generate them. You put them into the movelist. You sort the bigger movelist. Sometimes you even get to the point where you test them.
Worst of all you need a seperate "IsLegal" call for every move. Even when they would legal to begin with.

So its not an argument that holds to scrutiny. It needs much more useless cpu time.

Why do you think that pseudo-legal movegen engines must generate _all_ moves at once? Many engines generate moves in batches. Like winning captures first, then quiet moves, then losing captures. Or maybe completely different than that. But still in batches. Such that we save the time of move generation for a good bunch of moves completely, because they come after a cut-off. I actually do intend to switch to fully legal movegen at some point, but I would not even dream about getting twice the performance. That's simply a pipe-dream.

[Ras]

Many engines generate moves in batches.

The easiest and probably most bang for the buck trick is not generating moves if you have a validated hash move because that has at least 90% odds of generating a beta cut-off.