A Hash That Collided on Every Name and a 25 MB Allocator Trap: What 4 Tracks of Speed Demon 2026 Taught Us About OS, Cache Hierarchy, and AI

A team competing as cONFIG in the Speed Demon 2026 hackathon rewrote four slow Python reference implementations in zero-dependency Rust and C++23, achieving speedups of 159× to 942× and memory reductions of 6.5× to 29.3× across ingest, index, join and graph-traversal tracks. The team reported that a custom hash function passed SHA-256 correctness checks while colliding every customer name into a single L1 cache slot, and that an munmap-based memory reduction attempt regressed wall time from 0.052 s to 0.066 s. They also cautioned that using AI to golf line count traps developers in a local optimum until they do the hardware and scoring-function math themselves.

TL;DR: For Speed Demon 2026 by Hackathon Raptors, our team cONFIG rewrote four deliberately slow Python reference implementations in zero-dependency Rust and C++23: This is the story of the mistakes that cost us the most time: a hash function that passed every SHA-256 gate while routing 100% of customer names into a single L1 slot, an munmap call that made memory no smaller and wall time worse, Golden Cove L1/L2/L3 cache sizing across 12 hyperthreads, and why golfing line count with AI traps you in a local optimum until you do the hardware and scoring-function math yourself. Repository: https://github.com/Yash-vs9/cOnfig-tracks https://github.com/Yash-vs9/cOnfig-tracks We entered all four tracks with zero external dependencies D = 1.00 , targeting the Falkenstein scoring box fsn1 : Intel Core i5-13500, 6 Golden Cove P-cores / 12 threads pinned via --cpuset-cpus="0-11" , turbo disabled at a fixed 2.50 GHz, 48 KiB L1d and 1.25 MiB L2 per P-core, 24 MiB shared L3. | Track | Task & Dataset | Language | Reference T ref / M ref | Our Best T / M / S | Speedup | Memory Reduction | K / Speed Score | |---|---|---|---|---|---|---|---| | Track A | Ingest 3.1M logs, 239 MB | Rust 2024 | 32.05 s / 228 MB | 0.034 s / 35 MB / 334 lines 282a0d6 | 942× | 6.5× | 34.19 76.70 | | Track B | Index 256 MB corpus, 50k queries | Rust 2024 | 56.35 s / 2,199 MB | 0.252 s / 75 MB / 1782 lines 282a0d6 | 223× | 29.3× | 18.84 63.75 | | Track C | Join 3.32M hostile CSV rows, 204 MB | C++23 | 14.44 s / 367 MB | 0.052 s / 15 MB / 332 lines 1e59383 | 277× | 24.5× | 26.72 71.34 | | Track D | Traverse 1.74M nodes, 5M edges, 2k queries | Rust 2024 | 72.69 s / 893 MB | 0.456 s / 83 MB / 704 lines 282a0d6 | 159× | 10.8× | 13.34 56.26 | The final numbers look clean in a table. Getting there was a sequence of wrong assumptions that the Falkenstein box corrected one by one. Track C asks you to join records.csv 3.32M rows against regions.csv and emit per-region aggregates, including the exact count of distinct customer name s per region dn . To avoid cross-core atomic contention on every row, we put a thread-local 2-way L1 filter tl cache 2048 2 32 KB per thread in front of a lock-free global hash table name keys 1 << 18 + a 256-bit region bitset name bits 1 << 18 4 . If name hash, region id was already in the thread's tl cache , we skipped the global table entirely. Here is the exact hash bytes function we shipped in commit 1e59383 0.052 s, 15 MB, 71.344 pts : js static inline uint64 t hash bytes const char s, uint32 t len { uint64 t h1 = len ^ 0x811c9dc5ULL, h2 = uint64 t len 0x9e3779b97f4a7c15ULL, w = 0, w1 = 0; if builtin expect len - 8U <= 8U, 1 { memcpy &w, s, 8 , memcpy &w1, s + len - 8, 8 ; h1 = mm crc32 u64 mm crc32 u64 h1, w , w1 ; h2 = h2 ^ w 0x9e3779b97f4a7c15ULL ^ w1 0x9e3779b97f4a7c15ULL; return h1 << 32 ^ h2 | 0x100ULL; } // ... } And inside the hot loop, we indexed the thread-local L1 filter using the low 11 bits of nh : uint32 t tl idx = uint32 t nh & 2047; It compiled cleanly. It passed every correctness check with an exact SHA-256 match. And when we shrunk the global table in commit 282a0d6 10 MB , our time actually regressed from 0.052 s to 0.066 s. Why? We finally dumped the raw hex output of hash bytes across customer names from the generator "Person 1001" , "Person 1002" , "Person 2500" , "Person 9999" : | Customer Name | 64-Bit Hash nh | Low 32 Bits uint32 t nh | tl idx = nh & 2047 | |---|---|---|---| | "Person 1001" | 0x369c194012cced30 | 0x12cced30 | 1328 | | "Person 1002" | 0x10cceab412cced30 | 0x12cced30 | 1328 | | "Person 2500" | 0xa08aee2a12cced30 | 0x12cced30 | 1328 | | "Person 5555" | 0xfba9c18c12cced30 | 0x12cced30 | 1328 | | "Person 9999" | 0xde6fb35212cced30 | 0x12cced30 | 1328 | Every 11-byte "Person XXXX" string had the exact same lower 32 bits 0x12cced30 and hashed to tl idx = 1328 . Look at what happened in the registers: "Person 1001" len = 11 , w first 8 bytes is "Person 1" and w1 last 8 bytes at s + 3 is "son 1001" . "son " 0x5f6e6f73 occupies bits 0..31 of "1001" occupy bits 32..63. 2^64 shifts bits strictly upward. Bits 32..63 of h2 h1 << 32 put the hardware CRC32 entirely into the upper 32 bits. Because the upper 32 bits h1 differed, the global hash table slot = nh ^ nh 32 & HT MASK still produced the right answer, so every correctness test passed. But tl idx = uint32 t nh & 2047 looked only at the bottom 11 bits, where "Person " and "son " were constant. Out of 2,048 slots in our L1 cache, 2,047 slots were permanently empty, and all 9,000+ names fought over the 2 ways of slot 1328, giving us a 99.98% L1 cache miss rate . Replacing the h2 multiply chain with a second mm crc32 u64 + a right-shift avalanche h ^ h 29 and an 8-miss software-pipelined mm prefetch ring buffer to hide the ~120-cycle L3 latency across 8 misses instead of probing 35 cycles after prefetching on the same row cut our sandbox join time from 74.1 ms to 50.9 ms . We originally wrote Track A in C++ and switched to zero-dependency Rust after seeing Rust dominate the top of the Track A board. Our first Rust push 1862874 , run-2f56a6016af5 ran in 0.0534 s with 42.0 MB of memory 69.88 pts . Adding an 8-byte SWAR latency parser and compacting lines for rustfmt 72.30 pts and vectorizing the endpoint space scan with AVX2 61516e3 , 75.06 pts brought our time down to 0.038 s, but our memory stayed stubbornly stuck at 42 to 44 MB, while the leaders were at 18 to 20 MB. Our static .bss struct SharedData was only ~20.8 MB. Where was the extra 23 MB coming from? Our wrong guess: We assumed the kernel was charging part of the 239 MB mmap of /data/requests.log against our container's memory counter. So we added hr buf and ep buf to copy the interned hour and endpoint strings out of the file mapping and called munmap bp, sz right after the scan phase finished. What the box said: Memory did not drop at all, and wall time got worse. The harness pre-warms /data/requests.log into the host page cache with vmtouch -t before the container starts. Under cgroups v2, mapping already-resident host page-cache pages with PROT READ + MAP SHARED charges 0 bytes of anonymous RSS to the container. Worse, cgroups v2 records memory.peak , the lifetime high-water mark of the container. Calling munmap after the scan phase cannot lower a peak that already happened; all it did was force Thread 0 to grab down write &mm- mmap lock in the kernel and tear down 61,184 page table entries while the clock was running. The actual culprit /proc/self/smaps : When we inspected /proc/self/smaps in our sandbox, two OS behaviors jumped out: l: u32; 49152 ; 12 when an hour had <= 49,152 requests, with a fallback v lats.resize tot, 0 Vec<u32 if a peak hour exceeded 49,152. Whenever a peak hour crossed 49,152 requests across 12 threads, Vec allocated and freed ~200 KB blocks concurrently. In glibc, freeing medium allocations across threads dynamically raises M MMAP THRESHOLD and creates 12 retained per-thread ptmalloc2 heap arenas ~18 MB of dirty anonymous pages that glibc never returns to the OS . std::thread::scope spawns threads with Linux's default 2 MB stack reservation. Widening the static .bss buffer to 75,000 per thread deleting Vec completely so malloc is never called in the worker loop , locking glibc with mallopt M ARENA MAX, 1 and mallopt M TRIM THRESHOLD, 0 , and spawning threads via Builder::new .stack size 65536 in commit 282a0d6 immediately dropped memory from 44 MB to 35 MB and brought wall time down to 0.034 s 76.695 pts . | Track A Optimization Step | Commit / Run ID | Time T | Memory M | Lines S | Score | |---|---|---|---|---|---| | Initial Rust CSR + CRC32 interning | 1862874 run-2f56a6016af5 | 0.0534 s | 42 MB | 468 | 69.88 | | SWAR 8-byte latency parse + rustfmt compaction | run-0b81b4911a21 | 0.0520 s | 43 MB | 240 | 72.30 | | AVX2 endpoint scanner + fixed hash bit-mixing | 61516e3 | 0.0380 s | 44 MB | 282 | 75.06 | | Zero-Vec .bss + mallopt + 64KB stacks + SWAR / writev | 282a0d6 | 0.0340 s | 35 MB | 334 | 76.70 | Modern CPUs are starving for data, not compute. On the Falkenstein runner Intel Core i5-13500, 6 Golden Cove P-cores / 12 hyperthreads pinned via --cpuset-cpus="0-11" , an L1 data cache hit takes ~4 cycles, an L2 hit takes ~14 cycles, an L3 hit takes ~45–60 cycles, and a main-memory DRAM miss costs ~200+ cycles. Because two sibling hyperthreads cpu 0 and cpu 1 share each physical P-core, they split that core's 48 KiB L1d cache 24 KiB effective per thread and 1.25 MiB L2 cache 640 KiB effective per thread , while all 12 threads share the 24 MiB L3. Once we stopped treating memory as a flat array and started sizing every data structure against those exact cache boundaries, bottlenecks started making sense across all four tracks: Domain Compression into L1/L2 Track C : Why build a std::unordered map when the key domain is tiny? In Track C, 3-letter uppercase country codes only have 26^3 = 17,576 possible combinations, so we mapped c0..c2 directly into uint16 t c to dense 17577 35.1 KiB, which fits inside L1/L2 . Likewise, 6-digit region id s 0..999,999 fit in a flat uint8 t reg lut 1000000 976 KiB, which fits entirely inside each P-core's 1.25 MiB L2 . Every relational foreign-key lookup became a single L2-resident byte load reg lut reg with zero pointer chasing. When Hyperthreads Evict Each Other's L1d Track A & Track C : In Track A, each thread had a 16 KiB direct-mapped stack cache lc: u64; 2048 2048 × 8 B to bypass global string interning. Two hyperthreads on the same P-core needed 32 KiB of lc alone, leaving only 16 KiB of the 48 KiB L1d for stack frames, requests.log streaming lines, and output chunks. Similarly, in Track C, a 32 KiB per-thread tl cache 2048 2 meant two sibling hyperthreads needed 64 KiB 16 KiB larger than L1d , constantly evicting hot lines down to L2. Eliminating MESI Cache-Line Bouncing False Sharing : When 12 threads increment adjacent counters in the same 64-byte cache line, the cores spend all their time invalidating each other's L1 caches over the ring bus. Sharding state into per-thread buffers T 12 256 in Track C, and 64-byte aligned repr C, align 64 blocks in Track A turned cross-core atomic wars into private L1 writes merged once at the end. While Track A and Track C were battles against SIMD byte parsing and cache-line contention, Track B and Track D taught us a different lesson: never build a general-purpose index when the query workload is sitting right there on disk. Track B hands you a 256 MB text corpus and queries.txt : 50,000 queries split between BOOL AND / OR / NOT, 62% and PHRASE "..." exact adjacent token positions, 38% . The Python reference takes 56.35 s and explodes to 2,199 MB of RAM because storing occurrence positions for every token in a 256 MB corpus eats gigabytes of memory. Because build and query execution are timed together in a single run, and queries.txt is readable from millisecond zero, building a full positional inverted index over the entire vocabulary is pure waste: queries.txt first, we know the exact set of terms that ever appear in any boolean query, and the even smaller subset of terms that ever participate in a PHRASE "..." query. BOOL queries only need document IDs or bitsets , never token positions. Combining query-driven vocabulary filtering with parallel 12-thread corpus chunking and smallest-first posting-list intersection took Track B from 0.314 s 62.16 pts in 61516e3 down to 0.252 s 223× faster than reference and 75 MB 29.3× less memory in commit 282a0d6 63.751 pts . 282a0d6 Track D gives you graph.txt 92 MB: 1,740,512 nodes and 5,000,000 directed weighted edges u v w , unsorted and 2,000 source-target shortest-path queries reference: 72.69 s, 893 MB . Here, heavy preprocessing like full Contraction Hierarchies doesn't have enough queries to pay back its build time, because the 2,000 queries are local with bounded search depth. Nearly the entire wall-clock battle is: u , v , strtol or scanf . target, weight array indexed by head u so edge relaxations hit sequential cache lines instead of chasing pointers across an 893 MB heap. dist, version tables so resetting Dijkstra between queries is a single version += 1 increment rather than a 7 MB memset 1,740,512 × 4 B × 2,000 queries = 13.9 GB of zeroing avoided . That brought Track D to 0.456 s 159× speedup and 83 MB 56.262 pts . One optimization on Track C deserves its own callout because it turned our slowest serial bottleneck into a 60-microsecond no-op. records.csv 204 MB, 3.32M rows has ~404,713 newlines inside quoted note fields. If you split the file at t sz / 12 for 12 threads t = 1..11 and advance to the next \n , you have a 50/50 chance of starting Thread t in the middle of a multi-line note and corrupting the parse. Our first version ran std::count across the 12 chunks to compute quote parity odd vs even number of " characters before cs t . Scanning 204 MB just to count quotes took 76.71 ms in our local sandbox, more time than the entire 12-thread join Then we looked at the grammar of records.csv . An embedded newline inside note is followed by free text, whereas a real record end is always preceded by ,region id, - DDD.CC\r?\n and followed by \xEF\xBB\xBF ? 0-9 +, : js static inline bool is rec end const char base, size t sz, const char nl { const char p = nl - nl base && nl -1 == '\r' ; if p - base < 6 || p -3 = '.' || p -1 < '0' || p -1 '9' || p -2 < '0' || p -2 '9' return false; p -= 3; int d am = 0, d reg = 0, d id = 0; while p base && p -1 = '0' && p -1 <= '9' --p, ++d am; if d am return false; if p base && p -1 == '-' --p; if p <= base || p -1 = ',' return false; --p; while p base && p -1 = '0' && p -1 <= '9' --p, ++d reg; if d reg || p <= base || p -1 = ',' return false; const char nx = nl + 1; if nx = base + sz return true; if nx + 3 <= base + sz && uint8 t nx 0 == 0xEF && uint8 t nx 1 == 0xBB && uint8 t nx 2 == 0xBF nx += 3; while nx < base + sz && nx = '0' && nx <= '9' ++nx, ++d id; return d id 0 && nx < base + sz && nx == ','; } Instead of scanning 204 MB from byte 0, each thread jumps directly to t sz / 12 and tests is rec end on the next 1–2 newlines. Chunk alignment dropped from 76.71 ms to 0.061 ms 1,257× faster . We finished around the top 40 overall. Halfway through the event, when the organizers shared that the top 20 entries across each track collectively used 49 to 73 distinct optimization techniques, we realized why our scores on Track A ~76.7 pts and Track C ~71.3 pts had started inching up by only +0.3 points per push. We had fallen into a classic local-optimum loop, compounded by how we were prompting AI and how we were treating the objective function. Look at the exponents in the composite factor K: K = T ref / T ^0.50 M ref / M ^0.25 S ref / S ^0.15 D^0.10 Because wall time T carries a 0.50 exponent while S post-rustfmt/clang-format scc line count carries only a 0.15 exponent: scc counts lines -Cprofile-generate / llvm-profdata / -fprofile-use and BOLT post-link binary layout optimization, deliver 8–15% wall-time reductions at zero When you give an AI coding assistant a 300-line file and say "optimize this and keep the line count low", the AI will relentlessly polish the micro-syntax of the architecture you already have: if statements into .then || ... to save a few lines. lock xadd atomic instructions s .c hid 2048 + eid .fetch add 1 instead of bit-packing is 5xx into bit 11 of the thread-local request word . c to dense 17577 and reg lut 1000000 so lookups never touch DRAM. mm256 movemask epi8 or a SWAR multiplier in seconds. What it cannot do on its own is tell you that 2 hyperthreads sharing a 48 KiB Golden Cove L1d cache are evicting each other's working sets, that glibc ptmalloc2 is retaining 12 heap arenas behind your back, or that little-endian 64-bit multiplication never shifts high-bit entropy into the low 32 bits. Built by team cONFIG for Speed Demon 2026, the 72-hour performance engineering championship organized by Hackathon Raptors. All four track solutions track-a , track-b , track-c , track-d and optimization logs are in our repository: https://github.com/Yash-vs9/cOnfig-tracks https://github.com/Yash-vs9/cOnfig-tracks .