« Jeder sollte SIMD kennen »: Mitchell Hashimotos Erinnerung an die einzige Optimierung, die noch zählt

Mitchell Hashimoto (Gründer von HashiCorp) unterzeichnet einen Essay, der eine einfache These aufstellt: Im Zeitalter breiter CPU-Architekturen, SIMD nicht zu kennen, bedeutet, 4× bis 16× an Leistung liegen zu lassen.

Der konkrete Fall

Mitchell Hashimoto - Mitbegründer von HashiCorp, der zu einem produktiven Einzelbeitragenden wurde (er arbeitet heute an Ghostty, seinem Terminalemulator in Zig) - veröffentlicht einen langen Beitrag mit dem einfachen Titel Everyone Should Know SIMD. Die These lässt sich in einem Satz zusammenfassen: In einer Welt, in der die CPU-Frequenzen stagnieren, aber die Vektorregister breiter werden, bedeutet das Ignorieren von SIMD, Größenordnungen an Leistung ungenutzt zu lassen.

SIMD (Single Instruction, Multiple Data) bezeichnet die CPU-Befehle, die dieselbe Operation auf mehrere Werte gleichzeitig anwenden - acht float in einem Zyklus addieren, sechzehn Bytes auf einmal vergleichen. Auf modernen x86-64-CPUs sind dies die Befehlssätze SSE / AVX / AVX2 / AVX-512. Auf ARM (Apple Silicon, Neoverse-Server) ist es NEON und SVE.

Unter der Haube: Warum das Thema wieder aktuell wird

Die Diskussion ist nicht neu - SIMD existiert seit MMX (1996). Was sich geändert hat:

1. Die Breite der Register: 128 Bit (SSE, NEON) → 256 Bit (AVX2) → 512 Bit (AVX-512). Ein AVX-512-Register fasst 16 float32 oder 64 int8.
2. Die Verfügbarkeit: AVX2 ist auf jedem x86-CPU für den Massenmarkt seit Haswell (2013) vorhanden. NEON ist Standard auf jedem ARMv8 (iPhone 5S und neuer, alle ARM-Server).
3. Die CPU-Frequenz ist gedeckelt: Die "kostenlosen" Gewinne von einer Generation zur nächsten werden kleiner. Die Vektorisierung hingegen lohnt sich weiterhin.
4. Auto-Vektorisierer haben Grenzen: Die Compiler (LLVM, GCC) vektorisieren einfache Schleifen gut, scheitern aber oft, sobald es eine Verzweigung, ein Pointer Chasing oder eine besondere Akkumulation gibt. Der Programmierer muss es manuell tun.

Was Hashimoto sagt

Die zentrale Botschaft: SIMD ist nicht nur für Grafikmotor- oder Videocodec-Entwickler reserviert. Jede Massenverarbeitung von Daten - JSON-Parser, Volltext-Suchmaschinen, Zeichenkettenvergleiche, statistische Berechnungen, Bildfilter, Hashing - profitiert massiv von der Vektorisierung.

Einige konkrete Beispiele:

• simdjson parst JSON mit 3-5 GB/s auf einer aktuellen CPU, größtenteils dank SIMD.
• Die Sortiermaschinen VqSort (Google) und ips4o nutzen SIMD, um std::sort um den Faktor 3-5 auf Integer-Arrays zu schlagen.
• Spalten-Datenbanken (ClickHouse, DuckDB) sind um SIMD-Kerne herum aufgebaut.
• Das Parsen von Protobuf und UTF-8 kann vektorisiert werden, um einen ähnlichen Gewinn zu erzielen.

Mit anderen Worten: Es ist keine Nische mehr, es ist eine Grundkompetenz für alles, was mit Volumenleistung zu tun hat.

Wie man einsteigt, ohne zu ertrinken

SIMD von Hand ist berüchtigt für seine Unannehmlichkeiten: unlesbare Intrinsics, fragile Portabilität zwischen x86 und ARM. Drei heute gangbare Ansätze:

1. Highway (Google): Eine C++-Bibliothek, die SSE/AVX/NEON/SVE hinter einer gemeinsamen API abstrahiert und zur Laufzeit je nach CPU dispatcht.
2. std::simd (vorgeschlagen für C++26): In der STL, portabel, aber noch experimentell.
3. Portables SIMD in Rust / Zig: Beide Sprachen bieten portable vektorielle APIs (core::simd in Rust nightly, @Vector builtin in Zig).

Für einen "Standard"-Anwendungsentwickler ist der Einstieg über eine portable Bibliothek (Highway, std::simd, @Vector) der beste Weg, um nicht in die Low-Level-Intrinsics eintauchen zu müssen, während man dennoch den Großteil des Gewinns erzielt.

Unsere Meinung

Hashimoto hat recht: Die Generation von Entwicklern, die auf verwalteten Laufzeiten (JavaScript, Python, Go) ausgebildet wurde, ignoriert oft, dass die CPU seit zehn Jahren über Rechenmittel verfügt, die nie von ihrem Code genutzt werden. Das ist keine Anschuldigung - es ist eine Feststellung. Und der Return on Investment, wenn man diese Mittel endlich mit einem kritischen Pfad verbindet, ist spektakulär.

Zu beachten

• SIMD ist keine exotische Optimierung mehr: Es ist die Hauptquelle für verbleibende Gewinne auf der CPU.
• Portable Bibliotheken (Highway, std::simd, Zig @Vector) machen den Einstieg erschwinglich.
• Alles, was Daten in großen Mengen verarbeitet (Parser, DB, Bilder, Hashes), sollte unter diesem Gesichtspunkt hinterfragt werden.