GNU / Linux mit -O3-Optimierung kompilieren

Es heißt, dass das Kompilieren von GNU-Tools und Linux-Kernel mit der -O3Option zur GCC-Optimierung seltsame und irre Fehler hervorrufen wird. Ist es wahr? Hat es jemand versucht oder ist es nur ein Scherz?

Es wird in Gentoo verwendet und ich habe nichts Ungewöhnliches bemerkt.

-O3 hat mehrere Nachteile:

1. Zuallererst erzeugt es oft langsameren Code als -O2oder -Os. Manchmal wird durch das Abrollen der Schleife längerer Code erzeugt, der aufgrund der schlechteren Cache-Leistung des Codes tatsächlich langsamer sein kann.
2. Wie gesagt wird manchmal falscher Code erzeugt. Dies kann entweder auf einen Fehler bei der Optimierung oder auf einen Fehler im Code zurückzuführen sein (z. B. auf das Ignorieren von striktem Aliasing). Da Kernel-Code manchmal "schlau" ist und manchmal "schlau" sein muss, würde ich sagen, dass es möglich ist, dass ein Kernel-Entwickler einen Fehler gemacht hat. Als ich den Kernel mit gcc 4.5 kompilierte, der zu diesem Zeitpunkt stabil war, hatte ich verschiedene seltsame Probleme, wie das Abstürzen der Userspace-Dienstprogramme. Ich benutze immer noch gcc 4.4 für den Kernel und einige ausgewählte Userspace-Dienstprogramme aufgrund verschiedener Fehler. Gleiches kann für gelten -O3.
3. Ich denke nicht, dass es für den Linux-Kernel viel Nutzen bringt. Der Kernel führt keine umfangreichen Berechnungen durch, und an bestimmten Stellen wird er mit der Assembly optimiert. -O3Das Flag ändert weder die Kosten für die Kontextumschaltung noch die E / A-Geschwindigkeit. Ich denke nicht, dass sich eine Beschleunigung der Gesamtleistung um <0,1% lohnt.

Beachten Sie, dass große Teile der Toolchain (insbesondere glibc) nicht kompiliert werden, wenn Sie die Optimierungsstufe ändern. Das Build-System ist so eingerichtet, dass Ihre -O-Einstellungen für diese Abschnitte in den meisten vernünftigen Distributionen ignoriert werden.

Einfach ausgedrückt, bestimmte grundlegende Bibliotheks- und Betriebssystemfunktionen hängen davon ab, ob der Code tatsächlich das tut, was er sagt, und nicht, was in vielen Fällen schneller wäre. Insbesondere -fgcse-after-reload (aktiviert durch -O3) kann seltsame Probleme verursachen.

In den letzten 10 Jahren habe ich weltweit mehrere Gentoo-Systeme mit über 1000 Paketen ausgeführt -O3 -march=nativeund bin noch keinem dieser mythischen Stabilitätsprobleme begegnet , -O3die auftreten sollen. Benchmarks von CPU-intensiven Anwendungen (wie Mathematik- / Wissenschafts-Apps) zeigen immer wieder -O3, dass sie schnelleren Code produzieren. Andernfalls wäre dies sinnlos. Für die Mehrheit der Desktop-Apps ist CFLAGSdas ohnehin nicht so wichtig, da sie an E / A gebunden sind, aber für serverseitige Dinge, die an die CPU gebunden sind, ist es sehr wichtig.

-O3 verwendet einige aggressive Optimierungen, die nur dann sicher sind, wenn bestimmte Annahmen zur Registernutzung, zur Interaktion mit Stack-Frames und zur Funktionsreentranz zutreffen. Diese Annahmen können in einigen Codes wie dem Kernel nicht garantiert werden, insbesondere wenn es sich um Inline-Assembly handelt verwendet (wie es in einigen Teilen des Kernels und seiner Treibermodule auf sehr niedriger Ebene ist).

Während Sie mit der Verwendung von O3 und anderen Optimierungen Knöpfen auf den meisten Anwendungen wegkommen können (und es kann in Geschwindigkeitsverbesserungen führen), würde ich zögern , so zwickt den Kernel selbst oder auf der Werkzeugkette für den Bau es (Compiler, binutils erforderlich zu verwenden, etc.).

Denken Sie darüber nach: Ist ein Leistungsgewinn von 5% der RAID- und EXT3-Subsysteme einen Systemabsturz oder einen möglichen Datenverlust und / oder eine Beschädigung wert?

Stellen Sie alle Regler auf den von Ihnen wiedergegebenen Quake-Port oder die Audio- / Video-Codecs ein, die Sie zum Kopieren Ihrer DVD-Sammlung in DivX-Dateien verwenden. Sie werden wahrscheinlich eine Verbesserung sehen. Verwirren Sie nur nicht mit dem Kernel, es sei denn, Sie haben Zeit zu verschwenden und Daten zu verlieren, die Sie ertragen können.