Perft speed

[ericlangedijk]

Continuing, after a long break, with my chess engine...
GenMoves() works correctly. Now for some more speed.
From the starting position my Perft(5) takes 655 MS.
Only counting leave-nodes.
Without threads or hashing, on a Windows PC 2,67 GH machine.
I get the impression it's slower than the average chess program.
Does anyone know some speeds of different engines?

Regards, Eric Langedijk

[mar]

Continuing, after a long break, with my chess engine...
GenMoves() works correctly. Now for some more speed.
From the starting position my Perft(5) takes 655 MS.
Only counting leave-nodes.
Without threads or hashing, on a Windows PC 2,67 GH machine.
I get the impression it's slower than the average chess program.
Does anyone know some speeds of different engines?

Regards, Eric Langedijk

Hi Eric, my engine does perft(5) in 344ms (only counting leaf nodes) on Intel Q8400, 2.66Ghz. And it has much less nps than most other engines. I personally think that perft's value is in move generator validation more than benchmarking. Anyway good luck with your engine.

best
Martin

[Dann Corbit]

Some engines hash perft counting, so keep that in mind when you do comparisons.

[bob]

Some engines hash perft counting, so keep that in mind when you do comparisons.

Correct. Here are a couple of examples from Crafty, starting position. Core-2 duo laptop (2.53ghz):

model name : Intel(R) Core(TM)2 Duo CPU P9600 @ 2.53GHz

perft 5: total moves=4865609 time=0.22

perft 6: total moves=119060324 time=5.36


No hashing or other tricks inside Crafty... it was never intended to be a speed test, but was a "correctness test" instead...

[JVMerlino]

Continuing, after a long break, with my chess engine...
GenMoves() works correctly. Now for some more speed.
From the starting position my Perft(5) takes 655 MS.
Only counting leave-nodes.
Without threads or hashing, on a Windows PC 2,67 GH machine.
I get the impression it's slower than the average chess program.
Does anyone know some speeds of different engines?

Regards, Eric Langedijk

Hi Eric, my engine does perft(5) in 344ms (only counting leaf nodes) on Intel Q8400, 2.66Ghz. And it has much less nps than most other engines. I personally think that perft's value is in move generator validation more than benchmarking. Anyway good luck with your engine.

best
Martin

I agree with Martin. Although it may be interesting (or discouraging, in my case) to compare my perft results with other engines, it's only really useful for move generation validation and comparison against earlier versions of your movegen (i.e. optimization).

My engine's perft 5 currently takes 890ms. But it does a lot of work that many other engines do not. It's a fully legal move generator, plus it does move scoring and flagging moves that give check, the last of which is pretty expensive. If I remove that last bit, then perft 5 takes 420ms. But you have to perform that check somewhere, so you need to take that kind of thing into account when you try to compare perft scores with other engines.

But the first version of my movegen took more than 2100ms for perft 5, so I've made a lot of improvement on it in the 2+ years since the first release.

Good Luck!

jm

[kongsian]

Continuing, after a long break, with my chess engine...
GenMoves() works correctly. Now for some more speed.
From the starting position my Perft(5) takes 655 MS.
Only counting leave-nodes.
Without threads or hashing, on a Windows PC 2,67 GH machine.
I get the impression it's slower than the average chess program.
Does anyone know some speeds of different engines?

Regards, Eric Langedijk

On my Intel Core2 Duo 2.80 Ghz with a legal move generator and bulk counting at leaf.

perft 5: 0.125 s
perft 6: 1.875 s
perft 7: 43.990 s

Rgds.
Kong Sian

[JuLieN]

My engine's perft 5 currently takes 890ms. But it does a lot of work that many other engines do not. It's a fully legal move generator, plus it does move scoring and flagging moves that give check, the last of which is pretty expensive. If I remove that last bit, then perft 5 takes 420ms.

John, if I would do that in Prédateur that would be slower than not doing it, because it would be computing the checks even for moves that would be pruned in the tree (usually, >90% of the moves...). Are you sure this is a good idea? (Maybe it is in your implementation. In mine, there's only one check "checked" : it's right after makemove() ).

[jwes]

My engine's perft 5 currently takes 890ms. But it does a lot of work that many other engines do not. It's a fully legal move generator, plus it does move scoring and flagging moves that give check, the last of which is pretty expensive. If I remove that last bit, then perft 5 takes 420ms.

John, if I would do that in Prédateur that would be slower than not doing it, because it would be computing the checks even for moves that would be pruned in the tree (usually, >90% of the moves...). Are you sure this is a good idea? (Maybe it is in your implementation. In mine, there's only one check "checked" : it's right after makemove() ).

The situation is not as clear as that. I would hope that if you are going to prune a node you would not generate moves first. At ALL nodes, most programs will try all the moves they generate, while at CUT or PV nodes, they may well get the move from the hash table and not generate any moves at all. It also can be much more efficient to generate legal moves than to call InCheck for each move made (I would guess that the extra cost of legal move generation is about 4 InCheck calls). Qsearch is different and if you have a separate movegen for qsearch it might be better not to do legal moves there. If you haven't done it, you might want to collect statistics on how many moves you generate and how many times you call InCheck(). I tried this with crafty and was quite suprised.

[JVMerlino]

My engine's perft 5 currently takes 890ms. But it does a lot of work that many other engines do not. It's a fully legal move generator, plus it does move scoring and flagging moves that give check, the last of which is pretty expensive. If I remove that last bit, then perft 5 takes 420ms.

John, if I would do that in Prédateur that would be slower than not doing it, because it would be computing the checks even for moves that would be pruned in the tree (usually, >90% of the moves...). Are you sure this is a good idea? (Maybe it is in your implementation. In mine, there's only one check "checked" : it's right after makemove() ).

The situation is not as clear as that. I would hope that if you are going to prune a node you would not generate moves first. At ALL nodes, most programs will try all the moves they generate, while at CUT or PV nodes, they may well get the move from the hash table and not generate any moves at all. It also can be much more efficient to generate legal moves than to call InCheck for each move made (I would guess that the extra cost of legal move generation is about 4 InCheck calls). Qsearch is different and if you have a separate movegen for qsearch it might be better not to do legal moves there. If you haven't done it, you might want to collect statistics on how many moves you generate and how many times you call InCheck(). I tried this with crafty and was quite suprised.

Correct. In my main search (not qsearch) there is no pruning whatsoever between movegen and the iterative main search call (although there certainly can be reductions, but that will only cause a drop to qsearch).

But the qsearch is indeed a different story and it does look like I have some inefficiencies there, for example, calling SEE after movegen. I don't have a special movegen for qsearch -- just a parameter to only generate captures if the side to move is not in check. So all moves are still being checked for legality and giving check, but they can very often be pruned by SEE.

Something to look at, I think....

jm

[ericlangedijk]

Thanks for the response.
There is still a lot of optimization to do.

I make pseudolegal moves and check after having made the move if we runned into a check. I work with Bitboards and incrementally update 4 occupationmasks (normal, rotated90, rotated45 and rotated315).
Is this the best way to handle that? Or is there a smarter way?
To my astonishment GenerateMoves() took much less time than I thought.

GenerateMoves - 7,94% of the time used
MakeMove - 19,94% of the time used
UnmakeMove - 16,68% of the time used
RunnedIntoCheck - 14,31% of the time used
Where the rest of the time is going I still have to figure out.

I use Perft (after it runs correct in a lot of testpositions) now to check the basic speed.