Bitboards ?: C# vs C++

[Chessnut1071]

In my opinion it depends much on how you organize your entire engine, and when you do that well, it doesn't matter much whether you use mailbox or bitboard. Simplistic mailboard implementations are probably a bit slower than bitboard, especially when you have complex evaluation.

About you method for determining whether a move delivers check: more important than whether this is fast or slow is why you would want to do this at all. In my engines I am only interested in this once it is decided that the move is going to be searched. In which case a new move generation will follow for the opponent. So for most generated moves I would not be interested in this info. That means it doesn't really pay to heavily invest in making testing moves for this easy (by preparing / updating thecheck mask), but that it gives a faster engine when I test individual moves through a method that would be slower when it had to be applied to all moves.

Ah, Herr Muller, the check is everything for my objective. My interest is minimum moves to mate at the highest ply possible. The last moves doesn't even look at anything but check. Also, the check feeds forward info for the constraints on the opposite side. Even maxing ELO needs check, discovered check and pin. I will agree; however, that many openings and middle games can ignore check, discovered check, but not pin. I can't because check is the single most important variable in optimized mate finding, followed closely history by ply. I need 30x(32x64) matrix for that little gimmick. but, it drops the engine calls by more than 50%. the 30 is for 30-ply which is my objective.

I think you are focused on some different type of approach than I'm actually using. I'd list the code, but, it's like going to work in your underwear right now.

I'm working on a bit board, but, I'm using an older version of C# in Net, Framework. I think you need to go to C++ to optimize a bitboard. I don't know many C# bitboards.

OK, so you are building a mate finder rather than a chess player. Still, the basic principle remains valid: first examine what really has to be done, rather than just picking some method without analysis, and trying to make that as fast as possible. If you want to test all moves for delivering check, for the purpose of playing only those that do, that is a bad idea, even when the test can be made very fast. Because most moves do not deliver check, you would generate far more moves than needed. It would be much faster to use a special purpose move generator that selectively generates checking moves, and don't wastes any time on generating moves that don't. E.g. for knights you could have a pre-computed table indexed by knight square and opponent king square, which contains the (maximally 2) squares where that knight would deliver check. Most of the time knights would not be able to check at all, and you would be done with those almost instantly. That is a whole lot faster than generating all 8 moves for a knight, and subjecting each of those to a test to see whether they check.

Actually I already have all that, including the knight moves in the check mask. Also, it's no big deal to look for check, if the move is in the check mask it's check, or simply, one tiny little if statement, smaller than a photon but just a fast. It's no big deal setting up the check mask. Like the Zobirst hash, you just compute it for the pieces affected.

[hgm]

But then you have so few moves to check that it would hardly pay to invest in a checkmask for sliders. And stepper moves don't have to be tested at all; they are guaranteed hits.