World Chess Move Generation Speed Competition 2015

[ZirconiumX]

[d] r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 1

How much time does your engine need to compute KiwiPete perft(4) = 4085603 ?

Skipper needs 18 seconds.

4,085,603 / 18 = 226,977 nodes per second. That's slower than my engine (Perft(6) gives 853,228NPS), and I'm using Copy-Make on unaligned structures...

Matthew:out

[Henk]

Just saw that code does not work if last move is castling move.

So it should not only test if last move is an en passant move but also if it is a castling move.

[Daniel Anulliero]

Isa 1.6.0.95 (Version from HGm's December tournament)

Code: Select all

perft 4
sortie perft
Noeuds = 4085603
Temps  = 0.55 secondes

18 seconds for Skipper ... mmm ... seems you have a serious speed problem ...

Another interresting question is :
How many depth can you reach for this position at blitz level (5+1)

Isa have a move generator not too slow but it lose too much speed somewhere ...
It can reach only depth 8 here :

Code: Select all

1 134 4891 0 e2a6 b4c3
2 134 902 0 e2a6 b4c3
3 105 9783 0 e2a6 b4c3 d2c3 h3g2 f3g2 e6d5
4 105 10784 0 e2a6 b4c3 d2c3 h3g2 f3g2 e6d5
5 64 62355 1 e2a6 b4c3 d2c3 e6d5 e4d5 h3g2 f3g2 b6d5
6 49 406021 7 e2a6 e6d5 c3d5 b6d5 a6b7 h3g2 f3g2 e7e5 b7a8 f6e4
7 49 520662 15 e2a6 e6d5 c3d5 b6d5 a6b7 h3g2 f3g2 e7e5 b7a8 f6e4
8 40 1403668 36 e2a6 e6d5 c3d5 f6d5 e5c4 h3g2 f3g2 d7d6

Time for some profiling ...
best
Dany

[Henk]

No it was 4 seconds. It collects all moves in a list and that is not necessary. But I don't think it is that important for now. Only if I get tired waiting for perft to finish.

I'm more interested in the speed of Skipper's normal chess playing.

[ZirconiumX]

No it was 4 seconds. It collects all moves in a list and that is not necessary. But I don't think it is that important for now. Only if I get tired waiting for perft to finish.

I'm more interested in the speed of Skipper's normal chess playing.

These are inherently interlinked. Perft is kind of an upper bound for your chess speed - if your perft is slow, your normal chess won't be any faster.

Matthew:out

[hgm]

Well, not really. Perft can be slow because you have to check legality of the moves. Which, in a King-capture engine would basically force you to do an extra ply of move generation to detect if their are King captures in the perft leaves. That would make the eprft slow even in a fast engine.

[ZirconiumX]

Well, not really. Perft can be slow because you have to check legality of the moves. Which, in a King-capture engine would basically force you to do an extra ply of move generation to detect if their are King captures in the perft leaves. That would make the eprft slow even in a fast engine.

Note the use of "kind of". If your move ordering is worst-case, let's say, then you're doing a slower perft, which is where I got my idea of upper bound from, but I suppose you're right.

Having sufficiently debugged my program enough to get a correct result for KiwiPete(4), I have:

Code: Select all

Nodes: 4085603 in 5.627 seconds

On a debug build. That number would probably go down with the aid of optimisation and SSE, and possibly (to be tested) a 64-bit compile.

Matthew:out

[hgm]

True, but it would probably not go down a factor 100.

[bob]

Well, not really. Perft can be slow because you have to check legality of the moves. Which, in a King-capture engine would basically force you to do an extra ply of move generation to detect if their are King captures in the perft leaves. That would make the eprft slow even in a fast engine.

Note the use of "kind of". If your move ordering is worst-case, let's say, then you're doing a slower perft, which is where I got my idea of upper bound from, but I suppose you're right.

Having sufficiently debugged my program enough to get a correct result for KiwiPete(4), I have:

Code: Select all

Nodes: 4085603 in 5.627 seconds

On a debug build. That number would probably go down with the aid of optimisation and SSE, and possibly (to be tested) a 64-bit compile.

Matthew:out

You should be able to reach this fairly easily. Crafty has a plain vanilla perft, no hashing or anything tricky...

White(1): r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 1
White(1): perft 4
total moves=4085603 time=0.09
White(1): perft 5
total moves=193690690 time=4.31
White(1): perft 6
total moves=8031647685 time=177.86

[ZirconiumX]

Well, not really. Perft can be slow because you have to check legality of the moves. Which, in a King-capture engine would basically force you to do an extra ply of move generation to detect if their are King captures in the perft leaves. That would make the eprft slow even in a fast engine.

Note the use of "kind of". If your move ordering is worst-case, let's say, then you're doing a slower perft, which is where I got my idea of upper bound from, but I suppose you're right.

Having sufficiently debugged my program enough to get a correct result for KiwiPete(4), I have:

Code: Select all

Nodes: 4085603 in 5.627 seconds

On a debug build. That number would probably go down with the aid of optimisation and SSE, and possibly (to be tested) a 64-bit compile.

Matthew:out

You should be able to reach this fairly easily. Crafty has a plain vanilla perft, no hashing or anything tricky...

White(1): r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 1
White(1): perft 4
total moves=4085603 time=0.09
White(1): perft 5
total moves=193690690 time=4.31
White(1): perft 6
total moves=8031647685 time=177.86

I'm currently debugging my UnmakeMove function, since the 5 second figure was done with copy-make, which is really not ideal.

With optimisation flags, I got the number to 3.25 seconds copy-make, which is still fairly slow. An obvious speedup would be to not copy over the attack tables, since they get regenerated immediately afterwards.

Matthew:out