Il livello di ottimizzazione -O3 è pericoloso in g ++?

Ho sentito da varie fonti (anche se principalmente da un mio collega) che la compilazione con un livello di ottimizzazione di -O3in g ++ è in qualche modo "pericolosa" e dovrebbe essere evitata in generale a meno che non sia dimostrata necessaria.

È vero, e se sì, perché? Dovrei solo attenermi -O2?

Agli inizi di gcc (2.8 ecc.) E ai tempi di egcs, e redhat 2.96 -O3 a volte era piuttosto difettoso. Ma questo è successo più di un decennio fa e -O3 non è molto diverso da altri livelli di ottimizzazione (in buggy).

Tende tuttavia a rivelare casi in cui le persone fanno affidamento su comportamenti indefiniti, a causa del fatto di affidarsi più strettamente alle regole, e in particolare ai casi angolari, delle lingue.

Come nota personale, sto eseguendo software di produzione nel settore finanziario da molti anni ormai con -O3 e non ho ancora riscontrato un bug che non sarebbe stato lì se avessi usato -O2.

A grande richiesta, ecco un'aggiunta:

-O3 e in particolare flag aggiuntivi come -funroll-loops (non abilitato da -O3) a volte possono generare più codice macchina. In determinate circostanze (ad es. Su una CPU con cache di istruzioni L1 eccezionalmente piccola), ciò può causare un rallentamento a causa di tutto il codice, ad esempio di un ciclo interno, che ora non si adatta più a L1I. Generalmente gcc si impegna piuttosto a non generare così tanto codice, ma poiché di solito ottimizza il caso generico, ciò può accadere. Le opzioni particolarmente inclini a questo (come lo srotolamento del loop) normalmente non sono incluse in -O3 e sono contrassegnate di conseguenza nella manpage. Come tale, è generalmente una buona idea usare -O3 per generare codice veloce e ricorrere a -O2 o -Os (che tenta di ottimizzare la dimensione del codice) quando appropriato (ad es. Quando un profiler indica errori L1I).

Se vuoi portare l'ottimizzazione all'estremo, puoi modificare in gcc tramite --param i costi associati a determinate ottimizzazioni. Inoltre nota che gcc ora ha la capacità di mettere attributi su funzioni che controllano le impostazioni di ottimizzazione solo per queste funzioni, quindi quando trovi che hai un problema con -O3 in una funzione (o vuoi provare flag speciali solo per quella funzione), non è necessario compilare l'intero file o l'intero progetto con O2.

sembra che si debba fare attenzione quando si usa -Ofast, che afferma:

-Ofast abilita tutte le ottimizzazioni -O3. Consente inoltre ottimizzazioni non valide per tutti i programmi conformi standard.

il che mi porta a concludere che -O3 deve essere completamente conforme agli standard.

Nella mia esperienza in qualche modo a scacchi, l'applicazione -O3a un intero programma rende quasi sempre più lenta (rispetto a -O2), perché attiva lo srotolamento e l'inserimento di loop aggressivi che rendono il programma non più adatto alla cache delle istruzioni. Per programmi più grandi, questo può essere vero anche per quanto -O2riguarda -Os!

Lo schema d'uso previsto -O3è che, dopo aver creato il profilo del programma, lo si applica manualmente a una manciata di file contenenti loop interni critici che traggono effettivamente vantaggio da questi compromessi aggressivi spazio-velocità. Le versioni più recenti di GCC hanno una modalità di ottimizzazione guidata dal profilo che può (IIUC) applicare selettivamente le -O3ottimizzazioni alle funzioni a caldo, automatizzando efficacemente questo processo.

L'opzione -O3 attiva ottimizzazioni più costose, come l'integrazione delle funzioni, oltre a tutte le ottimizzazioni dei livelli inferiori "-O2" e "-O1". Il livello di ottimizzazione '-O3' può aumentare la velocità dell'eseguibile risultante, ma può anche aumentare le sue dimensioni. In alcune circostanze in cui queste ottimizzazioni non sono favorevoli, questa opzione potrebbe effettivamente rallentare un programma.

Sì, O3 è più forte. Sono uno sviluppatore di compilatori e ho identificato chiari e ovvi bug gcc causati da O3 che generava istruzioni di assemblaggio SIMD errate durante la creazione del mio software. Da quello che ho visto, la maggior parte dei software di produzione viene fornita con O2, il che significa che O3 riceverà meno attenzione rispetto ai test e alle correzioni di bug.

Pensala in questo modo: O3 aggiunge più trasformazioni sopra O2, che aggiunge più trasformazioni sopra O1. Statisticamente parlando, più trasformazioni significano più bug. Questo è vero per qualsiasi compilatore.

Di recente ho riscontrato un problema con l'ottimizzazione con g++. Il problema era legato a una scheda PCI, in cui i registri (per comando e dati) erano rappresentati da un indirizzo di memoria. Il mio driver ha mappato l'indirizzo fisico su un puntatore all'interno dell'applicazione e lo ha dato al processo chiamato, che ha funzionato con esso in questo modo:

unsigned int * pciMemory;
askDriverForMapping( & pciMemory );
...
pciMemory[ 0 ] = someCommandIdx;
pciMemory[ 0 ] = someCommandLength;
for ( int i = 0; i < sizeof( someCommand ); i++ )
    pciMemory[ 0 ] = someCommand[ i ];

La carta non ha funzionato come previsto. Quando ho visto l'assemblea ho capito che il compilatore ha scritto solo someCommand[ the last ]in pciMemory, tralasciando tutte le scritture precedenti.

In conclusione: essere accurati e attenti con l'ottimizzazione.