A terminal maintainer's 12-line SIMD patch got a 5x speedup — and he wrote down the pattern that always works
Mitchell Hashimoto argues SIMD's reputation for complexity is undeserved: nearly every real vectorization follows the same five steps. He proves it on live Ghostty terminal code — a one-line scalar loop becomes twelve lines and up to 16x faster.
Mitchell Hashimoto argues SIMD — processing 4, 8, or 16+ values per CPU instruction instead of one — is simpler than its reputation, because nearly all real-world vectorized code follows the same five-step pattern.
He proves it on production Ghostty terminal code: a one-line scalar loop finding printable character runs becomes a twelve-line vectorized version, delivering roughly 5x real-world throughput on AVX2.
The sharpest thread reply wasn't about the code — it was about control: with SIMD explicit and hand-written, an unrelated compiler update can't silently turn your fast path back into a scalar loop without you noticing.
SIMD's reputation problem, and the five-step fix
Mitchell Hashimoto's essay opens with a direct challenge to how most developers think about SIMD (Single Instruction, Multiple Data) — the CPU feature that processes several values in one instruction instead of one at a time, with real speedups scaling directly with how many values fit in a vector register. His argument: SIMD has an unearned reputation for being an exotic, PhD-adjacent optimization technique, when in practice the vast majority of real vectorized code follows one repeatable pattern: broadcast a constant into vector form, loop over vector-width chunks instead of individual elements, apply the operation in parallel across all lanes at once, reduce the results back down as needed, and handle whatever's left over — the "remainder" that doesn't divide evenly into the vector width — with an ordinary scalar loop at the end.
Proof on real production code, not a toy example
Rather than a synthetic benchmark, Hashimoto walks through actual code from Ghostty, the terminal emulator he maintains: a routine that finds runs of printable characters in terminal output. The scalar version is a single line. The vectorized version, following his five-step pattern exactly, grows to twelve lines — and the real-world payoff scales with the instruction set available: up to 4x on ARM NEON, up to 8x on AVX2 (the baseline for most modern x86 chips), up to 16x on AVX-512. In actual end-to-end testing on an AVX2 system, the change delivered roughly a 5x real speedup — not a synthetic microbenchmark number, but a measured improvement in a real terminal's actual workload.
The walkthrough maps each section of the twelve-line version back to one of the five named steps, which is the essay's real pedagogical point: once you've internalized the pattern once, on one piece of code, you can recognize the same shape in almost any hot loop that processes large, uniform data — string scanning, image processing, numeric arrays — without needing to relearn vectorization from scratch each time.
Why hand-written beats "the compiler will figure it out"
One reply in the 111-comment thread pushed back gently on the case for going manual at all — modern compilers auto-vectorize plenty of simple loops with a flag like gcc -O3, no hand-written SIMD required. The counter-argument, quoted from the piece and expanded on by another commenter, is about control rather than raw speed: "when this loop matters enough for me to care about a 5x speedup, I want the vectorization to be explicit and predictable. I don't want an unrelated code change or compiler update to quietly turn it back into a scalar loop." Auto-vectorization is genuinely fragile — a compiler upgrade, a change to an unrelated function, or even flipping a constant from 1 to 1.0 elsewhere in the file can silently disable the optimization a codebase was quietly depending on, with no error and no warning, just a performance regression nobody notices until it's measured. One commenter drew the same failure mode from an entirely different domain — V8's JIT compiler — where the identical class of "invisible optimization that silently disappears" bug shows up constantly in JavaScript performance work. Hand-written SIMD trades a small amount of code volume and readability for a guarantee: the fast path is there because you put it there, and it stays there until you remove it, not until some unrelated dependency bump quietly takes it away.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
A historian's answer to AI slop: skip the algorithm, browse the library shelves by subject
Benjamin Breen argues the best non-fiction defense against AI slop was already sitting in research libraries — curated by prize committees and shelf classification, not engagement algorithms. A commenter's rebuttal: even prize juries get gamed by publishers submitting in bulk.