GCC optimization/it

Questa guida fornisce un'introduzione all'ottimizzazione del codice compilato utilizzando valori sicuri per le variabili CFLAGS e CXXFLAGS. Inoltre viene descritta la teoria a fondamento dell'ottimizzazione in generale.

Cosa sono CFLAGS e CXXFLAGS?
CFLAGS e CXXFLAGS sono due tra le variabili d'ambiente che vengono convenzionalmente utilizzate per specificare opzioni di compilazione ad un sistema in via di costruzione quando si compila codice C e C++. Benché queste variabili non siano standardizzate, il loro uso è essenzialmente ubiquitario e qualsiasi build (compilazione) scritta correttamente dovrebbe venire a conoscenza di queste variabili per fornire opzioni extra o personalizzazioni quando si invoca il compilatore. Vedere la pagina delle informazioni GNU make per una lista di alcune delle variabili più usate in questa categoria.

Poiché la maggior parte dei pacchetti che costituiscono i sistemi Gentoo sono scritti in C e C++, queste sono due variabili che gli amministratori dovranno impostare correttamente, in quanto eserciteranno una grande influenza sul modo in cui verrà costruito il sistema.

Possono essere usate per ridurre la quantità di messaggi di debug per un programma, per incrementare i livelli dei messaggi di avvertimento e, ovviamente, per ottimizzare il codice prodotto. Il manuale GCC contiene una lista completa delle opzioni disponibili e dei loro scopi.

Come vengono usate?
Normalmente, CFLAGS e CXXFLAGS verrebbero inizializzate nell'ambiente al momento dell'invocazione di uno script configure o con Makefile generati da. Nei sistemi basati su Gentoo, le variabili CFLAGS e CXXFLAGS vengono impostate nel file. Le variabili impostate in questo file verranno esportate nell'ambiente dei programmi invocati da portage, in modo tale che tutti i pacchetti vengano compilati usando quelle opzioni di base.

Come è possibile vedere nell'esempio sopra, la variabile CXXFLAGS è configurata in modo da usare le stesse opzioni presenti su CFLAGS. La maggior parte dei sistemi dovrebbe essere configurato in questa maniera. Le opzioni aggiuntive in CXXFLAGS sono meno comuni e non si dovrebbero impostare globalmente.

Fraintendimenti
Anche se le variabili CFLAGS e CXXFLAGS possono essere un modo valido per produrre codice binario più piccolo o più veloce, se utilizzate in modo errato, possono compromettere la funzionalità del codice stesso, aumentare a dismisura le sue dimensioni, ridurre drasticamente le prestazioni. La loro configurazione errata può anche provocare errori di compilazione. La soglia di riduzione delle prestazioni viene raggiunta piuttosto rapidamente quando si armeggia con le CFLAGS. Non si impostino arbitrariamente.

È bene ricordare che la variabile globale CFLAGS configurata in verrà applicata ad ogni pacchetto del sistema, pertanto gli amministratori configureranno solo opzioni generali e applicabili su vasta scala. I singoli pacchetti modificano ulteriormente queste opzioni sia nell'ebuild che nel sistema compilato stesso per generare l'insieme finale di flag da usare quando si invoca il compilatore.

Pronto?
Ora che si è stati avvisati dei possibili rischi, diamo uno sguardo ad alcune equilibrate e sicure ottimizzazioni. Queste vi manterranno entro condizioni ottimali e saranno gradite agli sviluppatori quando ci sarà occasione di segnalare un problema su Bugzilla. (Gli sviluppatori di solito richiedono all'utente di ricompilare il pacchetto con un insieme ridotto di CFLAGS per vedere se il problema persiste. Si ricordi che opzioni aggressive possono rovinare il codice!)

Le basi
Lo scopo che ci si pone utilizzando le CFLAGS e le CXXFLAGS è di creare codice su misura per il sistema dell'utente; tale sistema dovrebbe funzionare perfettamente ed essere anche snello e veloce, se possibile. Alcune volte queste ultime due condizioni si escludono a vicenda, e pertanto questa guida si limiterà ad utilizzare combinazioni note per funzionare bene. Idealmente, si tratta delle migliori combinazioni per ogni architettura di CPU. Verrà fatta menzione delle opzioni aggressive più in là, in modo tale che l'utente possa sapere cosa bisogna evitare. Non verrà discussa ogni opzione presente nel manuale di  (ce ne sono centinaia) ma verranno spiegate solo le opzioni fondamentali e quelle più comuni.

-march
La prima e più importante opzione è. Questa comunica al compilatore di produrre codice per una certa architettura di processori (o arch); essenzialmente dice a GCC di produrre codice per un certo tipo di CPU. CPU diverse possiedono diverse funzionalità, supportano diversi insiemi di istruzioni e hanno diverse modalità di esecuzione del codice. L'opzione  indica al compilatore di produrre codice specifico per la CPU del sistema, con tutte le sue funzionalità, caratteristiche, insiemi di istruzioni, stranezze, e così via, purché il codice sorgente sia pronto per utilizzarle. Per esempio, per trarre beneficio dalle istruzioni AVX, il codice sorgente deve essere adattato per supportarle.

è un'opzione di selezione ISA; indica al compilatore che potrebbe usare le istruzioni dall'ISA. Su una piattaforma Intel/AMD64 con  o un livello OPT inferiore, il codice probabilmente verrà concluso con le istruzioni AVX presenti ma servendosi di registri SSE XMM più brevi. Per sfruttare al meglio i registri AVX YMM, si dovrebbero usare anche le opzioni,   o.

è un'opzione di ottimizzazione (predefinita con  e  ), che tenta di vettorializzare i cicli usando l'ISA selezionata se possibile. La ragione per cui non viene abilitata con  è che non sempre migliora il codice, può renderlo anche più lento, e solitamente più grande; ciò dipende da vari fattori, come anche dal tipo di ciclo, ecc.

Anche se la variabile CHOST nel file specifica l'architettura generale utilizzata,   dovrebbe comunque essere utilizzata così che i programmi possano essere ottimizzati per il processore specifico sul sistema. In particolare, le CPU x86 e x86-64 (fra le altre) dovrebbero utilizzare l'opzione.

Quale CPU è presente nel sistema? Per scoprirlo, si esegua il seguente comando:

oppure installare e aggiungere le opzioni specifiche della CPU al file, cosa che viene fatta dallo strumento  per esempio tramite la variabile CPU_FLAGS_X86:

Per ottenere maggiori dettagli, compresi i valori di  e , si possono usare due comandi.


 * Il primo comando dice al compilatore di non effettuare alcun collegamento, ed invece di interpretare l'opzione  per fornire chiarimenti sulle opzioni da linea di comando, mostra quali opzioni sono abilitate o disabilitate . In questo caso, le opzioni mostrate sono quelle abilitate per l'obiettivo (target) selezionato:


 * Il secondo comando mostrerà le direttive del compilatore per la costruzione del file header, ma senza effettuare le operazioni piuttosto mostrandole solamente sullo schermo . La linea dell'output finale è il comando che contiene tutte le opzioni di ottimizzazione più l'architettura selezionata:

Si veda ora  in azione. Questo è un esempio per un vecchio processore Pentium III:

Invece questo esempio è per una CPU AMD a 64 bit:

Se il tipo di CPU è indeterminato, o se l'utente non sa quale impostazione scegliere, è possibile usare l'opzione. Quando viene usata questa opzione, GCC proverà a rilevare il processore ed impostare automaticamente le opzioni più appropriate. Tuttavia, questa opzione non deve essere usata se l'intento è quello di compilare pacchetti per CPU diverse!

Se si compilano pacchetti su un computer per poi eseguirli su un altro computer (ad esempio nel caso in cui si dispone di un computer veloce che compila pacchetti da utilizzare su un computer più datato e lento), non bisogna utilizzare l'opzione. Native significa che il codice prodotto da una certa CPU potrà essere eseguito solo su quel tipo di CPU. Le applicazioni compilate con  su una CPU AMD Athlon 64 non potranno essere eseguite su una vecchia CPU VIA C3.

Esistono anche le opzioni  e. Esse sono solitamente utilizzate solo quando l'opzione  non è disponibile; le architetture di alcuni processori possono richiedere   o addirittura. Sfortunatamente il comportamento di GCC non è molto coerente nel modo in cui ciascuna opzione si comporta passando da un'architettura all'altra.

Su CPU x86 e x86-64,  genererà codice specifico per quella CPU usando il suo insieme di istruzioni disponibile ed il corretto ABI; non ci sarà retro compatibilità con CPU più vecchie o differenti. Si consideri l'uso di  quando si genera codice per CPU più vecchie come le i386 e le i486. produce codice più generico rispetto a ; sebbene possa accordare il codice per una certa CPU, non tiene conto dell'insieme di istruzioni disponibili e dell'ABI. Non utilizzare  su sistemi x86 o x86-64 in quanto è deprecato per quelle architetture.

Solo CPU diverse da x86/x86-64 (come SPARC, Alpha e PowerPC) possono richiedere  o   invece di. Su queste architetture  e   si comporteranno talvolta come   (su architettura x86/x86-64) ma con un differente nome opzione. Nuovamente, il comportamento di GCC e la denominazione delle opzioni non è coerente attraverso le varie architetture, dunque per essere sicuri controllare il manuale di GCC per stabilire ciò che si dovrebbe usare.

-O
La prossima variabile da considerare è. Questa permette di controllare il livello complessivo di ottimizzazione. Cambiare questo valore comporterà un tempo di compilazione maggiore ed un utilizzo di memoria molto più grande, specialmente con l'innalzamento del livello di ottimizzazione.

Esistono sette possibili impostazioni per : ,  ,  ,  ,  ,   e. Si scelga solo una tra esse nel file.

Con la sola eccezione di, ciascuna delle impostazioni di   attiva alcune opzioni aggiuntive. Assicurarsi quindi di leggere il capitolo del manuale GCC sulle opzioni per l'ottimizzazione per capire quali opzioni vengano attivate con ciascuno dei livelli di  e qual sia la loro funzione.

Esaminiamo ora ciascuno dei livelli di ottimizzazione:


 * : questo livello (che consiste nella lettera "O" seguita da uno zero) disattiva interamente l'ottimizzazione del codice ed è la scelta predefinita qualora nessuna opzione  venga specificata in CFLAGS o CXXFLAGS . Ciò riduce i tempi per la compilazione e può migliorare le informazioni per il debug, ma alcune applicazioni potrebbero non funzionare correttamente se nessuna ottimizzazione è attiva. Pertanto questa scelta è sconsigliata, a meno che lo scopo sia proprio il debug delle applicazioni.


 * : è il livello di ottimizzazione base. Il compilatore proverà a produrre codice più veloce e più snello, senza richiedere troppo tempo per la compilazione. Si tratta di un'opzione base, ma dovrebbe fare un buon lavoro in ogni circostanza.


 * : è il passo successivo rispetto a . È il livello di ottimizzazione raccomandato, salvo esigenze particolari.   attiva alcune ulteriori opzioni rispetto a quelle utilizzate da  . Con   il compilatore proverà ad incrementare le prestazioni del codice senza comprometterne le dimensioni, e senza richiedere un tempo eccessivo. In questo livello SSE o AVX potrebbero essere utilizzate, ma nessun registro YMM verrà usato a meno che non sia abilitato anche.


 * : è il livello di ottimizzazione più alto possibile. Vengono attivate ottimizzazioni costose dal punto di vista del tempo di compilazione e dell'utilizzo di memoria. Compilare con  non è un modo sicuro di migliorare le prestazioni del codice; in molti casi si ottiene il rallentamento del sistema a causa di codice binario più grande e dell'utilizzo maggiore di memoria.   è anche noto per causare la corruzione di alcuni pacchetti. Usare   non è raccomandato. Tuttavia, abilita anche   così che i cicli nel codice diventino vettorializzati e saranno usati i registri AVX YMM.


 * : ottimizza il codice dal punto di vista delle dimensioni. Attiva tutte le opzioni di  che non comportino l'incrementano delle dimensioni del codice prodotto.   può essere utile per macchine che hanno una capacità di archiviazione su disco estremamente limitata o CPU con una piccola cache.


 * : questa opzione è stata introdotta con GCC 4.8. Essa soddisfa il bisogno di ridurre i tempi della compilazione e quello di migliorare la capacità di effettuare il debug mantenendo però un ragionevole livello prestazionale in fase di esecuzione. Complessivamente con  l'attività di sviluppo dovrebbe risultare migliore rispetto a  . Si noti che   non implica  ; piuttosto si limita semplicemente a disattivare le ottimizzazioni che hanno ripercussioni negative sull'attività di debug.


 * : si tratta di un'opzione introdotta con GCC 4.7. Essa consiste della somma di  con ,   e  . Questa opzione viola la rigorosa conformità agli standard e pertanto non è consigliata.

Come menzionato precedentemente  è il livello di ottimizzazione raccomandato. Se la compilazione di un pacchetto fallisce e non si stava usando, si riprovi attivando questa opzione. In alternativa, provare ad impostare le variabili CFLAGS e CXXFLAGS ad un livello di ottimizzazione più basso, come ad esempio  o addirittura   (per la segnalazione degli errori ed il controllo di possibili problemi).

-pipe
Un'opzione piuttosto comune è. Essa non ha effetti sul codice generato ma rende più rapido il processo di compilazione. Comunica al compilatore di utilizzare le pipe (trasferimento dati) al posto di file temporanei durante le varie fasi della compilazione, la qual cosa utilizzerà più memoria. Tale opzione potrebbe causare problemi su sistemi con poca memoria, perché GCC potrebbe essere terminato. In quest'ultimo caso si sconsiglia di utilizzare tale opzione.

-fomit-frame-pointer
Questa è un'opzione molto comune che ha lo scopo di ridurre le dimensioni del codice generato. Essa viene attivata a tutti i livelli di  (eccetto  ) su quelle architetture dove ciò non interferisce con il debug (per esempio x86-64), ma potrebbe essere necessario attivare. Benché il manuale di GCC non specifichi tutte le architetture, ciò si attiva usando l'opzione. È necessario esplicitare  per attivarlo su x86-32 con GCC fino alla versione 4.6, o quando si usa   su x86-32 con qualunque versione di GCC. Tuttavia, utilizzando, il debug del codice diventa molto difficile o addirittura impossibile.

In particolare, rende la risoluzione dei problemi molto più difficile per le applicazioni scritte in Java e compilate da gcj, sebbene questo non sia l'unico linguaggio influenzato. Dunque, pur potendo l'opzione essere utile, rende il debug più arduo; in particolare il backtrace (tracciamento dei passi precedenti) risulterà inutilizzabile. Se non si effettua il debug dei programmi e non vengono usate altre variabili CFLAGS relative al debug, come per esempio, allora si può tentare di usare.

-msse, -msse2, -msse3, -mmmx, -m3dnow
Queste opzioni attivano gli insiemi di istruzioni Streaming SIMD Extensions (SSE), SSE2, SSE3, MMX, e [https://it.wikipedia.org/wiki/3DNow! 3DNow!] per le architetture x86 e x86-64. Tali opzioni sono principalmente utili per la multimedialità, i giochi ed altri intensi compiti di calcolo a virgola mobile. Questi insiemi di istruzioni si trovano nelle CPU più moderne.

Normalmente nessuna di queste opzioni è necessario aggiungere al file, a patto che il sistema utilizzi l'opzione  corretta (ad esempio   implica  ). Alcune eccezioni rilevanti a questa regola sono le CPU VIA e AMD64 più recenti, le quali supportano insiemi di istruzioni non incluse con  (per esempio SSE3). Per CPU come queste, sarà necessario abilitare opzioni aggiuntive appropriate dopo aver controllato.

Ma ottengo migliori prestazioni con -funroll-loops -fomg-optimize!
Non è vero. Si pensa questo solo perché qualcuno ci ha convinto che più opzioni si utilizzano meglio è. Le opzioni aggressive danneggiano le applicazioni se usate globalmente per tutto il sistema. Anche il manuale di GCC dice che usare  e   rendono il codice più grosso e più lento. Nonostante ciò queste due opzioni, assieme a,  ,   e simili, continuano ad essere molto popolari tra coloro che si vantano delle presunte prestazioni del proprio sistema.

La verità è che si tratta di opzioni aggressive e pericolose. Si invita il lettore a controllare il forum e il bugzilla di Gentoo per vedere quali sono le conseguenze di queste opzioni. Niente di buono!

Non bisogna aggiungere queste opzioni alle CFLAGS o alle CXXFLAGS. Esse possono indurre il lettore a credere di avere un sistema ad alte prestazioni e all'avanguardia, ma la realtà è che esse danneggiano il codice e costringono gli sviluppatori a chiudere i bug come INVALID o WONTFIX.

Opzioni pericolose come queste non sono necessarie. Non si usino. Limitarsi alle opzioni di base:,   e.

Riguardo ai livelli per -O maggiori di 3?
Alcuni utenti si vantano di ottenere prestazioni maggiori usando,   e simili. In realtà i livelli per  maggiori di 3 non hanno alcun effetto. Il compilatore accetta CFLAGS come, ma in questi casi esso si limita ad applicare le ottimizzazioni del livello   e niente di più.

Per una dimostrazione si esamini il codice sorgente:

case OPT_LEVELS_3_PLUS_AND_SIZE: enabled = (level >= 3 || size); break; }}

Il lettore può osservare che i valori maggiori di 3 sono trattati allo stesso modo di.

Riguardo la compilazione esterna alla macchina di destinazione?
Alcuni lettori potrebbero chiedersi se compilare fuori dalla macchina di destinazione con una CPU o una sotto architettura GCC seriamente inferiori portino a risultati di ottimizzazione inferiori (rispetto ad una compilazione nativa). La risposta è semplicemente: No. A prescindere dall'hardware che effettivamente esegue la compilazione ed il CHOST per il quale GCC è stato compilato, finché vengono usati gli stessi argomenti (fatta eccezione per ) e la stessa versione di GCC (sebbene versioni minori potrebbero comportarsi diversamente), le ottimizzazioni risultanti sono esattamente le stesse.

Per esemplificare, se Gentoo è installato su una macchina il cui CHOST di GCC è i686-pc-linux-gnu e un server Distcc è impostato su un altro computer il cui CHOST di GCC è i486-linux-gnu, allora non c'è motivo di temere che i risultati siano meno ottimali a causa della sotto architettura categoricamente inferiore del compilatore in remoto e/o dell'hardware. Il risultato verrebbe ottimizzato tanto quanto una compilazione nativa, a condizione che le stesse opzioni siano passate a entrambi i compilatori (e il parametro  non riceva l'argomento  ). In un caso così particolare, l'architettura di destinazione deve essere specificata esplicitamente, come spiegato su Distcc and -march=native.

La sola differenza di comportamento tra due versioni GCC costruite avendo come bersaglio sotto architetture diverse consiste nell'argomento implicito predefinito per, che deriva dal CHOST del GCC quando non è esplicitamente fornito da linea di comando.

Riguardo le opzioni ridondanti?
Spesso le CFLAGS e le CXXFLAGS che vengono attivate a vari livelli di  sono specificate in modo ridondante nel file. Alcune volte lo si fa per ignoranza, ma in altri casi lo scopo è evitare il filtraggio o la sostituzione delle opzioni (flag).

Il filtraggio/sostituzione delle opzioni è usato da molti ebuild nell'albero di Portage. Solitamente viene fatto perché alcuni pacchetti falliscono la compilazione con certi livelli di, o quando il codice sorgente è troppo sensibile per l'uso di opzioni aggiuntive qualsiasi. Tali ebuild possono filtrare alcune CFLAGS e CXXFLAGS o possono sostituire  con un livello differente.

Il Manuale dello Sviluppatore di Gentoo spiega nel dettaglio in che modo funziona il filtraggio e la sostituzione delle opzioni e dove essi hanno luogo.

È possibile raggirare il filtraggio di  attraverso un elenco ridondante di opzioni per un certo livello, ad esempio , come in questo modo:

Comunque, questa non è una buona idea. Le CFLAGS sono filtrate per una ragione precisa! Quando le opzioni vengono filtrate significa che non è sicuro compilare un pacchetto con quelle. Ovviamente non è sicuro compilare l'intero sistema con  se alcune delle opzioni attivate da tale livello causano problemi con certi pacchetti. Pertanto, non si cerchi di "superare" gli sviluppatori che mantengono questi pacchetti. Occorre fidarsi degli sviluppatori. Il filtraggio e la sostituzione delle opzioni vengono fatti per assicurare la stabilità del sistema e delle applicazioni! Se una ebuild specifica opzioni (flag) alternative non bisogna provare a raggirarle.

Se si sceglie di compilare un pacchetto con opzioni inaccettabili è molto probabile che si andrà incontro a problemi. Quando l'utente segnala un problema su Bugzilla, le opzioni usate in saranno chiaramente visibili e gli sviluppatori chiederanno senz'altro di ricompilare il pacchetto senza le opzioni problematiche. Si può evitare il fastidio di dover ricompilare tali pacchetti se si evita in primo luogo l'utilizzo di opzioni ridondanti in quella maniera! Non si deve presumere di saperne di più degli sviluppatori.

In merito alle LDFLAGS?
Gli sviluppatori Gentoo hanno già scelto un insieme minimo e sicuro di LDFLAGS nei profili di base, pertanto non è necessario modificarlo.

Posso usare opzioni specifiche per singolo pacchetto?
Le informazioni su come sia possibile applicare variabili d'ambiente (compresa CFLAGS ) ai singoli pacchetti sono descritte nel manuale Gentoo ("Variabili d'ambiente per pacchetto").

Vedere anche

 * Configurazione delle opzioni di compilazione (Manuale AMD64)

Risorse esterne
Le seguenti risorse sono utili per approfondire ulteriormente il tema dell'ottimizzazione:


 * La documentazione online per GCC




 * Wikipedia


 * I forum Gentoo