« Everyone Should Know SIMD » : le rappel de Mitchell Hashimoto sur la seule optimisation qui compte encore

Mitchell Hashimoto (fondateur d'HashiCorp) signe un essai qui pose une thèse simple : à l'ère des CPU larges, ne pas connaître le SIMD, c'est laisser 4× à 16× de performance sur la table.

Le cas concret

Mitchell Hashimoto - le co-fondateur d'HashiCorp devenu contributeur individuel prolifique (il travaille aujourd'hui sur Ghostty, son émulateur de terminal en Zig) - publie un long billet intitulé simplement Everyone Should Know SIMD. La thèse tient en une phrase : dans un monde où les CPU stagnent en fréquence mais s'élargissent en registres vectoriels, ignorer le SIMD c'est laisser dormir des ordres de grandeur de performance.

SIMD (Single Instruction, Multiple Data) désigne les instructions CPU qui appliquent la même opération à plusieurs valeurs simultanément - additionner huit float en un seul cycle, comparer seize octets d'un coup. Sur les CPU x86-64 modernes, ce sont les jeux d'instructions SSE / AVX / AVX2 / AVX-512. Sur ARM (Apple Silicon, serveurs Neoverse), c'est NEON et SVE.

Sous le capot : pourquoi le sujet remonte

Le débat n'est pas nouveau - le SIMD existe depuis MMX (1996). Ce qui a changé :

1. La largeur des registres : 128 bits (SSE, NEON) → 256 bits (AVX2) → 512 bits (AVX-512). Un registre AVX-512 tient 16 float32 ou 64 int8.
2. La disponibilité : AVX2 est présent sur tout CPU x86 grand public depuis Haswell (2013). NEON est standard sur tout ARMv8 (iPhone 5S et postérieurs, tous les serveurs ARM).
3. La fréquence CPU plafonne : les gains « gratuits » d'une génération à l'autre s'amenuisent. La vectorisation, elle, continue de payer.
4. Les auto-vectoriseurs ont des limites : les compilateurs (LLVM, GCC) vectorisent bien les boucles simples, mais échouent souvent dès qu'il y a une branche, un pointer chasing, une accumulation particulière. Le programmeur doit y aller à la main.

Ce que Hashimoto dit

Le message central : le SIMD n'est pas réservé aux codeurs de moteurs graphiques ou de codecs vidéo. Toute manipulation de données en masse - parsers JSON, moteurs de recherche plein texte, comparaisons de chaînes, calculs statistiques, filtres d'image, hachages - bénéficie massivement d'un passage en vectoriel.

Des cas d'école tangibles :

• simdjson parse du JSON à 3-5 Go/s sur un CPU récent, en grande partie grâce au SIMD.
• Les moteurs de tri VqSort (Google) et ips4o utilisent le SIMD pour battre std::sort d'un facteur 3-5 sur des tableaux d'entiers.
• Les DB colonnaires (ClickHouse, DuckDB) sont construites autour de kernels SIMD.
• Le parsing de Protobuf et de UTF-8 peut être vectorisé pour un gain similaire.

Autrement dit : ce n'est plus une niche, c'est une compétence de base pour tout ce qui touche à la performance sur volume.

Comment s'y mettre sans se noyer

Le SIMD à la main est réputé pénible : intrinsics illisibles, portabilité fragile entre x86 et ARM. Trois approches viables aujourd'hui :

1. Highway (Google) : bibliothèque C++ qui abstrait SSE/AVX/NEON/SVE derrière une API commune, dispatch runtime selon le CPU.
2. std::simd (proposé pour C++26) : dans la STL, portable, mais encore expérimental.
3. Portable SIMD en Rust / Zig : les deux langages proposent des API vectorielles portables (core::simd en Rust nightly, @Vector builtin en Zig).

Pour un développeur applicatif « standard », l'entrée par une bibliothèque portable (Highway, std::simd, @Vector) évite de plonger dans les intrinsics de bas niveau tout en gardant l'essentiel du gain.

Notre lecture

Hashimoto touche juste : la génération de développeurs formée sur des runtimes managés (JavaScript, Python, Go) ignore souvent que le CPU dispose depuis dix ans de moyens de calcul qui ne sont jamais utilisés par leur code. Ce n'est pas une accusation - c'est un constat. Et le retour sur investissement, quand on connecte enfin ces moyens à un chemin critique, est spectaculaire.

À retenir

• Le SIMD n'est plus une optimisation exotique : c'est la source principale de gains restants sur CPU.
• Bibliothèques portables (Highway, std::simd, Zig @Vector) rendent l'entrée abordable.
• Tout ce qui traite des données en volume (parsers, DB, images, hashes) doit être questionné sous cet angle.