No standard specification for Perft

[hgm]

If you want perft to be a representative measure of the speed of an engine it should indeed focus more on capture-only generation. Perthaps it would be useful to define a function perft(N, M) which does N ply of full-width search followed by M ply of captures only.

Most people use perft only for testing correctness, however, to see if they get the right numbers.

[Michael Sherwin]

If you want perft to be a representative measure of the speed of an engine it should indeed focus more on capture-only generation. Perthaps it would be useful to define a function perft(N, M) which does N ply of full-width search followed by M ply of captures only.

Most people use perft only for testing correctness, however, to see if they get the right numbers.

And it would be useful to have an accurate count of the capture only nodes as well.

[lucasart]

If you want perft to be a representative measure of the speed of an engine it should indeed focus more on capture-only generation. Perthaps it would be useful to define a function perft(N, M) which does N ply of full-width search followed by M ply of captures only.

Most people use perft only for testing correctness, however, to see if they get the right numbers.

And it would be useful to have an accurate count of the capture only nodes as well.

why?

perft is not a goal in itself. playing chess is the goal (or variants if that's your thing).

the only purpose of perft is to serve as unit test for the move generation (and move play/undo etc.).

in which valid use case do you need perft captures, that can't be verified by normal perft?

[Michael Sherwin]

If you want perft to be a representative measure of the speed of an engine it should indeed focus more on capture-only generation. Perthaps it would be useful to define a function perft(N, M) which does N ply of full-width search followed by M ply of captures only.

Most people use perft only for testing correctness, however, to see if they get the right numbers.

And it would be useful to have an accurate count of the capture only nodes as well.

why?

perft is not a goal in itself. playing chess is the goal (or variants if that's your thing).

the only purpose of perft is to serve as unit test for the move generation (and move play/undo etc.).

in which valid use case do you need perft captures, that can't be verified by normal perft?

If an engine has a separate capture generator it might be good to see if the engine produces correct node counts there as well. And like HGM said it would be a way of testing engine performance minus eval more realistically.

[hgm]

Exactly. If the engine uses a completely different move generator in QS, a perft of the full-width search would not test it at all.

For those who do want to use perft for comparing efficency of various move-generation algorithms and board representations: note that a real engine usually does not make the moves it generates in a leave node (and that most nodes are typically leaf nodes). It purely generates the moves to make sure none of those is worth making (i.e. one of the generated moves stands a chance of bringing the score above alpha).

[lucasart]

If you want perft to be a representative measure of the speed of an engine it should indeed focus more on capture-only generation. Perthaps it would be useful to define a function perft(N, M) which does N ply of full-width search followed by M ply of captures only.

Most people use perft only for testing correctness, however, to see if they get the right numbers.

And it would be useful to have an accurate count of the capture only nodes as well.

why?

perft is not a goal in itself. playing chess is the goal (or variants if that's your thing).

the only purpose of perft is to serve as unit test for the move generation (and move play/undo etc.).

in which valid use case do you need perft captures, that can't be verified by normal perft?

If an engine has a separate capture generator it might be good to see if the engine produces correct node counts there as well. And like HGM said it would be a way of testing engine performance minus eval more realistically.

Well, you must be doing it wrong, if you need to duplicate movegen code like this… Fix that instead of blaming perft.

[hgm]

Well, you must be doing it wrong, if you use the same move generator for a different purpose...

[Uri Blass]

If you want perft to be a representative measure of the speed of an engine it should indeed focus more on capture-only generation. Perthaps it would be useful to define a function perft(N, M) which does N ply of full-width search followed by M ply of captures only.

Most people use perft only for testing correctness, however, to see if they get the right numbers.

Does Captures only include promotions and if yes does it include all promotions or only promotions to queen?

I am not sure if it is the best idea to have a capture generator that include all captures.
For example maybe it is better to have a capture generator that does not generate QxP or RxP when the pawn is defended by another pawn.

[Joost Buijs]

If you want perft to be a representative measure of the speed of an engine it should indeed focus more on capture-only generation. Perthaps it would be useful to define a function perft(N, M) which does N ply of full-width search followed by M ply of captures only.

Most people use perft only for testing correctness, however, to see if they get the right numbers.

Does Captures only include promotions and if yes does it include all promotions or only promotions to queen?

I am not sure if it is the best idea to have a capture generator that include all captures.
For example maybe it is better to have a capture generator that does not generate QxP or RxP when the pawn is defended by another pawn.

It depends, usually generating all captures is faster than generating only winning captures. It is probably better to handle this with SEE().

My engine includes promotions in the capture generator, but I can choose which pieces to promote to. In quiescence I only promote to queen, and in my regular search I never promote to bishop because that is clearly a waste of time.

In my opinion perft() is a handy tool to check whether move generation and move do/undo are correctly functioning, and as a bonus it tells you also something about the move system performance. I don't see much speed difference between bulk counting or not because checking move legality costs considerably more time as move do/undo (at least in my engine this is the case).

[mar]

in my regular search I never promote to bishop because that is clearly a waste of time.

Is this really worth it? I always consider all legal moves in search and never even considered doing anything like that. Besides there are other ways to avoid wasting time on bishop underpromotions rather than completely pruning them.
There is a really really tiny fraction of games where it could matter, of course nothing that can be reliably measured.
And for analysis of course (but true, nobody would use my engine for analysis anyway