Optimierungen durch Undefined Behavior: Gewinn oder Risiko im C und C++ Code?

Hier hat mal jemand geguckt, ob das Ausnutzen von Undefined Behavior in C und C++ für Optimierungen wirklich was bringt.

Das war ja immer die Begründung, weil solche Optimierungen ja in der Regel Dinge wegoptimieren, die da aus gutem Grund standen. Zum Beispiel hat der Linux-Kernel mal einen Null-Pointer-Check so verloren, und ansonsten sind es gerne mal Bounds-Checks, die einen Buffer Overflow verhindern sollten, oder Integer-Overflow-Checks, die auch Memory Corruption verhindern sollen.

Da war immer die Erzählung der Compiler-Leute: Jaja, das ist nicht optimal, aber die Performance, die wir da rausholen können!1!!

So und was findet dieses Paper jetzt heraus? Ich zitiere mal:

Using LLVM, a compiler known for its extensive use of UB for optimizations, we demonstrate that, for the benchmarks and UB categories that we evaluated, the end-to-end performance gains are minimal. Moreover, when performance regresses, it can often be recovered through small improvements to optimization algorithms or by using link-time optimizations.

Das ist ja schon ein ziemlich großer Krater hier gerade.

Für die Studie haben sie einen Haufen realer Software genommen, sowas wie Video- und Audiocodecs und andere Kompressionssoftware, aber auch LLVM selbst und ein paar Crypto-Libraries. Eine ziemlich breite Sammlung. Dann haben sie die dokumentierten Compilerflags angeschaltet, um solche Optimierungen abzuschalten, und mal geguckt, wie sich das Laufzeitverhalten verändert hat. Das ganze auf x86-Prozessoren von Intel und AMD und auf einem ARM64.

Die Performanceunterschiede bewegen sich im einstelligen Prozentbereich, sind aber erstaunlicherweise bei ARM deutlich höher als bei Intel und AMD.

Ich vermute mal, dass die Auswahl der Software hier einige Weichen gestellt hat, denn gerade Crypto-Code und Videocodecs haben gerne mal Assembleroptimierungen in ihren heißen Pfaden, und die sind dann von Compilerflags nicht betroffen. Das macht einen Großteil der Benchmarks aus. Statt simdjson hätte man vielleicht eine Nicht-SIMD-Variante nehmen müssen, um Auswirkungen zu sehen.

Aber hey, insgesamt sieht das methodisch erstmal gut aus und die Ergebnisse räumen die angeblichen Performancegewinne ziemlich nachhaltig weg. (Danke, Georg)

23.04.2025