"Dein Code ist schnell - wenn du Glück hast": Warum deine Mikro-Benchmarks lügen

Ein viraler Beitrag hinterfragt die Zuverlässigkeit von Mikrobenchmarks: Der gleiche Code kann je nach Reihenfolge der Symbole, der Position im Speicher oder dem Benutzernamen um 30 % variieren. Was das für das Crafting bedeutet.

In einfachen Worten

Ein Entwickler hat gezeigt, dass ein und derselbe Code je nach Parametern, die nichts mit dem Algorithmus zu tun haben, 30 % schneller oder langsamer sein kann: Reihenfolge der Symbole beim Linken, Größe der Umgebungsvariablen, Speicherausrichtung. Mit anderen Worten: Ein großer Teil dessen, was wir in Mikrosekunden messen, hängt vom Glück ab.

Die Geschichte

Der Autor, auf tiki.li/blog/lucky_code, greift einen bereits gut bekannten Thread bei den Compilern (Emery Berger, Stabilizer, ASPLOS 2013) auf und bringt ihn auf den neuesten Stand: Er führt denselben Binärcode aus, ohne ihn zu ändern, und variiert periphere Parameter (Name des Build-Verzeichnisses, Reihenfolge des Linkens der Objektdateien, Größe von $PATH). Die Laufzeiten ändern sich signifikant, bis zu über 30 % bei Mikrobenchmarks. Der Grund: Die Ausrichtung der Anweisungen in den L1i/uop-Caches, der x86-Decoder und die Branch-Vorhersage, die alle auf die virtuelle Adresse des Codes ansprechen.

Der Punkt, der jeden stören sollte: In der realen Welt vergleichen wir einen PR vor/nach, notieren eine Verbesserung von 8 %, und mergen. Wie viel davon ist echtes Signal? Wie viel ist Ausrichtungsrauschen?

Under the hood

• Stabilizer (Berger 2013) randomisiert die Zuweisung von Stack, Heap und Code bei jedem Lauf - die Messungen werden zu Verteilungen, nicht zu Punkten.
• Hyperfine + -warmup + -runs 50 löst NICHT das Problem: Es mittelt, aber die Ausrichtung bleibt bei jedem Lauf desselben Binärcodes gleich.
• Die gute Praxis: Mit zufälligen Offsets neu kompilieren (Stabilizer oder manuelles Padding) ODER mit -randomize-address ausführen und einen IC 95 % melden, nicht einen Durchschnitt.

So what

Drei Konsequenzen für das Handwerk. Eins: Jede Leistungssteigerung unter 10 % in einem einzelnen Mikrobenchmark ist wahrscheinlich Rauschen. Sie ablehnen oder unter Randomisierung wiederholen. Zwei: Die Leistungsregressionen der CI (z. B. Codspeed) müssen die Randomisierung übernehmen, sonst lassen wir echte Regressionen durchgehen und machen uns Sorgen über Rauschen. Drei: Die Marketing-Benchmarks von Compilern und Runtimes (Bun vs Node, Zig vs C…) müssen mit diesem Filter gelesen werden. Die Leistung auf diesem Niveau hängt ebenso vom Build-Engineering wie vom Algorithmus ab.