--- title: 'EMOMA: Early Rejection via Lookup Table' url: https://www.emergentmind.com/topics/early-rejection-via-lookup-table type: topic --- # EMOMA: Early Rejection via Lookup Table Early rejection via lookup table refers to a mechanism that enables rapid elimination of non-existent keys in a lookup structure before off-chip memory accesses are performed, thus improving both the performance and efficiency of large-scale key-value storage systems. The EMOMA (Exact Match in One Memory Access) data structure operationalizes this principle using an on-chip counting block Bloom filter (CBBF) as a pre-filter, coupled with a two-choice cuckoo hash table in off-chip memory. This architecture ensures every lookup for a given key is resolved with at most one off-chip memory access—frequently rejecting absent keys without incurring such an access at all—by using the lookup table to disambiguate candidate memory locations and to guide early termination of unsuccessful searches [1709.04711]. ## 1. System Architecture and Lookup Path EMOMA’s design segregates responsibilities between its on-chip and off-chip components: - **On-chip elements:** These include the counting block Bloom filter (CBBF) and a small “stash,” a content-addressable memory (CAM) for temporarily holding elements during insertions or overflow situations. - **Off-chip elements:** The primary storage is a two-choice cuckoo hash table \(T\) of \(M\) buckets, each containing \(b\) slots, accessed via two hash functions \(h_1\) and \(h_2\). The CBBF is structured as \(M\) blocks of \(k\) bits each, with each block corresponding to a bucket in the cuckoo table and indexed by \(h_1(x)\). The stash, of bounded size \(s\), ensures progress in insertions even amidst rare displacement failures. CBBF counters to support deletions or updates may be kept off-chip but do not participate in the fast-path lookup. ## 2. Data Organization and On-Chip CBBF In EMOMA, each key-value pair \((x, v_x)\) is mapped to two potential buckets in \(T\): \(h_1(x)\) and \(h_2(x)\). The CBBF is arranged with one block per \(h_1\) bucket, within which \(k\) positions are determined by bit-selection hash functions \(g_1(x),\dots,g_k(x)\). ### Organization Table | Component | Location | Function | |-------------|------------|---------------------------------| | Cuckoo \(T\) | Off-chip | Main key-value storage | | CBBF | On-chip | Directs lookups, early rejects | | Stash \(S\) | On-chip | Assists insertions/failures | All present keys are stored in exactly one slot in \(T\); the CBBF is configured and maintained during insertions so that it directs retrieval with a single decisive bit-vector answer [1709.04711]. ## 3. Lookup Procedure and Early Rejection Mechanism The lookup starts by checking the stash for the queried key. If not present, the CBBF is queried using \(h_1(x)\) to retrieve a block and test whether all \(k\) corresponding bits are set. The outcome determines which bucket to probe in \(T\): - **CBBF negative:** The key cannot be in \(T[h_2(x)]\); \(T[h_1(x)]\) is checked. - **CBBF positive:** The key may reside in \(T[h_2(x)]\) (including possible false positives). Only the indicated bucket is read off-chip. If the key is found, its value is returned; otherwise, a miss is reported. The CBBF’s configuration avoids situations where multiple off-chip accesses would be necessary. Non-existent keys are frequently rejected entirely on-chip if the CBBF is negative, achieving “early rejection” [1709.04711]. ## 4. Insertion Procedure and Invariant Maintenance The insertion strategy in EMOMA is designed to uphold the invariant: > “Any key that would false-positive in the CBBF if placed in \(h_1\) is forced into \(h_2\).” The steps are as follows: - The new element is placed in the stash. - The CBBF is checked at \(h_1(x)\). If positive, \((x, v)\) is inserted into \(T[h_2(x)]\) and the appropriate CBBF bits are set; if negative and no false positives would be created for existing \(T[h_1(x)]\) entries, it is inserted into \(T[h_1(x)]\); otherwise, it is placed in \(T[h_2(x)]\). - If the target bucket is full, an eviction and re-insertion chain is initiated, using the stash as intermediate storage, until all keys are placed or the stash overflows. By always moving CBBF-conflicting keys to \(h_2\), EMOMA ensures the one-bit bucket decision remains correct for all lookups [1709.04711]. ## 5. Probabilistic Analysis and CBBF Parameters The false positive rate \(p_{\rm fp}\) of the CBBF follows a standard Bloom filter bound: \[ p_{\rm fp} \approx \left(1 - e^{-k n/M}\right)^k \] where \(n\) is the number of entries, \(M\) the number of buckets, and \(k\) the number of hash functions. With typical parameter choices (\(n/M \leq 0.95\) and \(k\approx3\) or 4), \(p_{\rm fp}\) remains a few percent. Crucially, EMOMA's invariant ensures any false positive in the CBBF does not result in a misdirected lookup but rather at most a single off-chip access with a correct miss result. If the CBBF is negative and the key was not inserted, early rejection occurs entirely on-chip [1709.04711]. ## 6. Comparative Evaluation with Alternative Schemes EMOMA’s effectiveness is benchmarked against classical cuckoo hashing and hybrid approaches (cuckoo plus Bloom filter): - **Off-chip accesses:** EMOMA guarantees exactly one for every lookup (hit or miss); standard cuckoo can require up to two, averaging \(1+p_{\rm miss}(h_1)\approx1.1\) at high load; traditional Bloom filter hybrids average \(1+p_{\rm fp}\approx1.05\), with a worst case of two. - **Throughput:** Given single-access per query, EMOMA enables pipelined designs—e.g., 50 ns DRAM latency supports ≈20 M lookups/s per port without stalls. - **Hardware resource usage:** The CBBF requires ≈4 bits per entry with simple shift/XOR logic, compared to >30 bits per entry and greater complexity for counting Bloom filter designs in pre-filtered Cuckoo table architectures. Empirical studies with millions of entries show EMOMA achieves ≈95% load, average 1.0 off-chip accesses per lookup, stash sizes <20, and maintains its efficiency across high-load scenarios [1709.04711]. ## 7. Insertion Costs and Limitations Insertion in EMOMA proceeds in an expected constant number of relocations for load factors up to ≈0.95, slightly lower than the ≈0.97 threshold conventional for classical cuckoo hashing. At 95% load, average insertion chains involve ≈30–50 relocations, and excess keys temporarily overflow to the small stash. The need to “lock” certain keys into \(h_2\) based on CBBF-induced conflicts incurs some complexity in insertion logic, but this does not impact the single-access guarantee or the early rejection property of the lookup path [1709.04711]. A plausible implication is that for applications with extremely high insertion-to-lookup ratios, EMOMA’s more involved insertion procedure may be less suitable, but for most packet processing workloads, where lookups dominate, the benefits for throughput and predictability are decisive. --- *For further details and empirical benchmarking, see "EMOMA: Exact Match in One Memory Access" [1709.04711].* Source: https://www.emergentmind.com/topics/early-rejection-via-lookup-table