Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packed like sardines TT #3

Closed
wants to merge 1 commit into from
Closed

Packed like sardines TT #3

wants to merge 1 commit into from

Commits on Jun 17, 2014

  1. Packed like sardines TT

    This change supports 50% more entries for a given sized transposition table (`TT`). Elo is increased as fewer time-consuming position evaluations are needed.
    
    The old `TT` used 64-byte clusters, with each cluster containing 4 14-byte entries. This change uses 32-byte clusters, with each cluster containing 3 10-byte entries.
    
    To reduce each entry from 14 to 10 bytes, some fields in the `TTEntry` structure have been condensed:
    
    * The key field (32-bits) is now just 16-bits.
    * The generation (8-bits) and bound (8-bits) fields have been combined into a single 8-bit field with 6-bits used for the generation and 2-bits for the bound.
    * The depth field (16-bits) is now just 8-bits with the depth stored as an offset from the minimum depth `DEPTH_NONE` (which has been adjusted from -254 to -12). In this way, all depths can be stored as positive `uint8` values.
    
    Since only a partial key is stored with each entry, the same entry used to store information about one position might be used to store information about a different position. This produces occasional type-2 errors during probes, where a probe returns information for a wrong position. These rare, but possible, type-2 errant probes are automatically detected with the same logic that detects corrupted entries generated during unsafe threaded access to the `TT`.
    
    To improve speed, several optimizations have been made:
    * The number of entries in each cluster has been reduced from 4 to 3.
    * `first_entry` only uses 2 machine instructions and no longer uses a multiply.
    * The `probe` loop has been unrolled.
    * `store` writes the key only when necessary. It also evaluates only the second and third entries as potentially better replacement candidates, since the first entry starts as the best replacement candidate.
    Britvich committed Jun 17, 2014
    Configuration menu
    Copy the full SHA
    6dd856b View commit details
    Browse the repository at this point in the history