The cost of check & discovered check in bitboards

[Chessnut1071]

I'm converting my engine into C# and recently added bitboards, Is it worth the trouble to compute for check & discovered check. Here's my statistics for pseudo-moves:

raw pseudo moves: = 620,22 nps
raw + check = 588,466 nps
raw + check + discovered check = 421,940 nps

given the relatively small reduction in speed, the evaluation reduction from the information gained usually overcomes the speed metric, So, is there something I'm missing here? Why are so many advising to ignore these metrics?

[lithander]

Is your NPS measuring only the move generators speed or the engines search speed?

If it's only perft then all NPS values you quote seem too low. You should have several million NPS if it's only about the move gen with no search and eval.

But if this speed measurement is already including search and the evaluation then I don't understand what the question is about. The fact that the speed of your engine goes down when you consider checks and discovered checks at the move generation level seems to be a testament to the quality of advise you have received against fully legal move generation.

So first of all... what exactly are you measuring? Everything or only the move generator?

[Mergi]

Whether it is perft or search, if you drop 33% of your NPS just by switching to (fully) legal move gen, then something is very wrong with your implementation.

[Chessnut1071]

Is your NPS measuring only the move generators speed or the engines search speed?

If it's only perft then all NPS values you quote seem too low. You should have several million NPS if it's only about the move gen with no search and eval.

But if this speed measurement is already including search and the evaluation then I don't understand what the question is about. The fact that the speed of your engine goes down when you consider checks and discovered checks at the move generation level seems to be a testament to the quality of advise you have received against fully legal move generation.

So first of all... what exactly are you measuring? Everything or only the move generator?

[Chessnut1071]

[fen][fen][/fen][/fen]

Is your NPS measuring only the move generators speed or the engines search speed?

If it's only perft then all NPS values you quote seem too low. You should have several million NPS if it's only about the move gen with no search and eval.

But if this speed measurement is already including search and the evaluation then I don't understand what the question is about. The fact that the speed of your engine goes down when you consider checks and discovered checks at the move generation level seems to be a testament to the quality of advise you have received against fully legal move generation.

So first of all... what exactly are you measuring? Everything or only the move generator?

[fen]b4b2/3r4/3pr3/8/1K5N/2PR4/Q3p3/5kBR w 0 1[/fen]

Gutten Tag Herr Lithandler
To avoid confusion. There are 56 pseudo-moves, 7 disc checks, and 4 checks for white in the following position. If if loop 3,000,000 times against this same position, the stopwatch finishes in 4.98 sec[699,642] for just the 56 moves, 4.99 sec 602,000] [if I include checks, and 6.92 sec [433,526] if discovered checks are also included.

I would love to know how some get get that speed so much faster. I'm using an Intel i7, 5 gen, 2.5 GHz, 1 core machine. Also, I'm using pre-computed bitboards for move generation. I'm kind of new to this and haven't copied anybody's code, so, there's definitely more efficient systems than mine.

However, my question: Is the information gained by including checks and discovered checks-reduces speed by about 1/3-worth the extra time. I know it is in some positions, but, what's the value in no evaluations? I assume they have to do it on the final move.

[R. Tomasi]

I would love to know how some get get that speed so much faster. I'm using an Intel i7, 5 gen, 2.5 GHz, 1 core machine. Also, I'm using pre-computed bitboards for move generation. I'm kind of new to this and haven't copied anybody's code, so, there's definitely more efficient systems than mine.

Given that you seem to be orders of magnitude off, speed-wise, I would guess that it is not your hardware that causes this. In any case, on an i7 you should definetely be in the millions of NPS for pure perft. My guess is, that you copy your board state around a lot. There should be one single instance of your board class in your whole program, which gets passed around in your movegen and search by reference and that is incrementally updated during move/unmove.

[Mergi]

Oh, I think i understand now. You are precomputing whether your move will put the enemy in check. I think for most engines, they would only compute whether a pseudo-legal move leaves their own king in check ... well, at least my engine does. I'm using a more lazy approch of finding out whether i'm in check only when it's actually needed.

Tbh, I'm not sure how beneficial that would be for a regular engine. I can imagine trying a checking move first in the endgame might be a good idea, but other than that MVVLVA sorting is probably superior? But i guess if you are looking to make just a pure mate solver, then trying checking moves first would definitely be huge for your search.

I'd also recommend implementing a perft function, rather than trying to loop over one position. This makes it harder to see and compare the actual generator speed.

[R. Tomasi]

Oh, I think i understand now. You are precomputing whether your move will put the enemy in check. I think for most engines, they would only compute whether a pseudo-legal move leaves their own king in check ... well, at least my engine does. I'm using a more lazy approch of finding out whether i'm in check only when it's actually needed.

Tbh, I'm not sure how beneficial that would be for a regular engine. I can imagine trying a checking move first in the endgame might be a good idea, but other than that MVVLVA sorting is probably superior? But i guess if you are looking to make just a pure mate solver, then trying checking moves first would definitely be huge for your search.

I'd also recommend implementing a perft function, rather than trying to loop over one position. This makes it harder to see and compare the actual generator speed.

I can see functionality like that helping during QS. The vanilla way of doing QS is to only look at captures, but also looking into moves that will give check can give some tactical edge. You have to limit that, of course, since there may be very long/perpetual checking sequences in a position. I had that in my old engine (and am planning to move it into Pygmalion, too). However, I think for that purpose it is better to only generate moves that give check, instead of generating everything and then verifying if the move checks the enemy king.

[Chessnut1071]

Oh, I think i understand now. You are precomputing whether your move will put the enemy in check. I think for most engines, they would only compute whether a pseudo-legal move leaves their own king in check ... well, at least my engine does. I'm using a more lazy approch of finding out whether i'm in check only when it's actually needed.

Tbh, I'm not sure how beneficial that would be for a regular engine. I can imagine trying a checking move first in the endgame might be a good idea, but other than that MVVLVA sorting is probably superior? But i guess if you are looking to make just a pure mate solver, then trying checking moves first would definitely be huge for your search.

I'd also recommend implementing a perft function, rather than trying to loop over one position. This makes it harder to see and compare the actual generator speed.

I think I see one of the slow issues. After reading perft descriptions it uses nodes, I refer will referred to the entire position, all 56 moves. So, my engine using, nodes, reaches 39,179,952 raw pseudo moves, 33,712,000 pseudo + check, and 24,277,456 pseudo + check + discovered check. This is my 1st attempt at optimizing my weak engine. My objective is not ELO, but, the minimum moves to checkmate. I think it's near 100 % up to 20-ply; however, I'm trying to reach 100% at 30-ply. Not sure that can be done. Any pruning will fail. I found some positions where the winning move was the last move out of 61 possible legal moves. I do; however, need magnitudes greater speed to reach 30-ply from here.

[pedrojdm2021]

In my C# engine i use only pseudo legal move generation with make/undo and i am getting ~700.000 NPS in my CPU.

if you want know an simple approarch to detect checks and attacks to a square, go to "chessprogramming.org" and search for "Square attacked by"
it seems to be faster than a doing a lot of conditions, but not so fast

Most of the fasest C# chess engine seems to do something like black magic IMO. if you want to keep a clear code without so many tricks and hacks, i'd recommend to translate the engine to C/C++ code and you will gain at least 2x performance boost for free.

Also, C/C++ is easier to optimize because you don't have to deal with all the trash that the C# puts into your assembly if you are not careful even doing simple things such as reading an array database

I have been dealing with the C# performance for quiet a bit, and i haven't seen any super fast C# that does not do so many tricks to reach a good performance.

That's just my humble recommendation if you don't want to smash your head over the keyboard