Compilazione di GNU / Linux con ottimizzazione -O3

Si dice che la compilazione di strumenti GNU e kernel Linux con -O3opzione di ottimizzazione gcc produrrà bug strani e funky. È vero? Qualcuno l'ha provato o è solo una bufala?

È usato in Gentoo e non ho notato nulla di insolito.

-O3 presenta diversi svantaggi:

1. Prima di tutto produce spesso un codice più lento di -O2o -Os. A volte produce codice più lungo a causa dello srotolamento del ciclo che può essere effettivamente più lento a causa delle peggiori prestazioni della cache del codice.
2. Come è stato detto, a volte produce un codice errato. Potrebbe essere dovuto a errore nell'ottimizzazione o errore nel codice (come ignorare l'aliasing rigoroso). Dato che il codice del kernel a volte è e talvolta deve essere "intelligente", direi che è possibile che alcuni sviluppatori del kernel abbiano commesso degli errori. Ho riscontrato vari strani problemi, come l'arresto anomalo delle utility di userspace, quando ho compilato il kernel con gcc 4.5 che a quel punto era stabile. Uso ancora gcc 4.4 per il kernel e diverse utility per lo spazio utente selezionate a causa di vari bug. Lo stesso può valere per -O3.
3. Non penso che offra molti vantaggi per il kernel Linux. Il kernel non esegue calcoli pesanti e in alcuni punti è ottimizzato con assembly. -O3flag non modificherà il costo del cambio di contesto o la velocità dell'I / O. Non credo che ne valga la pena qualcosa come una velocità <0.1% delle prestazioni complessive.

Si noti che grossi pezzi della toolchain (in particolare glibc) non vengono compilati se si modificano i livelli di ottimizzazione. Il sistema di compilazione è configurato per ignorare le tue preferenze -O per queste sezioni sulla maggior parte delle distro sane.

In poche parole, alcune funzionalità fondamentali della libreria e del sistema operativo dipendono dal fatto che il codice faccia effettivamente ciò che dice, non ciò che sarebbe più veloce in molti casi. -fgcse-after-ricaricare in particolare (abilitato da -O3) può causare strani problemi.

Negli ultimi 10 anni ho eseguito più sistemi Gentoo con oltre 1000 pacchetti in -O3 -march=nativetutto il mondo e non ho ancora incontrato nessuno di questi mitici problemi di stabilità che -O3dovrebbe avere. I benchmark delle applicazioni ad alta intensità di CPU (come le app matematiche / scientifiche) mostrano costantemente -O3di produrre codice più veloce, dopo tutto sarebbe inutile se non lo facesse. Per la maggior parte delle app desktop CFLAGSnon importa tanto quanto sono legate all'IO, ma conta molto per le cose lato server che sono legate alla CPU.

-O3 utilizza alcune ottimizzazioni aggressive che sono sicure solo se alcune assunzioni sull'uso del registro, su come interagiscono i frame dello stack e il rientro delle funzioni sono vere e queste assunzioni non sono garantite come vere in alcuni codici come il kernel, specialmente quando l'assemblaggio in linea è usato (com'è in alcune parti di livello molto basso del kernel e dei suoi moduli driver).

Mentre puoi cavartela usando -O3 e altre manopole di ottimizzazione sulla maggior parte delle applicazioni (e può portare a miglioramenti della velocità), esiterei a usare tali modifiche nel kernel stesso o nella catena di strumenti necessaria per costruirlo (compilatore, binutils, eccetera.).

Pensaci: un aumento delle prestazioni del 5% dei sottosistemi raid ed ext3 vale la pena crash del sistema o potenziale perdita e / o corruzione dei dati?

Modifica tutte le manopole che desideri per quella porta Quake che stai riproducendo o i codec audio / video che usi per copiare la tua collezione di DVD in file divx. Probabilmente vedrai un miglioramento. Basta non scherzare con il kernel se non si ha tempo da perdere e dati che si possono sopportare di perdere.