From: "Marcello Magaldi" <magowiz@gmail.com>
To: gentoo-docs-it@lists.gentoo.org
Subject: Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml
Date: Sun, 1 Jul 2007 16:27:59 +0200 [thread overview]
Message-ID: <9c037bdd0707010727o430f594fw27f42b3d91253c42@mail.gmail.com> (raw)
In-Reply-To: <200706291917.02887.scen@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
eccovi una prima versione, ci sono un paio di parole su cui ero
incerto e non ho tradotto , in particolare rice (che dovrebbe essere
riso ma anche pela patate , secondo dictionary.com) e il verbo
associato, rices.
Può esserci anche qualche parola che non sono riuscito a tradurre propriamente.
Comunque vi sottopongo il mio lavoro per eventuali revisioni prima di
postarlo su bugzilla.
Saluti
Marcello
Il 29/06/07, Davide Cendron<scen@gentoo.org> ha scritto:
> Il Friday 29 June 2007 17:31:07 Marcello Magaldi ha scritto:
> > CDO
>
> Ok, gcc-optimization.xml tuo, grazie!
>
> Ciao,
>
> --
> Davide Cendron
>
> Gentoo Documentation Project
> Italian Follow Up Translator
>
> http://www.gentoo.org/doc/it/
>
>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gcc-optimization.xml --]
[-- Type: text/xml; name="gcc-optimization.xml", Size: 22995 bytes --]
<?xml version='1.0' encoding='UTF-8'?>
<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/gcc-optimization.xml,v 1.4 2007/06/28 05:14:50 nightmorph Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/it/gcc-optimization.xml" lang="it">
<title>Guida all'Ottimizzazione della Compilazione</title>
<author title="Autore">
<mail link="nightmorph@gentoo.org">Joshua Saddler</mail>
</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 sicure, sane CFLAGS e CXXFLAGS. Descrive anche la teoria 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.1</version>
<date>2007-06-27</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.1.2/gcc/Invoking-GCC.html#Invoking-GCC">
manuale di GNU gcc</uri> (ndt in inglese) contiene una completa lista di 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 trovati
nel Portage tree. Invece, impostare le propre 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. Questo è ciò che si deve volere senza sbagliare.
Non si dovrebbe mai aver bisogno di specificare opzioni addizionali nelle
CXXFLAGS.
</p>
<impo>
Il Portage non può usare le CFLAGS basate su ciascun pacchetto, non vi è nessun
metodo supportato per forzarlo a far ciò. Le flag che si impostano in
<path>/etc/make.conf</path> saranno usate per <e>tutti</e> i pacchetti che si
installeranno.
</impo>
</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
(or "rice") 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 al
bene che possono farvi. Tenere in mente che la ragione percui 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 ti saranno
molto utili e porteranno 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. Menzioneremo le flag aggressive più avanti in modo da sapere da cosa
tenersi in guardia. Non discuteremo ogni opzione elencata nel manuale di
<c>gcc</c> (ce ne sono centinaia), ma copriremo le flag di base e più comuni.
</p>
<note>
Ogni volta che non si è sicuri su cosa faccia una flag, riferirsi al capitolo
appropriato del <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options">manuale di gcc
</uri>. 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>. Questo 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>
Pure la variabile CHOST in <path>/etc/make.conf</path> specifica l'architettura
generale usata, <c>-march</c> dovrebbe essere ancora usata così che i programmi
possono essere ottimizzati per il proprio specifico processore.
</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 guardiamo <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>
Qua c'è n'è un altro per un processore Sparc a 64-bit:
</p>
<pre caption="/etc/make.conf: Sparc">
CFLAGS="-march=ultrasparc"
CXXFLAGS="${CFLAGS}"
</pre>
<p>
Sono anche disponibili le flag <c>-mcpu</c> e <c>-mtune</c>. Ognuna di queste
dovrebbe essere usata <e>solo</e> quando non è disponibile nessuna opzione
<c>-march</c>.
Qual'è la differenza tra di loro? <c>-march</c> è molto più specifica circa
quali funzionalità del processore saranno usate quando si compila il codice; E'
la scelta migliore. <c>-mcpu</c> produrrà codice molto più generico meno
ottimizzato per la propria macchina. <c>-mtune</c> è perfino più generico di v<c>-mcpu</c>.
Ogni volta che sia possibile, usare <c>-march</c>. Per alcune architetture meno
comuni come PowerPC e Alpha, <c>-mcpu</c> deve essere usato.
</p>
<note>
Per le impostazioni di <c>-march</c> più suggerite, prego 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
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Submodel-Options.html#Submodel-Options">opzioni
specifiche per architettura</uri> (ndt in inglese) del manuale di<c>gcc</c>, così
come spiegazioni più dettagliate a proposito delle differenze tra <c>-march</c>,
<c>-mcpu</c>, and <c>-mtune</c>. Ciò è piuttosto d'aiuto per determinare quale
impostazione di <c>-march</c> bisognerebbe usare, specialmente per alcune
architetture, come x86, <c>-mcpu</c> è deprecato e <c>-mtune</c> dovrebbe
invece essere utilizzato.
</note>
</body>
</section>
<section>
<title>-O</title>
<body>
<p>
La prossima è la 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, così assicurarsi di leggere il capitolo del manuale di gcc
sulle <uri
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options">opzioni di
ottimizzazione</uri> (ndt in inglese) per imparare quali flag sono attivate ad
ogni livello di <c>-O</c>, così come qualche spiegazione su cosa facciano.
</p>
<p>
Esaminiamo ogni livello di ottimizzazione:
</p>
<ul>
<li>
<c>-O0</c>: Qesto livello ( che è contrassegnato dalla lettera "O" seguita
da uno zero) disattiva interamente l'ottimizzazione ed è l'opzione di
default 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ù di base. Il
compilatore proverà a produrre codice più veloce, più piccolo senza
impiegare tanto tempo di compilazione. E' piuttosto di base, ma dovrebbe
fare bene il suo lavoro tutte le volte.
</li>
<li>
<c>-O2</c>: Un passo avanti da <c>-O1</c>. Questo è il livello di
ottimizzazione <e>rccomandato</e> a meno che non si abbiano bisogni
speciali (come <c>-Os</c>, che sarà illustrato a breve). <c>-O2</c> attiverà
pochi altri flag in aggiunta a quelli attivati da <c>-O1</c>. Con <c>-O2</c>,
il compilatore tenterà di incrementare le performance 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. Ci 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> si aveva mostrato tempi di esecuzione marginalmente
più veloci rispetto a <c>-O2</c>, ma non è più il caso con <c>gcc</c> 4.x.
Compilare tutti i propri pacchetti con <c>-O3</c> <e>risulterà</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 chache di piccole dimensioni.
</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 fallback, provare a impostare i propri
CFLAGS e CXXFLAGS a un livello di ottimizzazione più basso, come <c>-O1</c> o
<c>-Os</c> 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 levelli 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 paericolare, 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.
Se non si ha intenzione di fare molto debug e non si ha aggiunto nessun'altra
CFLAG relativa al debug come <c>-ggdb</c> (e non si ha intenzione di installare
pacchetti con la USE flag <c>debug</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 performance 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> (ndt link in inglese)
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 floating point, benchè esse contengano molti altri miglioramenti
matematici. Questi insiemi di istruzioni si trovano nelle più moderne CPU.
</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 utilizzi il corretto <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.1.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options">lista</uri>
(ndt in inglese) delle flag specifiche di x86 e x86-64 per vedere quali di questi
insiemi di istruzioni sono attivate dall'appropriato flag del tipo della CPU. Se
un'istruzione è elencata, allora non si avrà bisogna di specificarla; sarà
attivata usando l'appropriata impostazione di <c>-march</c>.
</note>
</body>
</section>
</chapter>
<chapter>
<title>FAQ di Ottimizzazione</title>
<section>
<title>Ma ottengo migliori performance 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.1.2/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 frai ricers
che vogliono averne le più grandi ragioni per vantarsene.
</p>
<p>
La verità della questione è che sono flag pericolosamente aggressive. Date 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 hai bisogno di usare queste flag globalmente in CFLAGS o CXXFLAGS.
Danneggeranno solamente la performance. 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 hai bisogno di flag pericolosi come questi.<b>Non usarli</b>. Impuntati 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 performance 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>
Hai bisogno di più prove? Esamina 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 puoi 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 delle 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 ridondantemente
le flag per un certo livello, come <c>-O3</c>, facendo cose come questa:
</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 tuo intero sistema con <c>-O3</c> se qualcuna delle flag
attivate da quel livello causeranno problemi con alcuni pacchetti. Quindi, non
dovresti provare a "battere in intelligenza" gli sviluppatori che mantengono
questi pacchetti.<e>Fidati degli sviluppatori</e>. Il filtraggio delle flag e
la loro sostituzione è fatto a tuo vantaggio! Se una ebuild specifica flag
alternative, allora non provare ad aggirarle.
</p>
<p>
Continuerai ad incappare in problemi quando compili un pacchetto con flag
inaccettabili. Quando riporti i tuoi problemi su Bugzilla, le flag che usi in
<path>/etc/make.conf</path> saranno prontamente visibili e ti sarà detto di
ricompilare senza queste flag. Salvati dal problema di ricompilare non usando
flag ridondanti in primo luogo! Non assumere automaticamente che tu ne sappia
di più degli sviluppatori.
</p>
</body>
</section>
<section>
<title>Cosa mi dici delle LDFLAGS?</title>
<body>
<p>
Non usarle. Puoi aver sentito che possono velocizzare i tempi di caricamento
delle applicazioni o ridurre la dimensione dei binari, ma in realtà, le LDFLAGS
sono più destinate a non far più funzionare le tue applicazioni. Non sono
supportate, e puoi aspettarti che i tuoi bug vengano marcati INVALID se riporti
errori con pacchetti compilati con le LDFLAGS. Come minimo dovrai ricompilare
tutti i pacchetti affetti dal problema senza impostare le LDFLAGS.
</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.1.2/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 nel Portage:<c>emerge acovea</c>.
</li>
<li>I <uri link="http://forums.gentoo.org">Forum di Gentoo</uri></li>
</ul>
</body>
</section>
</chapter>
</guide>
next prev parent reply other threads:[~2007-07-01 14:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-29 15:31 [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml Marcello Magaldi
2007-06-29 17:16 ` Davide Cendron
2007-07-01 14:27 ` Marcello Magaldi [this message]
2007-07-01 15:31 ` Davide Cendron
2007-07-01 18:14 ` Marcello Magaldi
2007-07-01 18:22 ` Marcello Magaldi
2007-07-12 19:19 ` Marcello Magaldi
2007-07-16 22:41 ` Davide Cendron
-- strict thread matches above, loose matches on Subject: below --
2007-06-29 17:34 [gentoo-docs-it] Richiesta assegnazione: gcc-optimization.xml Riccardo Milan
2007-06-29 18:38 ` Davide Cendron
2007-06-29 19:24 ` Riccardo Milan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9c037bdd0707010727o430f594fw27f42b3d91253c42@mail.gmail.com \
--to=magowiz@gmail.com \
--cc=gentoo-docs-it@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox