Confusion about 'decoding' move bitboards

[Mpsey]

Thank you Gerd & Codesquid! those are brilliant solutions. I understand better now. This is a great community

[Mpsey]

I am enjoying coding with bitboards! I find them to be refreshingly elegant and am enjoying the performance improvements over arrays, even before using magics/rotated boards.

As a continuation of my original question.. I am still not sure at how some problems are solved with bitboards. For instance: when serializing moves how do you detect lets say two knights converging on the same square or perhaps two rooks converging on e1 (Rae1 and Rfe1 for example)?

It seems as if disabiguating here is a costly procedure... I am asking, perhaps from someone who has experience with this problem, If there is a good way of doing this without bottlenecking my engine.

If you focus on a target square with the question which pieces control or can move to this square, you usually put a super piece on that target-square to generate its attacks to intersect it with appropriate pieces. In case of one piece kind of interest, you virtually put that piece on the target-square, generate it knight- or rook-attacks to intersect them with own knights or rooks to see if one or more can move to that target square.

Specially at the tips in qsearch, where it is about to determine (winning) captures in stages, you don't serialize that much, due to intersection of attacks with target pieces to capture. Those intersections, if not empty, are sparsely populated, and if you found the winning capture early in the setwise world of bitboards, it is likely you don't need to serialize other moves at all.

Very interesting. I am moving slowly at this but eventually I would love to implement something like this in my code.

[hgm]

I'm not sure I understand your nomenclature here or how you define efficiency - but the primary benefit of bit-boards is its "data parallel" operations. They probably are not as efficient as simple arrays when you cannot take advantage of that.

What I meant is that extracting a single to-square from a bitboard is usually slower than generating a move from scratch in a mailbox representation.

[syzygy]

I'm not sure I understand your nomenclature here or how you define efficiency - but the primary benefit of bit-boards is its "data parallel" operations. They probably are not as efficient as simple arrays when you cannot take advantage of that.

What I meant is that extracting a single to-square from a bitboard is usually slower than generating a move from scratch in a mailbox representation.

I don't know if this is true on a cpu with a fast bitscan instruction. With a mailbox representation you have more branches and array lookups.

Of course it's hard to do a direct comparison, since you're not starting from the same data structures.

[Don]

I'm not sure I understand your nomenclature here or how you define efficiency - but the primary benefit of bit-boards is its "data parallel" operations. They probably are not as efficient as simple arrays when you cannot take advantage of that.

What I meant is that extracting a single to-square from a bitboard is usually slower than generating a move from scratch in a mailbox representation.

I don't know if this is true on a cpu with a fast bitscan instruction. With a mailbox representation you have more branches and array lookups.

Of course it's hard to do a direct comparison, since you're not starting from the same data structures.

Not only that, but you tend to write programs differently. You tend to bend the ideas to fit the data structure in order to take advantage of the things you can well (or do quickly.)