We need to scrap Perft()

[Sopel]

"I think you know that, too". I'm not so sure of this. I don't think he understands the amount of effort required to do 100.00%, vs 99.99%. He acts like the process of make-verify-unmake is entirely useless, but fails to recognize that the effort required to go around this is greater (as it stands, in practice in engines, like I stated originally). More code, and more instructions, and more operations, are required in order to ensure verified moves are legal.

Its extremely foolish and arrogant to assert that what people have been doing for decades is wrong and easily fixed -- ALTHOUGH IT HAPPENS FROM TIME TO TIME TO BE THE CASE. If this is such a case, then show it. Pretty simple. Modify an engine, demonstrate the speedup, post results and then flex on decades of hobbyists, computer scientists, and chess programmers missing what you see so clearly.

Put up or shut up.

In text form normal messages may seem like snippish or arrogant but thats because its text form. Dont assume any emotions on my side.
What I say is this (and it is self evident)
make-verify-unmake is longer and wastes cpu cycles compared to:
make-unmake

That is clear as day. If you say otherwise its you who would have to back it up.
On that point: More code, and more instructions, and more operations, are required in order to ensure verified moves are legal.
Thats what my movegen proved wrong. All you need is a single and instruction to resolve all pins on the board. And one AND instruction to resolve all check-evasions.

An engine has to call "ISLEGAL" on every single node it walks. And that is 30 Million calls/s with complex code behind it. Thats not nothing.
I dont know how you can even pretend that there is a discussion to be made...

There's plenty of examples where more code is faster than less code. You're being pretty ignorant. No one will be convinced by your hand-waving arguments.

[dangi12012]

There's plenty of examples where more code is faster than less code. You're being pretty ignorant. No one will be convinced by your hand-waving arguments.

Sopel is a confirmed forum troll. When he enteres a discussion you know every value is lost.

So I promise we stay on topic now:
Perft() vs "And Speedt() would end every leaf with a call to Quiessence()"

But as was said before Quiessence() is not a standard piece of code..
So if Quiessence() would be standardised is OPs idea good?

[R. Tomasi]

Sopel is a confirmed forum troll. When he enteres a discussion you know every value is lost.

Um... he's not. Plain and simple. Failing to acknoledge your feelings of grandeur isn't trolling. It's just pointing out the obvious.

[R. Tomasi]

Perft() vs "And Speedt() would end every leaf with a call to Quiessence()"

But as was said before Quiessence() is not a standard piece of code..
So if Quiessence() would be standardised is OPs idea good?

I think just replace QS with a cperft (exactly like perft, but captures-only and dig deeper until no more captures are available).

[dangi12012]

Perft() vs "And Speedt() would end every leaf with a call to Quiessence()"

But as was said before Quiessence() is not a standard piece of code..
So if Quiessence() would be standardised is OPs idea good?

I think just replace QS with a cperft (exactly like perft, but captures-only and dig deeper until no more captures are available).

So normal perft + capture expansion for every leaf node.
Why is it good to standardize that? But I see the value there. You dont test movegen only but actual QS for every leaf too.

[Ras]

Thats exactly my point. You literally bloat the thing you sort for no reason

No, it isn't, because most moves are actually legal.

Sorting is expensive NlogN.

No, it isn't. First, Big-Oh is meaningless for the typical list length of move lists. Second, most engines don't even do NlogN sorting, but have a move picker like SF, effectively a selection sort, because the first move already cuts in most cases. That's the point of move sorting.

Makemove / Unmake on an not legal move is expensive.

No, it isn't. Most moves are not illegal to begin with, in particular the hash moves where you don't even generate a move list.

Function calls are expensive.

No, they aren't. Thanks to LTO and inlining.

As I said, you are free to prove your claims just with a patch to SF. As long as it is functionally identical, but just faster, you don't need some 100k games to prove its worth because identical but faster is automatically better.

[R. Tomasi]

Perft() vs "And Speedt() would end every leaf with a call to Quiessence()"

But as was said before Quiessence() is not a standard piece of code..
So if Quiessence() would be standardised is OPs idea good?

I think just replace QS with a cperft (exactly like perft, but captures-only and dig deeper until no more captures are available).

So normal perft + capture expansion for every leaf node.
Why is it good to standardize that?

Well that's my suggestion. I'm happy to discuss alternatives. My reasoning is the following:

Perft is first and foremost a tool to test the correctness of move generators. It's vital, and virtually everyone who is writing a chess engine uses it to very the movegen. But most engines have special movegens for captures/QS. It would be really nice to have the equivalent of perft for testing those. Since QS isn't standardized, I would think just copy-pasting the perft routine one has and modifying it to only look at/generate captures and not stop at a specific depth. Would probably take less than 5mins to implement in most engines and might help lots with tracking movegen bugs in QS.

[Ras]

might help lots with tracking movegen bugs in QS.

I don't think so because first, QS is not standardised, and second, not even the moves are standardised. For example, many engines don't generate underpromotions in QS. The consequence is that you don't have reference result numbers that you could verify against.

[R. Tomasi]

might help lots with tracking movegen bugs in QS.

I don't think so because first, QS is not standardised, and second, not even the moves are standardised. For example, many engines don't generate underpromotions in QS. The consequence is that you don't have reference result numbers that you could verify against.

Indeed, that's why I suggest doing it the way I did.

[Ras]

Indeed, that's why I suggest doing it the way I did.

OK, that would solve the problem how to obtain reference results - but at the expense of still not being what is done in real QS, even discounting pruning and just looking at the move generators. See the "no underpromotions in QS" example. So that would still not test how moves are generated in QS, which was the objective of the proposal.