Potential SIMD inside a Transposition Table

[Stephen Fleischman]

Marking this as a long-term TODO, as the SIMD features required for this have not yet stabilized in rust,

Preface

Currently, the Transposition Table (TT) works with by hashing a Zobrist key to a Cluster. Each Cluster contains 3 possible Entrys, where each one is likely to correlate to a specific position:

pub struct Cluster {
    pub entry: [Entry; CLUSTER_SIZE],
    pub padding: [u8; 2],
}

pub struct Entry {
    pub partial_key: u16,
    pub best_move: BitMove, // What was the best move found here?
    pub score: i16, // What was the Score of this node?
    pub eval: i16, // What is the evaluation of this node
    pub depth: u8, // How deep was this Score Found?
    pub time_node_bound: NodeTypeTimeBound,
}

The key for the TT (the Zobrist Hash) is a u64 corresponding to a position. This hash is not guaranteed to be unique to a specific position, so there is always a risk of collisions / overlap in keys.

We determine which Cluster a hash might lie in by taking the lower x bits of the hash as the index. A TT is always guaranteed to contain 2^x number of Clusters inside of itself, so we can effectively use the lower bits as an index. From there, we determine the Entry a key might lie in by matching the upper 16 bits to the partial_key in each entry.

SIMD

While this is an O(n) operation, we have to search 3 Entrys inside each cluster for a possible match. While this is still a very inexpensive operation, I think it'd be worth the time to explore SIMD operations to both

1. Increase the Cluster Search speed from O(n) to O(1)
2. Increase the Cluster size to fit addition Entrys with the O(1) search time.

[Stephen Fleischman]

Despite the recent inclusion of SIMD in the standard library, I don't see how SIMD could reliably speed up the lookup of Transposition Table entries.

Closing this, as it's not something I foresee being useful.