New UnseenSource for Reborn Engine.

[hgm]

Perhaps you are right. Maybe if I only consider non-bitboard engines then my move generator might be just slow, instead of very slow. Haven't checked any perft times for non-bitboard engines, so I have no sense of what's "normal" for them.

Bitboard is usually a lot slower for perft. Especially with the perft flavor that makes/unmakes the final ply, rather than just counting generated moves.

[markchessman]

thanks sven , Your a great programer && I am learning, if not slowly

[ZirconiumX]

thanks sven , Your a great programer && I am learning, if not slowly

But Remember(THE * Rules, OF C, DO Not) {
Apply (int) English();
}

See?

Matthew::out()

[zullil]

Perhaps you are right. Maybe if I only consider non-bitboard engines then my move generator might be just slow, instead of very slow. Haven't checked any perft times for non-bitboard engines, so I have no sense of what's "normal" for them.

Bitboard is usually a lot slower for perft. Especially with the perft flavor that makes/unmakes the final ply, rather than just counting generated moves.

Thanks, but now I'm very puzzled.

I thought that using bitboard methods rather than more traditional board representations made move generation much faster.

Suppose one's only goal were to count the number of leaf nodes arising after n plies from a given chess position. What board representation/move generation method would likely yield the fastest program?

[Sven]

Perhaps you are right. Maybe if I only consider non-bitboard engines then my move generator might be just slow, instead of very slow. Haven't checked any perft times for non-bitboard engines, so I have no sense of what's "normal" for them.

Bitboard is usually a lot slower for perft. Especially with the perft flavor that makes/unmakes the final ply, rather than just counting generated moves.

I disagree. I have tried it. Have you?

It is possible to write a very fast bitboard-based move generator which is faster than with the fastest mailbox approach. Also in check testing, pin detection, legality testing can be implemented much more efficiently than with e.g. 0x88. Make/unmake usually has comparable speed with both ways based on my experience. The "last ply" improvement that saves most or (depending on the legality testing strategy) all make/unmake operations at the last ply works with both bitboards and mailbox approaches, of course, and gives approximately the same speedup.

You will never know unless you have actually tried it.

It would be the computer chess news of the century: both Vincent and you going bitboards ...

Sven

[Sven]

Perhaps you are right. Maybe if I only consider non-bitboard engines then my move generator might be just slow, instead of very slow. Haven't checked any perft times for non-bitboard engines, so I have no sense of what's "normal" for them.

Bitboard is usually a lot slower for perft. Especially with the perft flavor that makes/unmakes the final ply, rather than just counting generated moves.

Thanks, but now I'm very puzzled.

I thought that using bitboard methods rather than more traditional board representations made move generation much faster.

Suppose one's only goal were to count the number of leaf nodes arising after n plies from a given chess position. What board representation/move generation method would likely yield the fastest program?

Hi Louis,

note that HGM is a "Real Programmers Don't Use Bitboards" guy

Sven

[hgm]

I thought that using bitboard methods rather than more traditional board representations made move generation much faster.

Then you thought wrong. What can be faster with bitboards is selective move generation, such as only generating captures. (Which, in engines, can pretty important, because most nodes are QS nodes. But it is of no use in perft.)

Suppose one's only goal were to count the number of leaf nodes arising after n plies from a given chess position. What board representation/move generation method would likely yield the fastest program?

You could probably beat mailbox with something very complex based on attack maps. And with some special code bypassing the generation of moves, and directly tabulating the move counts (code not normally present in an engine) you could make bitboards competitive too (on 64-bit machines for orthodox Chess, that is).

[hgm]

You will never know unless you have actually tried it.

That is a bit doubtful. Trying it would not resolve anything, as I am sure it would be a factor 3-5 slower than qperft, and you would start to complain that this was measured on a 32-bit machine, not using SSE4 etc...

I think it should be perfectly feasible to look what others can achieve. And I just haven't seen many reports of anything faster than qperft, which is mailbox. If qperft can be beaten by bitboard, it is much more likely an experienced bitboard programmer should be able to do it, than that I would.

But as you have tried it: how fast was your perft, compared to qperft?

[zullil]

I thought that using bitboard methods rather than more traditional board representations made move generation much faster.

Then you thought wrong. What can be faster with bitboards is selective move generation, such as only generating captures. (Which, in engines, can pretty important, because most nodes are QS nodes. But it is of no use in perft.)

Suppose one's only goal were to count the number of leaf nodes arising after n plies from a given chess position. What board representation/move generation method would likely yield the fastest program?

You could probably beat mailbox with something very complex based on attack maps. And with some special code bypassing the generation of moves, and directly tabulating the move counts (code not normally present in an engine) you could make bitboards competitive too (on 64-bit machines for orthodox Chess, that is).

Thanks. I didn't intend to step into an ongoing dispute.

I downloaded and compiled http://home.hccnet.nl/h.g.muller/perft.c

Very impressively fast. I will study the code when I get a chance. The perft built into Spark-1.0 was faster on the same hardware, but the spark binary wasn't compiled by me (not open source and I don't know how it works).

Code: Select all

Spark:

perft 7               3195901860 ops in 24.201 seconds

perft.c:

perft( 7)=   3195901860 (30.296 sec)

[Pablo Vazquez]

Perhaps you are right. Maybe if I only consider non-bitboard engines then my move generator might be just slow, instead of very slow. Haven't checked any perft times for non-bitboard engines, so I have no sense of what's "normal" for them.

Bitboard is usually a lot slower for perft. Especially with the perft flavor that makes/unmakes the final ply, rather than just counting generated moves.

Last time I checked, frc-perft was the fastest perft around.