« Everyone Should Know SIMD » : el recordatorio de Mitchell Hashimoto sobre la única optimización que aún importa

Mitchell Hashimoto (fundador de HashiCorp) firma un ensayo que plantea una tesis simple: en la era de las CPU de gran ancho de banda, no conocer el SIMD es dejar sobre la mesa entre 4× y 16× de rendimiento.

El caso concreto

Mitchell Hashimoto — el cofundador de HashiCorp que se convirtió en un prolífico contribuyente individual (hoy trabaja en Ghostty, su emulador de terminal en Zig) — publica una larga entrada titulada simplemente Everyone Should Know SIMD. La tesis se resume en una frase: en un mundo donde los CPU dejan de aumentar en frecuencia pero crecen en registros vectoriales, ignorar el SIMD es dejar dormir órdenes de magnitud de rendimiento.

SIMD (Single Instruction, Multiple Data) se refiere a las instrucciones del CPU que aplican la misma operación a múltiples valores simultáneamente: sumar ocho float en un solo ciclo, comparar dieciséis bytes de golpe. En los CPU x86-64 modernos, estos son los conjuntos de instrucciones SSE / AVX / AVX2 / AVX-512. En ARM (Apple Silicon, servidores Neoverse), son NEON y SVE.

Bajo el capó: por qué el tema resurge

El debate no es nuevo: el SIMD existe desde MMX (1996). Lo que ha cambiado:

1. La anchura de los registros: 128 bits (SSE, NEON) → 256 bits (AVX2) → 512 bits (AVX-512). Un registro AVX-512 alberga 16 float32 o 64 int8.
2. La disponibilidad: AVX2 está presente en todos los CPU x86 de consumo desde Haswell (2013). NEON es estándar en todos los ARMv8 (iPhone 5S y posteriores, todos los servidores ARM).
3. La frecuencia del CPU se estanca: los beneficios «gratis» de una generación a otra se reducen. La vectorización, en cambio, sigue siendo rentable.
4. Los auto-vectorizadores tienen límites: los compiladores (LLVM, GCC) vectorizan bien los bucles simples, pero suelen fallar cuando hay una rama, un pointer chasing, una acumulación particular. El programador debe intervenir manualmente.

Lo que dice Hashimoto

El mensaje central: el SIMD no está reservado para los codificadores de motores gráficos o códecs de vídeo. Cualquier manipulación masiva de datos —parsers JSON, motores de búsqueda de texto completo, comparaciones de cadenas, cálculos estadísticos, filtros de imagen, hashes— se beneficia enormemente de la vectorización.

Casos tangibles:

• simdjson parsea JSON a 3-5 GB/s en un CPU reciente, en gran parte gracias al SIMD.
• Los motores de ordenamiento VqSort (Google) e ips4o usan SIMD para superar a std::sort en un factor de 3-5 en arrays de enteros.
• Las bases de datos columnares (ClickHouse, DuckDB) se construyen alrededor de kernels SIMD.
• El parsing de Protobuf y UTF-8 puede vectorizarse para obtener ganancias similares.

En otras palabras: ya no es una especialidad, es una habilidad básica para todo lo relacionado con el rendimiento sobre volumen.

Cómo empezar sin ahogarse

El SIMD manual es conocido por ser tedioso: intrinsics ilegibles, portabilidad frágil entre x86 y ARM. Tres enfoques viables hoy:

1. Highway (Google): biblioteca C++ que abstrae SSE/AVX/NEON/SVE tras una API común, con dispatch en tiempo de ejecución según el CPU.
2. std::simd (propuesto para C++26): en la STL, portable, pero aún experimental.
3. SIMD portable en Rust / Zig: ambos lenguajes ofrecen APIs vectoriales portables (core::simd en Rust nightly, @Vector builtin en Zig).

Para un desarrollador aplicativo «estándar», la entrada mediante una biblioteca portable (Highway, std::simd, @Vector) evita sumergirse en los intrinsics de bajo nivel sin perder lo esencial de la ganancia.

Nuestra lectura

Hashimoto acierta: la generación de desarrolladores formada en runtimes gestionados (JavaScript, Python, Go) suele ignorar que el CPU dispone, desde hace una década, de medios de cálculo que su código nunca aprovecha. No es una acusación, es un hecho. Y la rentabilidad, cuando finalmente se conectan esos medios a un camino crítico, es espectacular.

Para recordar

• El SIMD ya no es una optimización exótica: es la principal fuente de ganancias restantes en CPU.
• Las bibliotecas portables (Highway, std::simd, Zig @Vector) hacen la entrada accesible.
• Todo lo que procesa datos en volumen (parsers, bases de datos, imágenes, hashes) debe cuestionarse bajo este prisma.