* [gentoo-docs-it] revisione aggiornamento traduzione documento gcc-optimization.xml
@ 2009-09-03 14:28 Marcello Magaldi
2009-09-06 13:15 ` Davide Cendron
0 siblings, 1 reply; 4+ messages in thread
From: Marcello Magaldi @ 2009-09-03 14:28 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1.1: Type: text/plain, Size: 809 bytes --]
Ciao a tutti e bentornati dalle vacanze ;) ,
vi passo qui in ML il documento tradotto gcc-optimization.xml prima di
aprire il bug, l'aggiornamento è di lieve entità : un paio di piccoli
paragrafi ma tuttavia volevo un consulto.
Qui trovate le differenze tra il vecchio documento inglese di cui è già
stata pubblicata la traduzione e la nuova versione inglese :
http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/gcc-optimization.xml?r2=1.16&r1=1.15&diff_format=l
Come al solito su alcune cose non ho tradotto alla lettera ma ho cercato
tuttavia di rielaborare e rendere più comprensibile a noi italiani quanto
descritto da nightmorph nel documento originale.
Vi saluto e aspetto un vostro parere positivo o qualche eventuale correzione
prima di aprire il bug.
Saluti
Marcello
[-- Attachment #1.2: Type: text/html, Size: 984 bytes --]
[-- Attachment #2: gcc-optimization.xml --]
[-- Type: text/xml, Size: 25283 bytes --]
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/it/gcc-optimization.xml,v 1.10 2009/07/02 22:04:07 scen Exp $ -->
<guide link="/doc/it/gcc-optimization.xml" lang="it">
<title>Guida all'Ottimizzazione della Compilazione</title>
<author title="Autore">
<mail link="nightmorph"/>
</author>
<author title="Traduzione">
<mail link="magowiz@gmail.com">Marcello Magaldi</mail>
</author>
<abstract>
Questa guida fornisce un'introduzione all'ottimizzazione di codice compilato
usando CFLAGS e CXXFLAGS sane e sicure. Descrive anche la teoria che sta dietro
all'ottimizzazione in generale.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.11</version>
<date>2009-07-18</date>
<chapter>
<title>Introduzione</title>
<section>
<title>Cosa sono le CFLAGS e le CXXFLAGS?</title>
<body>
<p>
Le CFLAGS e le CXXFLAGS sono variabili d'ambiente utilizzate per dire al GNU
Compiler Collection, <c>gcc</c>, che tipo di switch usare durante la
compilazione del codice sorgente. Le CFLAGS sono per il codice scritto in C,
mentre le CXXFLAGS sono per il codice scritto in C++.
</p>
<p>
Possono essere utilizzate per diminuire il numero di messaggi di debug di un
programma, aumentare i livelli di avvisi d'errore, e, ovviamente, ottimizzare il
codice prodotto. Il <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Invoking-GCC.html#Invoking-GCC">
manuale di GNU gcc</uri> (in inglese, ndt) contiene una lista completa delle
opzioni disponibili e i loro scopi.
</p>
</body>
</section>
<section>
<title>Come sono utilizzate?</title>
<body>
<p>
Le CFLAGS e le CXXFLAGS possono essere usate in due modi. Primo, possono essere
usate per ciascun programma con i Makefile generati da automake.
</p>
<p>
Comunque, questo non dovrebbe esser fatto quando si installano pacchetti
disponibili nel Portage tree. Invece, impostare le proprie CFLAGS e CXXFLAGS in
<path>/etc/make.conf</path>. In questo modo tutti i pacchetti verranno compilati
usando le proprie opzioni specificate.
</p>
<pre caption="CFLAGS in /etc/make.conf">
CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
</pre>
<p>
Come si può notare, le CXXFLAGS sono impostate per utilizzare tutte le opzioni
presenti nelle CFLAGS. Questa è la modalità da seguire praticamente sempre per
non sbagliare. Non si dovrebbe mai aver bisogno di specificare opzioni
addizionali nelle CXXFLAGS.
</p>
</body>
</section>
<section>
<title>Idee Sbagliate</title>
<body>
<p>
Mentre le CFLAGS e le CXXFLAGS possono essere molto efficaci facendo in modo che
il codice sorgente produca binari più piccoli e/o più veloci, possono anche
alterare la funzione del proprio codice, aumentare le sue dimensioni, rallentare
il suo tempo di esecuzione, o perfino causare fallimenti nella compilazione!
</p>
<p>
Le CFLAGS non sono pallottole magiche; non faranno automaticamente girare più
veloce il proprio sistema o renderanno i propri binari più piccoli per occupare
meno spazio su disco. Aggiungere più e più flag nel tentativo di ottimizzare (o
"personalizzare" in modo estremo) il proprio sistema è una ricetta sicura per il
fallimento. C'è un punto nel quale si raggiungeranno risultati peggiori.
</p>
<p>
Contrariamente alle vanterie che si possono trovare su internet, le CFLAGS e le
CXXFLAGS aggressive sono piuttosto dannose per i propri programmi rispetto ai
vantaggi che possono introdurre. Tenere a mente che la ragione per cui esistono
le flag al primo posto è perchè sono progettate per essere usate in posti
specifici per scopi specifici. Solo perchè una particolare CFLAG è buona per un
pezzo di codice questo non significa che va bene per compilare tutto ciò che si
vorrà installare sulla propria macchina!
</p>
</body>
</section>
<section>
<title>Pronti?</title>
<body>
<p>
Ora che si è informati di alcuni dei rischi implicati, si può dare un'occhiata
a qualche sana, sicura ottimizzazione per il proprio computer. Queste saranno
molto utili e si conquisteranno le simpatie degli sviluppatori la prossima volta
che si riporterà un problema su <uri
link="http://bugs.gentoo.org">Bugzilla</uri>. (Gli sviluppatori solitamente
richiederanno di ricompilare un pacchetto con CFLAG minimali per vedere se il
problema persiste. Ricordare, flag aggressive possono rovinare il codice.)
</p>
</body>
</section>
</chapter>
<chapter>
<title>Ottimizzare</title>
<section>
<title>Le basi</title>
<body>
<p>
Lo scopo che sta dietro all'uso delle CFLAGS e delle CXXFLAGS è creare codice
adatto al proprio sistema; dovrebbe funzionare perfettamente finchè è piccolo e
veloce, se possibile. Qualche volta queste condizioni sono mutualmente
esclusive, così si proverà con combinazioni che si sa che funzionano bene.
Idealmente, ci sono le migliori disponibili per qualsiasi architettura della
CPU. Successivamente verranno menzionate le flag aggressive in modo da sapere da
cosa tenersi in guardia. Non verrà discussa ogni opzione elencata nel manuale di
<c>gcc</c> (ce ne sono centinaia), ma verranno coperte le flag di base e più
comuni.
</p>
<note>
Ogni volta che non si è sicuri su cosa faccia una flag, fare riferimento al
capitolo appropriato del <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Options">
manuale di gcc</uri>(ndt in inglese). Se si è ancora dubbiosi, provare Google,
o controllare le<uri link="http://gcc.gnu.org/lists.html">mailing list</uri> di <c>gcc</c>.
</note>
</body>
</section>
<section>
<title>-march</title>
<body>
<p>
La prima e la più importante opzione è <c>-march</c>. Essa dice al compilatore
che codice dovrà esser prodotto per la propria <uri
link="http://en.wikipedia.org/wiki/Microarchitecture">architettura</uri> di
processore (o <e>arch</e>); dice che dovrà produrre codice per un certo tipo di
CPU. Differenti CPU hanno differenti capacità, supportano differenti insiemi di
istruzioni, e hanno differenti modi di eseguire il codice. La flag <c>-march</c>
istruirà il compilatore a produrre codice specificatamente per la propria CPU,
con tutte le sue capacità, funzionalità, insiemi di istruzioni, caratteristiche,
e così via.
</p>
<p>
Sebbene la variabile CHOST in <path>/etc/make.conf</path> specifichi
l'architettura generale usata, dovrebbe essere usata anche <c>-march</c> in modo
che i programmi possano essere ottimizzati per il proprio specifico processore.
Per i processori x86 e x86-64 (fra gli altri) si dovrebbe utilizzare la flag
<c>-march</c>.
</p>
<p>
Che tipo di CPU si possiede? Per scoprirlo, eseguire il seguente comando:
</p>
<pre caption="Esaminare informazioni sulla CPU">
$ <i>cat /proc/cpuinfo</i>
</pre>
<p>
Ora si vedrà <c>-march</c> in azione. Questo esempio è per un vecchio Pentium
III:
</p>
<pre caption="/etc/make.conf: Pentium III">
CFLAGS="-march=pentium3"
CXXFLAGS="${CFLAGS}"
</pre>
<p>
Ecco un altro esempio per un processore AMD a 64-bit:
</p>
<pre caption="/etc/make.conf: AMD64">
CFLAGS="-march=athlon64"
CXXFLAGS="${CFLAGS}"
</pre>
<p>
Se si è tuttora insicuri su quale tipo di CPU si abbia, si può semplicemente
usare <c>-march=native</c>. Quando questo flag è usato, GCC rileverà il proprio
processore e imposterà automaticamente flag appropriati per questo.
<brite>Tuttavia, questo non dovrebbe essere usato se si intende compilare
pacchetti per una diversa CPU!</brite>
</p>
<p>
Quindi se si compilano pacchetti su un computer, ma si intende eseguirli su un
altro computer (come ad esempio quando si utilizza un computer veloce per
compilare per un più vecchio e più lento computer), allora <e>non</e> usare
<c>-march=native</c>. "Native" significa che il codice prodotto girerà
<e>solamente</e> su quel tipo di CPU. Le applicazioni compilate con
<c>-march=native</c> su una CPU AMD Athlon 64 non potranno essere eseguite
su una vecchia CPU VIA C3.
</p>
<p>
Sono anche disponibili le flag <c>-mcpu</c> e <c>-mtune</c>. Queste sono
solitamente usate solo quando non è disponibile nessuna opzione<c>-march</c>;
certe architetture di processori possono richiedere <c>-mtune</c> o persino
<c>-mcpu</c>. Sfortunatamente, il comportamento di <c>gcc</c> non è molto
consistente con il modo in cui si comporta ogni flag da una architettura alla
successiva.
</p>
<p>
Nelle CPU x86 e x86-64, <c>-march</c> genererà codice specifico per quella CPU
usando tutti gli insiemi di istruzioni disponibili e la corretta ABI; non avrà
retrocompatibilità per CPU più vecchie/differenti. Se non si ha bisogno di
eseguire codice su nessun altro sistema al di fuori di quello su cui si sta
eseguendo Gentoo, continuare ad usare <c>-march</c>. Si potrebbe considerare
l'utilizzo di <c>-mtune</c> solo quando si ha bisogno di generare codice per
vecchie CPU come ad esempio i386 e i486. <c>-mtune</c> produce codice più
generico di <c>-march</c>; sebbene ottimizzi il codice per una certa CPU, non
tiene conto insiemi di istruzioni e ABI. Non utilizzare <c>-mcpu</c> su sistemi
x86 o x86-64, perchè è deprecato per quelle architetture.
</p>
<p>
Solo per le CPU diverse da x86/x86-64 (come Sparc, Alpha, e PowerPC) può essere
necessario <c>-mtune</c> o <c>-mcpu</c> invece di <c>-march</c>. Su queste
architetture, <c>-mtune</c>/<c>-mcpu</c> si comporteranno talvolta proprio come
<c>-march</c> (su x86/x86-64) . . . ma con un differente nome di flag. Ancora,
il comportamento di <c>gcc</c> e la denominazione delle flag semplicemente non è
consistente attraverso le architetture, quindi assicurarsi di controllare il
<uri link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Submodel-Options.html#Submodel-Options">manuale</uri>
di <c>gcc</c> per determinare quali utilizzare per il proprio sistema.
</p>
<note>
Per le impostazioni di <c>-march</c>/<c>-mtune</c>/<c>-mcpu</c> più suggerite,
si prega leggere il capitolo
5 del <uri link="/doc/it/handbook/">Manuale di Installazione Gentoo</uri>
appropriato per la propria architettura. Leggere anche la lista di <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Submodel-Options.html#Submodel-Options">
opzioni specifiche per architettura</uri> (in inglese, ndt) del manuale di
<c>gcc</c>, così come spiegazioni più dettagliate a proposito delle differenze
tra <c>-march</c>, <c>-mcpu</c>, e <c>-mtune</c>.
</note>
</body>
</section>
<section>
<title>-O</title>
<body>
<p>
Un'altra variabile è <c>-O</c>. Questa controlla il livello generale di
ottimizzazione. Questo rende il tempo di compilazione più lungo, e può
richiedere molta più memoria, specialmente se si aumenta il livello di
ottimizzazione.
</p>
<p>
Ci sono cinque impostazioni di <c>-O</c> : <c>-O0</c>, <c>-O1</c>, <c>-O2</c>,
<c>-O3</c>, e <c>-Os</c>. Bisogna usare solo una di queste in
<path>/etc/make.conf</path>.
</p>
<p>
Con l'eccezione di <c>-O0</c>, ciascuna impostazione di <c>-O</c> attiva molte
flag addizionali, pertanto assicurarsi di leggere il capitolo del manuale di gcc
sulle <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Options">
opzioni di ottimizzazione</uri> (in inglese, ndt) per imparare quali flag sono
attivate ad ogni livello di <c>-O</c>, così come qualche spiegazione su cosa
facciano.
</p>
<p>
Verrà ora esaminato ogni livello di ottimizzazione:
</p>
<ul>
<li>
<c>-O0</c>: Questo livello (che è contrassegnato dalla lettera "O" seguita
da uno zero) disattiva interamente l'ottimizzazione ed è l'opzione
predefinita se nessun livello di <c>-O</c> è specificato nelle CFLAG o nelle
CXXFLAGS. Il proprio codice non sarà ottimizzato; ciò non è solitamente
desiderato
</li>
<li>
<c>-O1</c>: Questo è il livello di ottimizzazione più basilare. Il
compilatore proverà a produrre codice più veloce, più piccolo senza
impiegare tanto tempo di compilazione. E' piuttosto basilare, ma dovrebbe
fare bene il suo lavoro in ogni situazione.
</li>
<li>
<c>-O2</c>: Un passo avanti da <c>-O1</c>. Questo è il livello di
ottimizzazione <e>raccomandato</e> a meno che non si abbiano necessità
speciali. <c>-O2</c> attiverà poche altre flag in aggiunta a quelli attivati
da <c>-O1</c>. Con <c>-O2</c>, il compilatore tenterà di incrementare le
prestazioni del codice senza comprometterne le dimensioni, e senza impiegare
troppo tempo di compilazione.
</li>
<li>
<c>-O3</c>: Questo è il più alto livello di ottimizzazione possibile, e
anche il più rischioso. Impiegherà un tempo più lungo a compilare il
proprio codice con questa opzione, e infatti <e>non dovrebbe essere usato
per tutto il sistema con <c>gcc</c> 4.x</e>. Il comportamento di <c>gcc</c>
è cambiato significativamente dalla versione 3.x. Nella 3.x, <c>-O3</c>
aveva mostrato tempi di esecuzione marginalmente più veloci rispetto a
<c>-O2</c>, ma non è più il caso con <c>gcc</c> 4.x. Compilando tutti i
propri pacchetti con <c>-O3</c> <e>si otterranno</e> binari più grossi che
richiedono più memoria, e incrementerà significativamente il numero di
compilazioni fallite o comportamenti dei programmi inaspettati (inclusi
errori). Gli svantaggi superano i benefici; ricordare il principio di
diminuire i risultati. <b>Usare <c>-O3</c> non è raccomandato per <c>gcc</c>
4.x.</b>
</li>
<li>
<c>-Os</c>: Questo livello ottimizzerà il proprio codice per le dimensioni.
Attiva tutte le opzioni di <c>-O2</c> che non incrementano la dimensione del
codice generato. E' utile per macchine che hanno spazio su disco
estremamente limitato e/o hanno CPU con cache di piccole dimensioni.
Comunque, può causare alcuni problemi, il che spiega perchè è filtrato da
molte delle ebuild nel tree. Usare <c>-Os</c> non è raccomandato.
</li>
</ul>
<p>
Come citato precedentemente, <c>-O2</c> è il livello di ottimizzazione
raccomandato. Se le compilazioni dei pacchetti causano errori, assicurarsi di
non utilizzare <c>-O3</c>. Come opzione di riserva, provare ad impostare le
proprie CFLAGS e CXXFLAGS ad un livello di ottimizzazione più basso, come
<c>-O1</c> o persino <c>-O0 -g2 -ggdb</c> (per riportare errori e trovare
possibili problemi) e ricompilare il pacchetto.
</p>
</body>
</section>
<section>
<title>-pipe</title>
<body>
<p>
Una divertente, sicura flag da usare è <c>-pipe</c>. Questa flag attualmente non
ha effetto sul codice generato, ma rende il processo di compilazione più veloce.
Dice al compilatore di usare le pipe invece dei file temporanei durante le
differenti fasi della compilazione.
</p>
</body>
</section>
<section>
<title>-fomit-frame-pointer</title>
<body>
<p>
Questa è una flag molto comune progettata per ridurre la dimensione del codice
generato. E' attivata a tutti i livelli di <c>-O</c> (eccetto <c>-O0</c>) su
architetture dove fare così non interferisce con il debug (come su x86-64), ma
si può aver bisogno di attivarla aggiungendola alle proprie flag. Benchè il
manuale di GNU <c>gcc</c> non specifichi tutte le architetture per le quali è
attivato utilizzando <c>-O</c>, si avrà bisogno di attivarlo esplicitamente su
x86. Comunque, usare questo flag renderà il debug difficile o impossibile.
</p>
<p>
In particolare, rende più difficile risolvere problemi di applicazioni scritte
in Java, benchè Java non sia l'unico codice interessato dall'utilizzo di questa
flag. Così finchè la flag può aiutare, può anche rendere il debug più difficile;
i backtrace in particolare saranno inutili. Comunque, Se non si ha intenzione di
fare molto debug e non si ha aggiunto nessun'altra CFLAG relativa al debug come
<c>-ggdb</c>, allora provare a usare <c>-fomit-frame-pointer</c>.
</p>
<impo>
<e>Non</e> combinare <c>-fomit-frame-pointer</c> con la flag simile
<c>-momit-leaf-frame-pointer</c>. Usare quest'ultima flag è scoraggiato, siccome
<c>-fomit-frame-pointer</c> svolge già quel compito propriamente. Ancora, è
stato dimostrato che <c>-momit-leaf-frame-pointer</c> influisce negativamente
sulla prestazioni del codice.
<!--
fonte per questa informazione:
http://www.coyotegulch.com/products/acovea/aco5p4gcc40.html
-->
</impo>
</body>
</section>
<section>
<title>-msse, -msse2, -msse3, -mmmx, -m3dnow</title>
<body>
<p>
Queste flag abilitano gli insiemi d'istruzioni
<uri
link="http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions">SSE</uri>, <uri
link="http://en.wikipedia.org/wiki/SSE2">SSE2</uri>, <uri
link="http://en.wikipedia.org/wiki/SSSE3">SSE3</uri>, <uri
link="http://en.wikipedia.org/wiki/MMX">MMX</uri>, e <uri
link="http://en.wikipedia.org/wiki/3dnow">3DNow!</uri> (link in inglese, ndt)
per le architetture x86 e x86-64. Queste sono utili principalmente per
applicazioni multimediali, giochi, e altri compiti di elaborazione che fanno uso
intensivo di operazioni in virgola mobile, benchè esse contengano molti altri
miglioramenti matematici. Questi insiemi di istruzioni si trovano nelle CPU più
moderne.
</p>
<impo>
Assicurarsi di controllare se la propria CPU li supporti eseguendo
<c>cat /proc/cpuinfo</c>. L'output includerà ogni insieme di istruzioni
addizionale supportato. Notare che <b>pni</b> è solo un nome differente per
SSE3.
</impo>
<p>
Normalmente non si avrà bisogno di aggiungere ognuna di queste flag a
<path>/etc/make.conf</path> finchè si utilizzerà il valore corretto per
<c>-march</c> (per esempio, <c>-march=nocona</c> implica <c>-msse3</c>). Qualche
eccezione notabile sono le nuove CPU VIA e AMD64 che supportano istruzioni non
implicate da <c>-march</c> (come SSE3). Per CPU come queste si avrà bisogno di
abilitare flag addizionali dove appropriato dopo aver controllato l'output di
<c>cat /proc/cpuinfo</c>.
</p>
<note>
Si dovrebbe controllare la <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options">
lista</uri> (in inglese, ndt) delle flag specifiche di x86 e x86-64 per vedere
quali di questi insiemi di istruzioni sono attivate dall'appropriata flag del
tipo della CPU. Se un'istruzione è elencata, allora non si avrà bisogno di
specificarla; sarà attivata usando l'appropriata impostazione di <c>-march</c>.
</note>
</body>
</section>
</chapter>
<chapter>
<title>Domande frequenti (FAQ) Sull'Ottimizzazione</title>
<section>
<title>Ma si ottengono prestazioni migliori con -funroll-loops
-fomg-optimize!</title>
<body>
<p>
No, tu <e>pensi</e> solo di averle perchè qualcuno ti ha convinto che più flag
ci sono meglio è. Le flag aggressive faranno solo del male alle tue applicazioni
quando usate per tutto il sistema. Persino il <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Options">
manuale</uri> di <c>gcc</c>(ndt in inglese) dice che usare <c>-funroll-loops</c>
e <c>-funroll-all-loops</c> rende il codice più grande e più lento. Ancora per
qualche ragione, in associazione con <c>-ffast-math</c>, <c>-fforce-mem</c>,
<c>-fforce-addr</c>, e flag simili, continua ad essere molto popolare fra i
fanatici della personalizzazione che vogliono averne le più grandi ragioni per
vantarsene.
</p>
<p>
La verità della questione è che sono flag pericolosamente aggressive. Dare una
buona occhiata sui <uri link="http://forums.gentoo.org">Forum Gentoo</uri> e su
<uri link="http://bugs.gentoo.org">Bugzilla</uri> per vedere ciò che fanno
queste flag: niente di buono!
</p>
<p>
Non c'è bisogno di usare queste flag globalmente in CFLAGS o CXXFLAGS.
Danneggeranno solamente la prestazioni. Ti faranno sentire come se tu avessi
un sistema ad alte prestazioni che fa girare l'ultima tecnologia, ma non faranno
altro che gonfiare il tuo codice e rendere i tuoi bug marcati come INVALID o
WONTFIX.
</p>
<p>
Non c'è bisogno di flag pericolose come queste. <b>Non usarle</b>. Impuntarsi
sulle basi: <c>-march</c>, <c>-O</c>, e <c>-pipe</c>.
</p>
</body>
</section>
<section>
<title>Cosa mi dici a proposito dei livelli di -O più alti di 3?</title>
<body>
<p>
Qualche utente si vanta di prestazioni migliori ottenute usando <c>-O4</c>,
<c>-O9</c>, e così via, ma la verità è che i livelli di <c>-O</c> più alti di 3
non hanno effetti. Il compilatore può accettare CFLAGS come <c>-O4</c>, ma
attualmente non ne fa nulla. Effettua solamente le ottimizzazioni per
<c>-O3</c>, niente di più.
</p>
<p>
C'è bisogno di più prove? Esaminare il <uri
link="http://gcc.gnu.org/viewcvs/trunk/gcc/opts.c?revision=124622&view=markup">
codice sorgente</uri> di <c>gcc</c> :
</p>
<pre caption="codice sorgente di -O">
if (optimize >= 3)
{
flag_inline_functions = 1;
flag_unswitch_loops = 1;
flag_gcse_after_reload = 1;
/* Allow even more virtual operators. */
set_param_value ("max-aliased-vops", 1000);
set_param_value ("avg-aliased-vops", 3);
}
</pre>
<p>
Come si può vedere, ogni valore più alto di 3 è trattato esattamente come
<c>-O3</c>.
</p>
</body>
</section>
<section>
<title>Cosa mi dici delle flag ridondanti?</title>
<body>
<p>
Spesso le CFLAGS e le CXXFLAGS che sono attivate a vari livelli di <c>-O</c>
sono specificatamente ridondanti in <path>/etc/make.conf</path>. Qualche volta
ciò è fatto per ignoranza, ma è anche fatto per evitare il filtraggio o la
sostituzione delle flag.
</p>
<p>
Il filtraggio/sostituzione delle flag è fatto in molte degli ebuild nel Portage
tree. E' fatto solitamente perchè i pacchetti falliscono la compilazione a certi
livelli di <c>-O</c>, o quando il codice sorgente è troppo sensibile per ogni
flag addizionale da usare. L'ebuild filtrerà qualcuna o tutte le CFLAGS e le
CXXFLAGS, o può sostituire <c>-O</c> con un livello differente.
</p>
<p>
Il<uri
link="http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html">
Manuale degli Sviluppatori di Gentoo</uri> (ndt in inglese) descrive dove e
come funziona il filtraggio/sostituzione di flag.
</p>
<p>
E' possibile aggirare il filtraggio di <c>-O</c> elencando in modo ridondante le
flag per un certo livello, come <c>-O3</c>, in in modo simile a questo:
</p>
<pre caption="Specificare CFLAGS ridondanti">
CFLAGS="-O3 -finline-functions -funswitch-loops"
</pre>
<p>
Comunque, <brite>questa non è una cosa intelligente da fare</brite>. Le CFLAGS
sono filtrate per una ragione! Quando le flag sono filtrate, significa che non è
sicuro compilare un pacchetto con queste flag. Chiaramente, <e>non</e> è sicuro
compilare il proprio intero sistema con <c>-O3</c> se qualcuna delle flag
attivate da quel livello causeranno problemi con alcuni pacchetti. Quindi, non
provare a "battere in intelligenza" gli sviluppatori che mantengono questi
pacchetti. <e>Bisogna fidarsi degli sviluppatori</e>. Il filtraggio delle flag e
la loro sostituzione è fatto a vantaggio degli utenti! Se un ebuild specifica
flag alternative, allora non provare ad aggirarle.
</p>
<p>
Si Continuerà ad incappare in problemi quando si compila un pacchetto con flag
inaccettabili. Quando si riportano i propri problemi su Bugzilla, le flag usate
in <path>/etc/make.conf</path> saranno prontamente visibili e verrà detto di
ricompilare senza queste flag. Si può evitare il problema di ricompilare non
usando flag ridondanti in primo luogo! Non assumere automaticamente di saperne
di più degli sviluppatori.
</p>
</body>
</section>
<section>
<title>Cosa mi dici delle LDFLAGS?</title>
<body>
<p>
Gli sviluppatori Gentoo hanno già impostato delle LDFLAGS elementari e sicure
nei profili basilari, pertanto non è necessario cambiarle.
</p>
</body>
</section>
<section>
<title>Posso usare le flag per pacchetto?</title>
<body>
<p>
Non ci sono metodi supportati per usare le CFLAGS o altre variabili su una base
per pacchetto, sebbene ci siano alcuni modi <uri
link="http://forums.gentoo.org/viewtopic-p-3832057.html#3832057">piuttosto
perversi</uri> per forzare Portage a farlo.
</p>
<p>
È consigliabile <e>non provare</e> a forzare Portage ad usare flag per
pacchetto, in quanto questa modalità non è supportata in alcun modo e
complicherà enormemente i bug report. Impostare solamente le proprie flag in
<path>/etc/make.conf</path> per usarle globalmente.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Risorse</title>
<section>
<body>
<p>
Le seguenti risorse sono d'aiuto per capire ulteriormente l'ottimizzazione:
</p>
<ul>
<li>
Il <uri link="http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/">manuale GNU gcc
</uri>(ndt in inglese)
</li>
<li>
Capitolo 5 dei <uri link="/doc/it/handbook/">Manuali di Installazione
Gentoo</uri>
</li>
<li><c>man make.conf</c></li>
<li><uri link="http://it.wikipedia.org">Wikipedia</uri></li>
<li>
<uri link="http://www.coyotegulch.com/products/acovea/">Acovea</uri>(ndt in
inglese), una suite di benchmark e test che può essere utile per determinare
come differenti flag del compilatore interagiscono e interessano la
generazione del codice, benchè i suoi suggerimenti sul codice non sono
appropriati per l'uso sull'intero sistema. E' disponibile in Portage:
<c>emerge acovea</c>.
</li>
<li>I <uri link="http://forums.gentoo.org">Forum di Gentoo</uri></li>
</ul>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-docs-it] revisione aggiornamento traduzione documento gcc-optimization.xml
2009-09-03 14:28 [gentoo-docs-it] revisione aggiornamento traduzione documento gcc-optimization.xml Marcello Magaldi
@ 2009-09-06 13:15 ` Davide Cendron
2009-09-06 15:22 ` Marcello Magaldi
0 siblings, 1 reply; 4+ messages in thread
From: Davide Cendron @ 2009-09-06 13:15 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1: Type: Text/Plain, Size: 2098 bytes --]
In data giovedì 03 settembre 2009 16:28:46, Marcello Magaldi ha scritto:
: > Ciao a tutti e bentornati dalle vacanze ;) ,
> vi passo qui in ML il documento tradotto gcc-optimization.xml prima di
> aprire il bug, l'aggiornamento è di lieve entità : un paio di piccoli
> paragrafi ma tuttavia volevo un consulto.
> Qui trovate le differenze tra il vecchio documento inglese di cui è già
> stata pubblicata la traduzione e la nuova versione inglese :
> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/gcc-optimizat
> ion.xml?r2=1.16&r1=1.15&diff_format=l
>
> Come al solito su alcune cose non ho tradotto alla lettera ma ho cercato
> tuttavia di rielaborare e rendere più comprensibile a noi italiani quanto
> descritto da nightmorph nel documento originale.
>
> Vi saluto e aspetto un vostro parere positivo o qualche eventuale
> correzione prima di aprire il bug.
>
> Saluti
>
> Marcello
>
Ciao Marcello!
La nuova parte io la tradurrei così:
<p>
Se non si è ancora sicuri sul tipo di CPU in proprio possesso, basta usare
<c>-march=native</c>. Quando questa flag è usata, GCC rileverà il proprio
processore e imposterà automaticamente le relative flag appropriate per esso.
<brite>Tuttavia, questa opzione non dovrebbe essere usata se si intende
compilare pacchetti per una CPU diversa!</brite>
</p>
<p>
Quindi se si compilano pacchetti su un computer, ma si intende eseguirli su
una
macchina differente (per esempio quando si utilizza un computer veloce per
compilare pacchetti per un altro più vecchio e lento), allora <e>non</e> usare
<c>-march=native</c>. "Native" significa che il codice prodotto girerà
<e>solamente</e> su quel tipo di CPU. Le applicazioni compilate con
<c>-march=native</c> su una CPU AMD Athlon 64 non potranno essere eseguite
su una vecchia CPU VIA C3.
</p>
(ho reso la traduzione un po' più scorrevole, dal mio punto di vista).
My 2 cents ;-)
--
Davide Cendron
Gentoo Documentation Project
Italian Lead Translator
http://www.gentoo.org/doc/it/
http://dev.gentoo.org/~scen/trads-it.xml
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-docs-it] revisione aggiornamento traduzione documento gcc-optimization.xml
2009-09-06 13:15 ` Davide Cendron
@ 2009-09-06 15:22 ` Marcello Magaldi
2009-09-06 21:14 ` Davide Cendron
0 siblings, 1 reply; 4+ messages in thread
From: Marcello Magaldi @ 2009-09-06 15:22 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1: Type: text/plain, Size: 3265 bytes --]
Ciao ho letto la tua traduzione e l'ho confrontata con la mia, ho sistemato
la mia con i tuoi suggerimenti tranne la frase :
"Quando questa flag è usata, GCC rileverà il proprio
processore e imposterà automaticamente le relative flag appropriate per
esso."
che mi sembrava troppo lunga e contorta, ho messo :
"Quando questa flag è usata, GCC rileverà il proprio processore e imposterà
automaticamente le flag appropriate."
che secondo me rende lo stesso senso dato che "appropriate" è già relativo
al processore e mettere "per esso" secondo me è una sorta di ripetizione
e anche "relative" mi sembrava superfluo dato che stiamo parlando di opzioni
di compilazione e più precisamente delle opzioni dell'architettura del
proprio processore e quindi penso che sia implicito nel discorso che le flag
siano relative alla cpu.
Che ne pensi, Davide (ma anche gli altri in ascolto)?
Ciao,
Marcello
Il giorno 06 settembre 2009 15.15, Davide Cendron <scen@gentoo.org> ha
scritto:
> In data giovedì 03 settembre 2009 16:28:46, Marcello Magaldi ha scritto:
> : > Ciao a tutti e bentornati dalle vacanze ;) ,
> > vi passo qui in ML il documento tradotto gcc-optimization.xml prima di
> > aprire il bug, l'aggiornamento è di lieve entità : un paio di piccoli
> > paragrafi ma tuttavia volevo un consulto.
> > Qui trovate le differenze tra il vecchio documento inglese di cui è già
> > stata pubblicata la traduzione e la nuova versione inglese :
> >
> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/gcc-optimizat
> > ion.xml?r2=1.16&r1=1.15&diff_format=l
> >
> > Come al solito su alcune cose non ho tradotto alla lettera ma ho cercato
> > tuttavia di rielaborare e rendere più comprensibile a noi italiani quanto
> > descritto da nightmorph nel documento originale.
> >
> > Vi saluto e aspetto un vostro parere positivo o qualche eventuale
> > correzione prima di aprire il bug.
> >
> > Saluti
> >
> > Marcello
> >
>
> Ciao Marcello!
>
> La nuova parte io la tradurrei così:
>
> <p>
> Se non si è ancora sicuri sul tipo di CPU in proprio possesso, basta usare
> <c>-march=native</c>. Quando questa flag è usata, GCC rileverà il proprio
> processore e imposterà automaticamente le relative flag appropriate per
> esso.
> <brite>Tuttavia, questa opzione non dovrebbe essere usata se si intende
> compilare pacchetti per una CPU diversa!</brite>
> </p>
>
> <p>
> Quindi se si compilano pacchetti su un computer, ma si intende eseguirli su
> una
> macchina differente (per esempio quando si utilizza un computer veloce per
> compilare pacchetti per un altro più vecchio e lento), allora <e>non</e>
> usare
> <c>-march=native</c>. "Native" significa che il codice prodotto girerà
> <e>solamente</e> su quel tipo di CPU. Le applicazioni compilate con
> <c>-march=native</c> su una CPU AMD Athlon 64 non potranno essere eseguite
> su una vecchia CPU VIA C3.
> </p>
>
> (ho reso la traduzione un po' più scorrevole, dal mio punto di vista).
>
> My 2 cents ;-)
>
> --
> Davide Cendron
>
> Gentoo Documentation Project
> Italian Lead Translator
>
> http://www.gentoo.org/doc/it/
> http://dev.gentoo.org/~scen/trads-it.xml<http://dev.gentoo.org/%7Escen/trads-it.xml>
>
[-- Attachment #2: Type: text/html, Size: 4172 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-docs-it] revisione aggiornamento traduzione documento gcc-optimization.xml
2009-09-06 15:22 ` Marcello Magaldi
@ 2009-09-06 21:14 ` Davide Cendron
0 siblings, 0 replies; 4+ messages in thread
From: Davide Cendron @ 2009-09-06 21:14 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1: Type: Text/Plain, Size: 1286 bytes --]
In data domenica 06 settembre 2009 17:22:34, Marcello Magaldi ha scritto:
: > Ciao ho letto la tua traduzione e l'ho confrontata con la mia, ho
sistemato
> la mia con i tuoi suggerimenti tranne la frase :
> "Quando questa flag è usata, GCC rileverà il proprio
> processore e imposterà automaticamente le relative flag appropriate per
> esso."
>
> che mi sembrava troppo lunga e contorta, ho messo :
> "Quando questa flag è usata, GCC rileverà il proprio processore e imposterà
> automaticamente le flag appropriate."
>
> che secondo me rende lo stesso senso dato che "appropriate" è già relativo
> al processore e mettere "per esso" secondo me è una sorta di ripetizione
> e anche "relative" mi sembrava superfluo dato che stiamo parlando di
> opzioni di compilazione e più precisamente delle opzioni dell'architettura
> del proprio processore e quindi penso che sia implicito nel discorso che
> le flag siano relative alla cpu.
>
>
> Che ne pensi, Davide (ma anche gli altri in ascolto)?
>
>
Concordo al 100%!
Come sempre, la revisione "multipla" è degli strumenti più efficaci :-)
Ciao,
--
Davide Cendron
Gentoo Documentation Project
Italian Lead Translator
http://www.gentoo.org/doc/it/
http://dev.gentoo.org/~scen/trads-it.xml
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-09-06 21:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-03 14:28 [gentoo-docs-it] revisione aggiornamento traduzione documento gcc-optimization.xml Marcello Magaldi
2009-09-06 13:15 ` Davide Cendron
2009-09-06 15:22 ` Marcello Magaldi
2009-09-06 21:14 ` Davide Cendron
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox