We need to scrap Perft()

[Mergi]

Ok, i just tried it. Generating only captures (no promotions).

From 140m/s movegen to 7m/s I think it gets so slow because the MoveGen object needs to be instantiated a lot more and it calculates a lot of special masks when it gets constructed.

The problem with what you are proposing is that a lot of engine authors would have to radically change their movegen to make it work for this. For example i can't just easily change the movegen to only generate queen promotions. It's either all promotions or nothing.

Code: Select all

perft 1
Nodes explored: 20

perft 2
Nodes explored: 408

perft 3
Nodes explored: 8591011

perft 4
Nodes explored: 2877055794

[Ras]

cperft(n) is like normal perft(n), except for the final depth, were we only look at captures (excluding underpromotions) and queen-promotions.

Agree.

Btw. I could see a similar thing to cperft for testing checking-moves movegen (in very similar spirit).

Uh, maybe the capture perft then should be called "captperft" so that a later checkperft wouldn't collide with the naming - after all, "cperft" would also be an abbreviation for the checking perft?

[Ras]

For example i can't just easily change the movegen to only generate queen promotions. It's either all promotions or nothing.

Oh, so you generate underpromotions in QS, but just don't execute them? I hadn't thought of this possibility. That would be a reason to re-consider and accepting underpromotions as well, both for capture-promotions and quiet promotions.

[Mergi]

I might've misunderstood and implemented something else.

Are you proposing to generate captures only for the final perft depth OR when perft reaches depth 0, go into "qperft" where you keep generating captures until you run out? I implemented the latter.

[Mergi]

For example i can't just easily change the movegen to only generate queen promotions. It's either all promotions or nothing.

Oh, so you generate underpromotions in QS, but just don't execute them? I hadn't thought of this possibility. That would be a reason to re-consider and accepting underpromotions as well, both for capture-promotions and quiet promotions.

My QSearch generates all promotions. It just reuses the normal movegen's method to generate those. They are very rare so i didn't see the need to limit that in any way and introduce more complex code. Besides, the chances are, the underpromotions will get pruned anyway.

[R. Tomasi]

For example i can't just easily change the movegen to only generate queen promotions. It's either all promotions or nothing.

Oh, so you generate underpromotions in QS, but just don't execute them? I hadn't thought of this possibility. That would be a reason to re-consider and accepting underpromotions as well, both for capture-promotions and quiet promotions.

Yeah, I have the same problem. But if all I want for now is the correct numbers, I can just exclude the underpromotions that have been generated in the final depth of cperft, no?

I might've misunderstood and implemented something else.

Are you proposing to generate captures only for the final perft depth OR when perft reaches depth 0, go into "qperft" where you keep generating captures until you run out? I implemented the latter.

We were actually discussing the pros and cons of both aproaches, but then settled for captures and queen promotions only (excluding underpromoting captures) in final depth.

[Ras]

when perft reaches depth 0, go into "qperft" where you keep generating captures until you run out?

A mixture: run regular perft, and at the leaf nodes, generate exactly one additional level of captures, but not recursive, i.e. not "until you run out of captures". So, captperft x >= perft x, with equality if there are no captures or promotions in any leaf node of perft x.

[Mergi]

I guess you can always make a check in the perft .. if (underpromotion(move)) continue;
Sometimes i feel dumb.

[Ras]

(excluding underpromoting captures)

Well, to be fair, it was only me who suggested that, and we should probably give others a bit more time to weigh in. We could as well include underpromotions as long as we get to a conclusion what to do.

[R. Tomasi]

(excluding underpromoting captures)

Well, to be fair, it was only me who suggested that, and we should probably give others a bit more time to weigh in. We could as well include underpromotions as long as we get to a conclusion what to do.

Personally I don't care that much about including or not, so my vote on this is an abstention

I think I finished implementing (it's compiling currently) it - for the moment excluding underpromotions, but that would be trivial to change. I'll post a few results for the starting position and kiwi-pete once the compiler is done with it's work.