Inside Go 1.24 Swiss Tables: SIMD Control Words, Extendible Hashing, and 70% Memory Reductions

For over a decade, Go's built-in map[K]V relied on bucket-chaining: 8-element buckets (bmap), 8-bit tophash memoization bytes, and linked-list overflow buckets allocated on collision.

While dependable, this design created severe bottlenecks at scale. Chasing pointers through overflow buckets induced L1/L2 cache misses. Memory overhead was compounded by low load factors (6.5/8 or ~81.25%) and 8-byte pointer overhead per bucket. Large map growths triggered multi-millisecond rehashing pauses.

In Go 1.24, the runtime replaced the map engine with an implementation based on Google's Swiss Tables and extendible hashing (internal/runtime/maps), adapting open-address hashing to modern CPU pipelines.

By packing 8-slot metadata into 64-bit control words probed via SIMD vector instructions, raising load factor thresholds to 87.5%, and bounding growth pauses using extendible hashing, Go 1.24 delivers up to 60% faster lookups and up to 70% memory reduction in high-throughput workloads.

---

1. Architectural Anatomy: Bucket Chaining vs. Swiss Table Groups

+-----------------------------------------------------------------------------------------+
|                  GO 1.23 BUCKET CHAINING VS. GO 1.24 SWISS TABLE LAYOUT                 |
+-----------------------------------------------------------------------------------------+
| [LEGACY GO 1.23 BUCKET (bmap)]                                                          |
|   +---------------------------------------------------------------------------------+   |
|   | tophash: [uint8; 8] | keys: [K; 8] | values: [V; 8] | overflow: *bmap (8 bytes) |   |
|   +---------------------------------------------------------------------------------+   |
|                             │                                                           |
|                             └───> Overflow Bucket (Pointer Chasing -> Cache Miss)       |
+─────────────────────────────────────────────────────────────────────────────────────────+
                                          │
                                     VS.  ▼
+────────────────────────────────────────────────────────────────────────────────---------+
| [GO 1.24 SWISS TABLE GROUP (internal/runtime/maps/group.go)]                           |
|                                                                                         |
|   64-Bit SIMD Control Word (8 x 1-byte metadata):                                       |
|   +--------+--------+--------+--------+--------+--------+--------+--------+             |
|   | ctrl 0 | ctrl 1 | ctrl 2 | ctrl 3 | ctrl 4 | ctrl 5 | ctrl 6 | ctrl 7 |             |
|   +--------+--------+--------+--------+--------+--------+--------+--------+             |
|       ├── 0x80: Slot Empty (kEmpty)                                                     |
|       ├── 0xFE: Slot Deleted / Tombstone (kDeleted)                                     |
|       └── 0x00..0x7F: 7-bit H2 Hash Fingerprint (Live Slot)                             |
|                                                                                         |
|   Contiguous Key-Value Storage (slots 0..7):                                            |
|   +--------+--------+--------+--------+--------+--------+--------+--------+             |
|   | Slot 0 | Slot 1 | Slot 2 | Slot 3 | Slot 4 | Slot 5 | Slot 6 | Slot 7 |             |
|   |  K / V |  K / V |  K / V |  K / V |  K / V |  K / V |  K / V |  K / V |             |
|   +--------+--------+--------+--------+--------+--------+--------+--------+             |
|   * Open Addressing: NO overflow pointers! All slots probed via SIMD vector matching.   |
+-----------------------------------------------------------------------------------------+

The Inefficiency of Legacy Chaining

Under Go 1.23:

• Pointer Indirection: Overflow buckets linked via 8-byte pointers caused random memory dereferences, stalling execution on cache misses.
• Memory Footprint: Every bucket carried an overflow pointer field regardless of whether collisions occurred.
• Iterative Linear Probing: Searching within a bucket required scanning each tophash element sequentially in software loops.

Go 1.24 eliminates overflow bucket pointers. All entries reside in flat, contiguous memory arrays grouped into 8-slot clusters.

---

2. Hash Decomposition: H1 Routing and H2 Fingerprinting

When accessing a key (m[k]), Go 1.24 computes a 64-bit hash (hash(k)) using runtime AES-NI or Wyhash:

 63                                                      7 6             0
+---------------------------------------------------------+---------------+
|                H1: 57 Upper Bits                        | H2: 7 Bits    |
| (Table Indexing & Intra-Table Group Probing Route)      | (Fingerprint) |
+---------------------------------------------------------+---------------+

1. H1 (Top 57 Bits): Routes requests across tables and determines the starting group index within the target Swiss Table.
2. H2 (Bottom 7 Bits): Acts as a high-entropy 7-bit fingerprint (0x00 to 0x7F). Stored directly in the control byte corresponding to the slot, H2 serves as a rapid filter before full-key comparisons are attempted.

---

3. Vectorized SIMD and SWAR Parallel Probing

Instead of checking slots sequentially, Go 1.24 evaluates all 8 slots in a group simultaneously within a single CPU clock cycle:

+-----------------------------------------------------------------------------------------+
|                  PARALLEL 8-SLOT EVALUATION VIA SIMD VECTOR INSTRUCTIONS                |
+-----------------------------------------------------------------------------------------+
| 1. Broadcast Target H2 across 8-byte Vector:                                            |
|    _mm_set1_epi8(H2) -> [H2, H2, H2, H2, H2, H2, H2, H2]                                |
| 2. Load 64-bit Control Word from Group:                                                 |
|    [ctrl0, ctrl1, ctrl2, ctrl3, ctrl4, ctrl5, ctrl6, ctrl7]                             |
| 3. Single-Instruction Byte Comparison:                                                  |
|    _mm_cmpeq_epi8(BroadcastH2, ControlWord) -> [0xFF if match, 0x00 if mismatch]        |
| 4. Extract Candidate Bitmask:                                                           |
|    _mm_movemask_epi8() -> Produces 8-bit Candidate Bitmask (e.g., 0b00000100)            |
| 5. Direct Key Comparison:                                                               |
|    Only Slot 2 is accessed in main memory! False match rate is only 1/128 (~0.78%).     |
+-----------------------------------------------------------------------------------------+

Portable SWAR Fallback (SIMD Within A Register)

On architectures lacking native 8-byte vector equality instructions, Go 1.24 implements SWAR (SIMD Within A Register):

func matchH2(ctrl uint64, h2 uint8) uint64 {
    mask := uint64(h2) * 0x0101010101010101
    diff := ctrl ^ mask
    return (diff - 0x0101010101010101) & ^diff & 0x8080808080808080
}

Because H2 contains 7 bits of entropy, the probability of a false-positive collision is only $1 / 128 \approx 0.78%$. When no candidate bits match, the entire group is rejected without touching main memory.

---

4. Bounded Latency: Extendible Hashing Directory

In conventional Swiss Tables, resizing a large table requires allocating a double-sized array and migrating all entries at once. Go 1.24 prevents long pauses by coupling Swiss Tables with Extendible Hashing:

+-----------------------------------------------------------------------------------------+
|                  EXTENDIBLE HASHING DIRECTORY ARCHITECTURE                              |
+-----------------------------------------------------------------------------------------+
| [Runtime Map Header]                                                                    |
|   dirPtr: Pointer to Directory Entries | dirLen: Length | globalDepth: Directory Depth  |
|         ├───> Directory Entry [00] ───> Table A (Local Depth 2, Max 1,024 slots)        |
|         ├───> Directory Entry [01] ───> Table B (Local Depth 2, Max 1,024 slots)        |
|         ├───> Directory Entry [10] ───> Table C (Local Depth 2, Max 1,024 slots)        |
|         └───> Directory Entry [11] ───> Table D (Local Depth 2, Max 1,024 slots)        |
|                                                                                         |
| [TABLE SPLIT ON OVERFLOW (Bounded Growth)]                                              |
|   When Table B reaches 87.5% capacity (128 groups = 1,024 slots):                       |
|   1. Only Table B is split into Table B1 and Table B2!                                  |
|   2. Tables A, C, and D remain completely untouched in memory!                          |
|   3. Maximum element migration pause is bounded strictly to 1,024 entries!             |
+-----------------------------------------------------------------------------------------+

The 1,024-Slot Invariant

• Bounded Table Size: Each Swiss Table in the directory stores a maximum of 128 groups (1,024 slots).
• Independent Splitting: When an individual table exceeds the 7/8 load factor threshold, only that 1,024-slot table is divided.
• Predictable Latency: By capping reallocation to 1,024 entries, Go 1.24 ensures map growth latency remains strictly bounded.

---

5. Small Map Optimization & Deletion Semantics

For maps with $\le 8$ elements, Go 1.24 bypasses directory indirection:

• Direct Pointer: dirPtr points directly to a single 8-slot group.
• Zero Indirection: Directory lookup and hash split overhead are eliminated.
• No Tombstones: Because all 8 slots are checked in one SIMD instruction, deletions reset the control byte directly to 0x80 (kEmpty).

In larger maps, deleted slots receive a tombstone marker (0xFE / kDeleted):

1. Search Continuation: Probing algorithms treat 0xFE as occupied, maintaining probe continuity.
2. Insertion Recycling: Probing tracks the first tombstone and reuses it if the key is not found.
3. pruneTombstones Compaction: When tombstones exceed 10% of total capacity, Go 1.24 triggers an in-place pass (pruneTombstones) before allocating memory.

---

6. Empirical Benchmarks: Production Performance Gains

Profiling across microbenchmarks and hyper-scale distributed services (Datadog and VictoriaMetrics) demonstrates marked performance gains:

Go 1.24 sustains a maximum load factor of $7 / 8 = 87.5%$ without degradation. Fewer empty slots and the absence of 8-byte overflow pointers drive the ~70% memory reduction in large-scale services.

---

7. Systems Engineering & Production Migration Playbook

Go 1.24 maintains strict backwards compatibility under the Go 1 promise. Existing map[K]V code requires no modifications.

Systems engineers should adopt these production practices:

1. Fallback Experiment Flag (noswissmap)

If production workloads hit unexpected edge regressions, Go 1.24 provides a compile-time fallback:

GOEXPERIMENT=noswissmap go build -o backend main.go

(Note: GOEXPERIMENT=noswissmap will be removed in Go 1.26 alongside legacy bucket code).

2. Pre-Allocate Map Capacity

While extendible hashing minimizes growth pauses, pre-allocating known capacities via make(map[K]V, hint) avoids directory reallocations and sizes tables to the optimal 87.5% load factor.

3. Clear vs. Re-Allocate

In Go 1.24, invoking clear(m) efficiently resets all control bytes to 0x80 (kEmpty) in contiguous SIMD vector blocks without deallocating underlying group arrays.

---

8. Semantic FAQ: Go 1.24 Swiss Tables

What are Swiss Tables in Go 1.24?

Swiss Tables are open-address hash tables using 64-bit metadata control words and SIMD vector instructions to inspect 8 slots in parallel, replacing legacy bucket chaining.

Why did Go adopt Extendible Hashing alongside Swiss Tables?

Standard Swiss Tables double the entire table upon reaching capacity, causing GC and latency pauses for large maps. Extendible hashing limits individual table sizes to 1,024 slots, ensuring table-splitting pauses remain bounded.

Does Go 1.24 change map iteration order or semantics?

No. Go 1.24 continues to randomize iteration order using randomized hash seeds per map instance. Concurrent read/write detection still triggers immediate runtime panics.

How does Go 1.24 achieve up to 70% memory reduction?

By eliminating 8-byte overflow bucket pointers, increasing the maximum load factor to 87.5% (7/8), and avoiding sparse linked-list allocations, large maps consume dramatically less heap memory.

Are SIMD instructions supported on ARM64 and Apple Silicon?

Go 1.24 ships with native 8-byte SIMD vector comparisons for amd64. On architectures where dedicated vector instructions are absent, the runtime executes optimized 64-bit SWAR bitwise arithmetic delivering equivalent parallel matching without hardware vector registers.