[gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Marcello Magaldi]

CDO
-- 
gentoo-docs-it@gentoo.org mailing list

Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Davide Cendron]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

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/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-docs-it] Richiesta assegnazione: gcc-optimization.xml

[Riccardo Milan]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

Ciao Davide,
detto fatto, posso iniziare con gcc-optimization.xml  ?

aspetto ordini

ciao,
Riccardo

-- 
riccardo milan
16, largo. f.lli rosselli
preganziol (tv) 31022
italy

[-- Attachment #2: Type: text/html, Size: 228 bytes --]

Re: [gentoo-docs-it] Richiesta assegnazione: gcc-optimization.xml

[Davide Cendron]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

Il Friday 29 June 2007 19:34:33 Riccardo Milan ha scritto:
> Ciao Davide,
> detto fatto, posso iniziare con gcc-optimization.xml  ?
>
> aspetto ordini
>
> ciao,
> Riccardo

Ehm... l'ho già assegnato meno di un'ora fa a Marcello Magaldi! :P

Comunque sarebbe più corretto chiudere la tua traduzione di gnome-config.xml, 
prima di richiedere altri documenti :)

Ciao,

-- 
Davide Cendron

Gentoo Documentation Project
Italian Follow Up Translator

http://www.gentoo.org/doc/it/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-docs-it] Richiesta assegnazione: gcc-optimization.xml

[Riccardo Milan]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

ok, aspetto e poi riscelgo :-)

Riccardo


Il 29/06/07, Davide Cendron <scen@gentoo.org> ha scritto:
>
> Il Friday 29 June 2007 19:34:33 Riccardo Milan ha scritto:
> > Ciao Davide,
> > detto fatto, posso iniziare con gcc-optimization.xml  ?
> >
> > aspetto ordini
> >
> > ciao,
> > Riccardo
>
> Ehm... l'ho già assegnato meno di un'ora fa a Marcello Magaldi! :P
>
> Comunque sarebbe più corretto chiudere la tua traduzione di
> gnome-config.xml,
> prima di richiedere altri documenti :)
>
> Ciao,
>
> --
> Davide Cendron
>
> Gentoo Documentation Project
> Italian Follow Up Translator
>
> http://www.gentoo.org/doc/it/
>
>


-- 
riccardo milan
16, largo. f.lli rosselli
preganziol (tv) 31022
italy

[-- Attachment #2: Type: text/html, Size: 1124 bytes --]

Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Marcello Magaldi]

[-- 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&amp;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>

Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Davide Cendron]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Il Sunday 01 July 2007 16:27:59 Marcello Magaldi ha scritto:
> 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.

Il termine "ricer" vorrebbe significare quella tipologia di 
persone "fanatiche" della personalizzazione (o "tuning") del proprio mezzo da 
corsa (automobile/moto).

In Gentoo questo termine viene applicato a quella categoria di utenti che 
cercano ad ogni costo di aumentare le prestazioni del proprio pc, soprattutto 
utilizzando CFLAGS ed LDFLAGS "estreme" ed in gran quantità, che nel 99% dei 
casi fanno solamente peggio

Io lo tradurrei come "fanatico dell'ottimizzazione" o qualcosa di simile.

Comunque lo controllo appena possibile!

Ciao,

-- 
Davide Cendron

Gentoo Documentation Project
Italian Follow Up Translator

http://www.gentoo.org/doc/it/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Marcello Magaldi]

Il 01/07/07, Davide Cendron<scen@gentoo.org> ha scritto:
> Il Sunday 01 July 2007 16:27:59 Marcello Magaldi ha scritto:
> > 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.
>
> Il termine "ricer" vorrebbe significare quella tipologia di
> persone "fanatiche" della personalizzazione (o "tuning") del proprio mezzo da
> corsa (automobile/moto).

perfetto, ora che lo so lo sistemo.

>
> In Gentoo questo termine viene applicato a quella categoria di utenti che
> cercano ad ogni costo di aumentare le prestazioni del proprio pc, soprattutto
> utilizzando CFLAGS ed LDFLAGS "estreme" ed in gran quantità, che nel 99% dei
> casi fanno solamente peggio
>
> Io lo tradurrei come "fanatico dell'ottimizzazione" o qualcosa di simile.
>

ok grazie ;)

> Comunque lo controllo appena possibile!
>

perfetto

> Ciao,
>
> --
> Davide Cendron
>

Ciao

Marcello

> Gentoo Documentation Project
> Italian Follow Up Translator
>
> http://www.gentoo.org/doc/it/
>
>
--
gentoo-docs-it@gentoo.org mailing list

Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Marcello Magaldi]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

ho sistemato dietro suggerimento di Davide quelle due parole. vi
riallego il documento.

Il 01/07/07, Marcello Magaldi<magowiz@gmail.com> ha scritto:
> Il 01/07/07, Davide Cendron<scen@gentoo.org> ha scritto:
> > Il Sunday 01 July 2007 16:27:59 Marcello Magaldi ha scritto:
> > > 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.
> >
> > Il termine "ricer" vorrebbe significare quella tipologia di
> > persone "fanatiche" della personalizzazione (o "tuning") del proprio mezzo da
> > corsa (automobile/moto).
>
> perfetto, ora che lo so lo sistemo.
>
> >
> > In Gentoo questo termine viene applicato a quella categoria di utenti che
> > cercano ad ogni costo di aumentare le prestazioni del proprio pc, soprattutto
> > utilizzando CFLAGS ed LDFLAGS "estreme" ed in gran quantità, che nel 99% dei
> > casi fanno solamente peggio
> >
> > Io lo tradurrei come "fanatico dell'ottimizzazione" o qualcosa di simile.
> >
>
> ok grazie ;)
>
> > Comunque lo controllo appena possibile!
> >
>
> perfetto
>
> > Ciao,
> >
> > --
> > Davide Cendron
> >
>
> Ciao
>
> Marcello
>
> > 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: 23031 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
(o "personalizzare") 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 
fanatici della personalizzazione 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&amp;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>

Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Marcello Magaldi]

non è che ve ne siete dimenticati ? :D (scherzo!)

Il 01/07/07, Marcello Magaldi<magowiz@gmail.com> ha scritto:
> ho sistemato dietro suggerimento di Davide quelle due parole. vi
> riallego il documento.
>
> Il 01/07/07, Marcello Magaldi<magowiz@gmail.com> ha scritto:
> > Il 01/07/07, Davide Cendron<scen@gentoo.org> ha scritto:
> > > Il Sunday 01 July 2007 16:27:59 Marcello Magaldi ha scritto:
> > > > 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.
> > >
> > > Il termine "ricer" vorrebbe significare quella tipologia di
> > > persone "fanatiche" della personalizzazione (o "tuning") del proprio mezzo da
> > > corsa (automobile/moto).
> >
> > perfetto, ora che lo so lo sistemo.
> >
> > >
> > > In Gentoo questo termine viene applicato a quella categoria di utenti che
> > > cercano ad ogni costo di aumentare le prestazioni del proprio pc, soprattutto
> > > utilizzando CFLAGS ed LDFLAGS "estreme" ed in gran quantità, che nel 99% dei
> > > casi fanno solamente peggio
> > >
> > > Io lo tradurrei come "fanatico dell'ottimizzazione" o qualcosa di simile.
> > >
> >
> > ok grazie ;)
> >
> > > Comunque lo controllo appena possibile!
> > >
> >
> > perfetto
> >
> > > Ciao,
> > >
> > > --
> > > Davide Cendron
> > >
> >
> > Ciao
> >
> > Marcello
> >
> > > Gentoo Documentation Project
> > > Italian Follow Up Translator
> > >
> > > http://www.gentoo.org/doc/it/
> > >
> > >
> >
>
>
--
gentoo-docs-it@gentoo.org mailing list

Re: [gentoo-docs-it] richiesta assegnazione gcc-optimization.xml

[Davide Cendron]

[-- Attachment #1.1: Type: text/plain, Size: 543 bytes --]

Il Thursday 12 July 2007 21:19:56 Marcello Magaldi ha scritto:
> non è che ve ne siete dimenticati ? :D (scherzo!)
>

Ooooppssss... effettivamente era finita nel dimenticatoio :PPPPP (grazie per 
avermelo ricordato)

Ecco qua il documento revisionato da cima a fondo (versione 1.2, revisione 1.5 
del CVS inglese), controlla eventuali errori ortografici e altre 
imperfezioni, attendo il bug report :)

Ciao e grazie,

-- 
Davide Cendron

Gentoo Documentation Project
Italian Lead Translator

http://www.gentoo.org/doc/it/

[-- Attachment #1.2: gcc-optimization.xml --]
[-- Type: text/xml, Size: 23826 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/en/gcc-optimization.xml,v 1.4 2007/06/28 05:14:50 nightmorph Exp $ -->

<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 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.2</version>
<date>2007-07-01</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> (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>

<impo>
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 (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.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>. 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.
</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 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, dev'essere usato
<c>-mcpu</c>.
</p>

<note>
Per le impostazioni di <c>-march</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.1.2/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>, 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 dovrebbe invece
essere utilizzato <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.1.2/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>: Qesto 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 (come <c>-Os</c>, che sarà illustrato a breve). <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. 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>
    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.
  </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 <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 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 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 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.1.2/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à bisogna 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.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 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&amp;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>
Non usarle. si può aver sentito che possono velocizzare i tempi di caricamento
delle applicazioni o ridurre la dimensione dei binari, ma in realtà, le LDFLAGS
sono destinate il più delle volte a non far più funzionare le proprie
applicazioni. Non sono supportate, e i propri bug potrebbero venire marcati
INVALID se si riportano errori con pacchetti compilati con le LDFLAGS. Come
minimo bisognerà 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 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>

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]