Attacks From table

[bob]

unless you have a power of 2 size, a table lookup is going to include a multiply. Shift and add really don't count in a super-scalar architecture. I don't think there is anything to gain here. I used to do what Slate and Atkin did. Maintained an array of attacks. One showing all squares attacked from each occupied square (now replaced by direct computation via magic) and one showing all squares that attack a given square (kind of info used in SEE for example). The updating was quite expensive, and very cache unfriendly. I dropped the latter one completely and converted the other to a table lookup (initially rotated bit boards, then to magic bit boards) and the speed climbed dramatically.

I can probably dig up my old slate/atkin style code, but it was really big (and really clever and really cache-unfriendly). Much nicer to have a simple direct-computation macro that expands into something very simple.

[Aleks Peshkov]

This representaion is as fast as the fastest perft known engines.

My principal chess representation consists of 16-byte vector for each 16 chess piece from each side.

attackMap is array of Ranks of BitRank vectors for each piece;

BitRank: byte of 8 squares per rank (1/8 of bitboard);
PieceId: index to 16 pieces of one side;

BitRank attackMap[Rank 0..8][PieceId 0..15];

There are 3 basic operations:
1) writing 8 separate bytes of attackTo bitboard into each attackMap rank;
2) fetching set (16-byte mask or 16-bit using _mm_movemask_epi8) of pieces that attack a given square (trivial operation within single SIMD register);
3) transforming attackMap into legal moves matrix (excluding pinned moves, adding pawn non capture moves).

Source code of Perft Engine:
https://bitbucket.org/alekspeshkov/petrel

[Edsel Apostol]

unless you have a power of 2 size, a table lookup is going to include a multiply. Shift and add really don't count in a super-scalar architecture. I don't think there is anything to gain here. I used to do what Slate and Atkin did. Maintained an array of attacks. One showing all squares attacked from each occupied square (now replaced by direct computation via magic) and one showing all squares that attack a given square (kind of info used in SEE for example). The updating was quite expensive, and very cache unfriendly. I dropped the latter one completely and converted the other to a table lookup (initially rotated bit boards, then to magic bit boards) and the speed climbed dramatically.

I can probably dig up my old slate/atkin style code, but it was really big (and really clever and really cache-unfriendly). Much nicer to have a simple direct-computation macro that expands into something very simple.

You are probably right. There' s not much to gain besides code complexity. I've implemented the usual PEXT optimization to the magic bitboards and sliding piece attacks are now almost just a table lookup.