Answers.Body: <p>I believe you are using magic bitboards. Your suggestion can actually be done quite reasonably, and is known as <a href="https://www.chessprogramming.org/BMI2#PEXT_Bitboards" rel="nofollow noreferrer">PEXT bitboards</a>. Basically, the tradeoff is between having a larger LUT or using an extra PEXT instruction to index the entry based on the least significant bit. IIRC both approaches are almost the same speed but PEXT is ever so slightly faster.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-09-01T13:26:53.150Z
Answers.LastActivityDate: 2023-09-01T13:26:53.150Z
Answers.UserDisplayName: Stockfischer
Answers.Body: <p>It takes time on the CPU to remove that extra information. Magic BitBoards are designed to do these calculations on the CPU one time when the engine is initializing so that we don't have to do them for each position being evaluated later on. If we tried to remove the extra, irrelevant blockers when computing the destinations ahead of time, we'd also need to later when attempting to retrieve the positions from the pre-computed results.</p>
  <p>When you consider the fact that 4096 BitBoards represented in 64-bit integers constitutes about 32kb of memory, it really is not worth it to reduce this data set down. Now days, a typical home computer will have 4GB minimum. 32kb of 4GB is 0.0008192% of the available RAM. That is a perfectly reasonable amount of memory for an application to use in order to save a few CPU instructions in a method that is called thousands or millions of times per second.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-09-04T11:59:40.147Z
Answers.Text: While I agree that the slowdown of computing this on each node is not worth it, I have to disagree on the point that 32 KB is negligible. How much main memory you have is pretty irrelevant for something like this, it matters how much cache memory you have, you definitely want these tables in L2 cache. For that, 32 KB *per square* is quite a bit. However, it is just about little enough to still be ok for this.
Answers.UserDisplayName: koedem
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-09-01T16:41:51.540Z
Answers.LastActivityDate: 2023-09-01T16:41:51.540Z
Answers.UserDisplayName: Nelson O
Body: <p>When generating attack tables for a rook, why do we consider all <code>2^(number of set bits on the mask)</code> potential configurations of empty or occupied squares along the ranks and files where a rook can move?</p>
  <p>Specifically, why are nonsensical configurations included given that they don't accurately represent legal moves a rook can make?</p>
  <p>Take this example :
  <code>X 1 1 0 1 1</code> and <code>X 1 1 0 0 0</code> result in the same legal move for a rook. Allowing only legal combinations, the rook table could be reduced from 4096 to 144.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-08-26T18:22:59.393Z
Comments.Text: Not sure I understand your suggestion correctly, but how would you access the correct entry then?
Comments.UserDisplayName: koedem
Tags: <programming><bitboard>
Title: Why consider all possible combinations of empty/occupied square a sliding piece can move to in attack table generation?
ThreadText: # Why consider all possible combinations of empty/occupied square a sliding piece can move to in attack table generation?
  
  (Asked by: username_0 on 2023-08-26)
  
  When generating attack tables for a rook, why do we consider all `2^(number of set bits on the mask)` potential configurations of empty or occupied squares along the ranks and files where a rook can move?
  
  Specifically, why are nonsensical configurations included given that they don't accurately represent legal moves a rook can make?
  
  Take this example :
  `X 1 1 0 1 1` and `X 1 1 0 0 0` result in the same legal move for a rook. Allowing only legal combinations, the rook table could be reduced from 4096 to 144.
  
  **Tags:** programming, bitboard
  
  > **Comments:**
  > **username_1**: Not sure I understand your suggestion correctly, but how would you access the correct entry then?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2023-09-01. Score: 1
  
  I believe you are using magic bitboards. Your suggestion can actually be done quite reasonably, and is known as [PEXT bitboards](https://www.chessprogramming.org/BMI2#PEXT_Bitboards). Basically, the tradeoff is between having a larger LUT or using an extra PEXT instruction to index the entry based on the least significant bit. IIRC both approaches are almost the same speed but PEXT is ever so slightly faster.
  
  
  ---
  
  ### Answer by username_3 on 2023-09-01. Score: 1
  
  It takes time on the CPU to remove that extra information. Magic BitBoards are designed to do these calculations on the CPU one time when the engine is initializing so that we don't have to do them for each position being evaluated later on. If we tried to remove the extra, irrelevant blockers when computing the destinations ahead of time, we'd also need to later when attempting to retrieve the positions from the pre-computed results.
  
  When you consider the fact that 4096 BitBoards represented in 64-bit integers constitutes about 32kb of memory, it really is not worth it to reduce this data set down. Now days, a typical home computer will have 4GB minimum. 32kb of 4GB is 0.0008192% of the available RAM. That is a perfectly reasonable amount of memory for an application to use in order to save a few CPU instructions in a method that is called thousands or millions of times per second.
  
  > **Comments:**
  > **username_1**: While I agree that the slowdown of computing this on each node is not worth it, I have to disagree on the point that 32 KB is negligible. How much main memory you have is pretty irrelevant for something like this, it matters how much cache memory you have, you definitely want these tables in L2 cache. For that, 32 KB *per square* is quite a bit. However, it is just about little enough to still be ok for this.  
  
  ---
  
  