Editing Bitboard (section)

==Implementation issues==
As a result of necessary compression and encoding of the contents of massive tables and the probability of transcription or encoding errors, bitboard programs are tedious for software developers to either write or debug.  Auxiliary generative methods not part of the application are usually required to build the tables.

===Processor use===
====Pros====
Bitboard representations use parallel [[bitwise operation|bitwise]] operations available on nearly all [[CPU]]s that complete in one cycle and are fully pipelined and cached etc.  Nearly all CPUs have [[Logical conjunction|AND]], [[Logical disjunction|OR]], [[Logical nor|NOR]], and [[Exclusive or|XOR]].  
Furthermore, modern CPUs have [[instruction pipeline]]s that queue instructions for execution.  A processor with multiple execution units can perform more than one instruction per cycle if more than one instruction is available in the pipeline.  Normal instruction sequences with branches may cause the pipeline to empty if a branch is mispredicted. Many bitboard operations require fewer conditionals and therefore increase pipelining and make effective use of multiple execution units on many CPUs.

CPUs have a bit width which they are designed toward and can carry out bitwise operations in one cycle in this width.  So, on a 64-bit or more CPU, 64-bit operations can occur in one instruction.  There may be support for higher or lower width instructions.  Many 32-bit CPUs may have some 64-bit instructions and those may take more than one cycle or otherwise be handicapped compared to their 32-bit instructions.

If the bitboard is larger than the width of the instruction set, multiple instructions will be required to perform a full-width operation on it.  So a program using 64-bit bitboards would run faster on a 64-bit processor than on a 32-bit processor.

====Cons====
Bitboard representations have much longer code, both source and object code.  Long bit-twiddling sequences are technically tricky to write and debug.  The bitboards themselves are sparse, sometimes containing only a single one bit in 64, so bitboard implementations are memory-intensive.  Both these issues may increase cache misses or cause cache thrashing.

If the processor does not have hardware instructions for 'first one' (or '[[count leading zeros]]') and '[[ONES|count ones]]' (or 'count zeros'), the implementation will be significantly handicapped, as these operations are extremely inefficient to code as assembly language loops.

===Cache and memory use===
====Pros====
Bitboards require more memory than piece-list board data structures, but are more execution efficient because many loop-and-compare operations are reduced to a single (or small number of) bitwise operation(s). For example, in mailbox, determining whether ''piece'' attacks ''space'' requires generating and looping through legal moves of ''piece'' and comparing the final space with ''space''.  With bitboards, the legal moves of ''piece'' are stored in a bitmap, and that map is ANDed with the bitmap for ''space''.  A non-zero result means that ''piece'' attacks ''space''.

====Cons====
For some games, writing a bitboard engine requires a fair amount of source code including data tables that will be longer than the compact mailbox/enumeration implementation. For mobile devices (such as cell phones) with a limited number of registers or processor instruction cache, this can cause a problem. For full-sized computers, it may cause cache misses between level-one and level-two cache. This is only a potential problem, not a major drawback, as most machines will have enough instruction cache for this not to be an issue.

===Incremental update===
Some kinds of bitboards are derived from others by an elaborate process of cross-correlation, such as the attack maps in chess.  Reforming all these maps at each change of game state (such as a move) can be prohibitively expensive, so derived bitmaps are incrementally updated, a process which requires intricate and precise code. This is much faster to execute, because only bitmaps associated with changed spaces, not all bitmaps over the board, need to change.  Without incremental update, bitmapped representation may not be more efficient than the older mailbox representation where update is intrinsically local and incremental.

===Precomputed bitmaps and table lookup===
Some kinds of bitmaps that don't depend on board configurations can be precomputed and retrieved by table lookup rather than collated after a move or state change of the board, such as spaces attacked by a knight or king located on each of 64 spaces of a chessboard that would otherwise require an enumeration.