We need to scrap Perft()

[dangi12012]

You are objectively wrong -- or at least no one else in the computer chess world has figured out how to make using a fully legal move generator faster than the alternative.

Please use precice language. Objective is a word you have to back up with claims and studies which you didnt. Its your opinion. Absence of a an elo gaining branch for an alternative movegen is neither proof nor evidence against the validity. SF devs discussed it but increasing movegen speed by even 20% gains less than 3 Elo. So as long as tinkering elsewhere brings more elo/manhour that has the priority.

Yeah well... you claim 100% increase, not 20%. I'm pretty sure the SF team would merge a 3 ELO gain nevertheless. But if you talk about backing up claims, I'd say it's you who should back up your claim

I already did. You can try - but wont be able to invent a faster movegen than mine. Ethereal wants to have an IsLegal call for every move. I say its faster without.
Having a function call vs having none is not a "claim" or something i need to back up which is faster... I think you know that too

[AndrewGrant]

You are objectively wrong -- or at least no one else in the computer chess world has figured out how to make using a fully legal move generator faster than the alternative.

Please use precice language. Objective is a word you have to back up with claims and studies which you didnt. Its your opinion. Absence of a an elo gaining branch for an alternative movegen is neither proof nor evidence against the validity. SF devs discussed it but increasing movegen speed by even 20% gains less than 3 Elo. So as long as tinkering elsewhere brings more elo/manhour that has the priority.

Yeah well... you claim 100% increase, not 20%. I'm pretty sure the SF team would merge a 3 ELO gain nevertheless. But if you talk about backing up claims, I'd say it's you who should back up your claim

I already did. You can try - but wont be able to invent a faster movegen than mine. Ethereal wants to have an IsLegal call for every move. I say its faster without.
Having a function call vs having none is not a "claim" or something i need to back up which is faster... I think you know that too

I, every user of this forum, and all of the Stockfish contributers, are too daft to do it. Grace us with your knowledge, and show us how to speed up our engines so easily as you say.

[R. Tomasi]

You are objectively wrong -- or at least no one else in the computer chess world has figured out how to make using a fully legal move generator faster than the alternative.

Please use precice language. Objective is a word you have to back up with claims and studies which you didnt. Its your opinion. Absence of a an elo gaining branch for an alternative movegen is neither proof nor evidence against the validity. SF devs discussed it but increasing movegen speed by even 20% gains less than 3 Elo. So as long as tinkering elsewhere brings more elo/manhour that has the priority.

Yeah well... you claim 100% increase, not 20%. I'm pretty sure the SF team would merge a 3 ELO gain nevertheless. But if you talk about backing up claims, I'd say it's you who should back up your claim

I already did. You can try - but wont be able to invent a faster movegen than mine. Ethereal wants to have an IsLegal call for every move. I say its faster without.
Having a function call vs having none is not a "claim" or something i need to back up which is faster... I think you know that too

You did not, because your movegen is totally useless in the context of an actual engine - as has already been pointed out to you about a million times here on these boards

And if you claim that fully legal movegen is 100% faster for an actual engine (as you did in your first post in this thread), you better back that up. It's not about a single function call, it's about the total impact on the engine. I think you know that, too.

[Ras]

I already did. You can try - but wont be able to invent a faster movegen than mine. Ethereal wants to have an IsLegal call for every move. I say its faster without.

That's because everyone else is developing a full-blown chess engine while you have a standalone move generator for perft. As already explained in this thread, the main difference is that perft needs to make/unmake or at least count every legal move while real chess engines prune most of the moves. If an engine has a branching factor of 3 while a chess position has 30 moves on average, it means that 90% of the moves are never tried. For these 90%, it doesn't matter whether they are fully legal. Investing any effort into these 90% is a waste of time. Now, also consider that most pseudo-legal moves are actually legal, so there isn't much effort to be saved with avoiding to copy non-legal moves into the move list.

[AndrewGrant]

You are objectively wrong -- or at least no one else in the computer chess world has figured out how to make using a fully legal move generator faster than the alternative.

Please use precice language. Objective is a word you have to back up with claims and studies which you didnt. Its your opinion. Absence of a an elo gaining branch for an alternative movegen is neither proof nor evidence against the validity. SF devs discussed it but increasing movegen speed by even 20% gains less than 3 Elo. So as long as tinkering elsewhere brings more elo/manhour that has the priority.

Yeah well... you claim 100% increase, not 20%. I'm pretty sure the SF team would merge a 3 ELO gain nevertheless. But if you talk about backing up claims, I'd say it's you who should back up your claim

I already did. You can try - but wont be able to invent a faster movegen than mine. Ethereal wants to have an IsLegal call for every move. I say its faster without.
Having a function call vs having none is not a "claim" or something i need to back up which is faster... I think you know that too

You did not, because your movegen is totally useless in the context of an actual engine - as has already been pointed out to you about a million times here on these boards

And if you claim that fully legal movegen is 100% faster for an actual engine (as you did in your first post in this thread), you better back that up. It's not about a single function call, it's about the total impact on the engine. I think you know that, too.

"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.

[dangi12012]

"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...

[Ras]

I dont know how you can even pretend that there is a discussion to be made...

30M/s is for the moves that are tried. With 90% pruning rate, you're looking at additional effort for 300M/s, that's why. It seems you still don't get the difference between an engine and a pure move gen.

[R. Tomasi]

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.

And the mask that you are comparing with using these two AND instructions just magically falls from the sky, or what? Not talking about the fact that these are wasted effort 90% of the time...

You proved nothing at all. Except for an impressive lack of understanding how actual chess engines work - that you proved quite convincingly.

[R. Tomasi]

But anyways: let's try to refocus on what this thread is about. I think having perft numbers for captures would be interesting, really. My suggestion is to compute perft (as in vanilla perft) but at the leaves continue to expand until every combination of captures has been exhausted.

[dangi12012]

I dont know how you can even pretend that there is a discussion to be made...

30M/s is for the moves that are tried. With 90% pruning rate, you're looking at additional effort for 300M/s, that's why. It seems you still don't get the difference between an engine and a pure move gen.

Thats exactly my point. You literally bloat the thing you sort for no reason its literally almost free to have a fully legal movegen. Sorting is expensive NlogN. Makemove / Unmake on an not legal move is expensive. Function calls are expensive.

When you quote 90% its exaclty my point. With 99.5% yes then we could discuss. But as its stands - you sort more elements (you know the 300M includes the sorted - the 30M is the played) for every position and that alone makes you lose the argument.

EDIT:
Yes please stay on topic..