What ever became of bitboard ray serializing?

[Zach Wegner]

Why did this idea completely die? And all bitboard serialization schemes for that matter?
http://www.stmintz.com/ccc/index.php?id=487844

It was a good idea. It was reasonably fast. But it has completely died? Everyone seems to be too caught up with magic bitboards and such, when there is a lot of untapped potential in this idea. It's hard to use directly with most current move gen schemes, because it uses rays, but it could be expanded to cover multiple directions... like magic bitboards. Has anyone tried using magic bitboards to get the attacks, and then another magic table from the masked attack set to get the actual moves?

With today's magic-finding schemes, I'm sure that at least the memory requirements can be reduced.

[Gerd Isenberg]

Why did this idea completely die? And all bitboard serialization schemes for that matter?
http://www.stmintz.com/ccc/index.php?id=487844

It was a good idea. It was reasonably fast. But it has completely died? Everyone seems to be too caught up with magic bitboards and such, when there is a lot of untapped potential in this idea. It's hard to use directly with most current move gen schemes, because it uses rays, but it could be expanded to cover multiple directions... like magic bitboards. Has anyone tried using magic bitboards to get the attacks, and then another magic table from the masked attack set to get the actual moves?

With today's magic-finding schemes, I'm sure that at least the memory requirements can be reduced.

It died?

Ok, I have the raywise infra-structure, but I abandoned the raywise serialization, since bitscan has become fast again with core 2 and K10 - and I like to traverse lot of disjoint sets, of course specially in qsearch. I thought about special all-node generators with it, but I actually don't even use classical movelists (except root) but 16 move target bitboards per direction, where I generate move by move in a plausible order .

For attacks I use SSE2 fill stuff to generate direction-wise attacks. For rare piece-wise attacks HyperQuint for files and diagonals, which is imho unbeatable and most ressource friendly for sliding piece attacks, but requires bswap. 32-bit IsiChess MMX and HansDamf use MMX Kogge-Stone and Dumb7Fill.

But thanks for the link again, one may update Hashing Multiple Bits in CPW a bit. Actually I feel quite lonesome there

Cheers,
Gerd

[Zach Wegner]

Thanks for the info Gerd. I hadn't looked at that Wiki page, at least for a long time.

While bitscans are now pretty fast, I think there is still room for improvement. Imagine instead of the direction dependent approach on the post I linked to, a square based approach for multiple directions. For instance, a rook on E4 has 5*5*4*4=400 possible unique movelists. Quick calculation: 400 movelists*16 bytes*64 squares=400KB max for rooks. It would get smaller too, as corner rooks have 7*7=49 possible movelists. Though it seems tricky, a masked attack set could be condensed via magic multiplication into an index into a movelist table. Unfortunately, there's no chance for good collisions--400 is the best possible. If I had my old magic finding code, it would be fun to try. Any takers?

It's also too bad that I lost my titboard code. That was pretty fast on 32 bits, and I'm sure it would get a nice speedup on 64, also with increased cache sizes, etc. I also never got around to trying out the compression I had in mind of not duplicating identical movelists.

[Sven]

It would get smaller too, as corner rooks have 7*7=49 possible movelists.

Isn't it 8*8=64? E.g. a white rook on A1 has either 0 or 1 or ... or 7 moves on the first rank, and the same for a-file. 0 moves if B1 (A2) is occupied by white, 7 moves if B1..G1 (A2..A7) are empty and H1 (A8) are either empty or occupied by black.

So 8 possible movelists on first rank * 8 possible movelists on a-file.

Did I miss something?

Sven

[Zach Wegner]

Err... yes. You're right. I just did a quick head-calculation while thinking about Gerd's archived post. It says 7 attack sets, but it's only non-empty.

So 64. Still pretty small though.