[gentoo-commits] gentoo commit in xml/htdocs/doc/it: gcc-optimization.xml

[Davide Cendron (scen)]

scen        07/09/12 20:38:29

  Modified:             gcc-optimization.xml
  Log:
  Version 1.6, revision 1.9 of EN CVS

Revision  Changes    Path
1.4                  xml/htdocs/doc/it/gcc-optimization.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/gcc-optimization.xml?rev=1.4&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/gcc-optimization.xml?rev=1.4&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/gcc-optimization.xml?r1=1.3&r2=1.4

Index: gcc-optimization.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/it/gcc-optimization.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- gcc-optimization.xml	29 Jul 2007 22:39:10 -0000	1.3
+++ gcc-optimization.xml	12 Sep 2007 20:38:28 -0000	1.4
@@ -1,6 +1,6 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/gcc-optimization.xml,v 1.3 2007/07/29 22:39:10 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/gcc-optimization.xml,v 1.4 2007/09/12 20:38:28 scen Exp $ -->
 
 <guide link="/doc/it/gcc-optimization.xml" lang="it">
 <title>Guida all'Ottimizzazione della Compilazione</title>
@@ -22,8 +22,8 @@
 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
 <license/>
 
-<version>1.4</version>
-<date>2007-07-28</date>
+<version>1.6</version>
+<date>2007-08-12</date>
 
 <chapter>
 <title>Introduzione</title>
@@ -102,7 +102,7 @@
 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, e si arriverà ad un punto di ottenere solamente risultati peggiori.
+fallimento. C'è un punto nel quale si raggiungeranno risultati peggiori.
 </p>
 
 <p>
@@ -183,6 +183,8 @@
 Sebbene la variabile CHOST in <path>/etc/make.conf</path> specifichi
 l'architettura generale usata, dovrebbe essere usata anche <c>-march</c> in modo
 che i programmi possano essere ottimizzati per il proprio specifico processore.
+Per i processori x86 e x86-64 (fra gli altri) si dovrebbe utilizzare la flag
+<c>-march</c>.
 </p>
 
 <p>
@@ -213,28 +215,47 @@
 </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; è 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, Sparc ed Alpha, dev'essere
-usato <c>-mcpu</c>.
+Sono anche disponibili le flag <c>-mcpu</c> e <c>-mtune</c>. Queste sono
+solitamente usate solo quando non è disponibile nessuna opzione<c>-march</c>;
+certe architetture di processori possono richiedere <c>-mtune</c> o persino
+<c>-mcpu</c>. Sfortunatamente, il comportamento di <c>gcc</c> non è molto
+consistente con il modo in cui si comporta ogni flag da una architettura alla
+successiva.
+</p>
+
+<p>
+Nelle CPU x86 e x86-64, <c>-march</c> genererà codice specifico per quella CPU
+usando tutti gli insiemi di istruzioni disponibili e la corretta ABI; non avrà
+retrocompatibilità per CPU più vecchie/differenti. Se non si ha bisogno di
+eseguire codice su nessun altro sistema al di fuori di quello su cui si sta
+eseguendo Gentoo, continuare ad usare <c>-march</c>. Si potrebbe considerare
+l'utilizzo di <c>-mtune</c> solo quando si ha bisogno di generare codice per
+vecchie CPU come ad esempio i386 e i486. <c>-mtune</c> produce codice più
+generico di <c>-march</c>; sebbene ottimizzi il codice per una certa CPU, non
+tiene conto insiemi di istruzioni e ABI. Non utilizzare <c>-mtune</c> su sistemi
+x86 o x86-64, perchè è deprecato per quelle architetture.
+</p>
+
+<p>
+Solo per le CPU diverse da x86/x86-64 (come Sparc, Alpha, e PowerPC) può essere
+necessario <c>-mtune</c> o <c>-mcpu</c> invece di <c>-march</c>. Su queste
+architetture, <c>-mtune</c>/<c>-mcpu</c> si comporteranno talvolta proprio come
+<c>-march</c> (su x86/x86-64) . . . ma con un differente nome di flag. Ancora,
+il comportamento di <c>gcc</c> e la denominazione delle flag semplicemente non è
+consistente attraverso le architetture, quindi assicurarsi di controllare il
+<uri link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Submodel-Options.html#Submodel-Options">manuale</uri>
+di <c>gcc</c> per determinare quali utilizzare per il proprio sistema.
 </p>
 
 <note>
-Per le impostazioni di <c>-march</c> più suggerite, si prega leggere il capitolo
+Per le impostazioni di <c>-march</c>/<c>-mtune</c>/<c>-mcpu</c> più suggerite,
+si prega leggere il capitolo
 5 del <uri link="/doc/it/handbook/">Manuale di Installazione Gentoo</uri>
 appropriato per la propria architettura. Leggere anche la lista di <uri
 link="http://gcc.gnu.org/onlinedocs/gcc-4.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>, e <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>.
+tra <c>-march</c>, <c>-mcpu</c>, e <c>-mtune</c>.
 </note>
 
 </body>
@@ -272,8 +293,8 @@
 
 <ul>
   <li>
-    <c>-O0</c>: Qesto livello (che è contrassegnato dalla lettera "O" seguita da
-    uno zero) disattiva interamente l'ottimizzazione ed è l'opzione
+    <c>-O0</c>: Questo livello (che è contrassegnato dalla lettera "O" seguita
+    da uno zero) disattiva interamente l'ottimizzazione ed è l'opzione
     predefinita se nessun livello di <c>-O</c> è specificato nelle CFLAG o nelle
     CXXFLAGS. Il proprio codice non sarà ottimizzato; ciò non è solitamente
     desiderato
@@ -287,7 +308,7 @@
   <li>
     <c>-O2</c>: Un passo avanti da <c>-O1</c>. Questo è il livello di
     ottimizzazione <e>raccomandato</e> a meno che non si abbiano necessità
-    speciali. <c>-O2</c> attiverà poche altre flag in aggiunta a quelle attivati
+    speciali. <c>-O2</c> attiverà poche altre flag in aggiunta a quelli attivati
     da <c>-O1</c>. Con <c>-O2</c>, il compilatore tenterà di incrementare le
     prestazioni del codice senza comprometterne le dimensioni, e senza impiegare
     troppo tempo di compilazione.
@@ -310,11 +331,10 @@
   <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. Può essere utile per macchine che hanno spazio su disco
+    codice generato. E' utile per macchine che hanno spazio su disco
     estremamente limitato e/o hanno CPU con cache di piccole dimensioni.
-    Tuttavia, può causare più di qualche problema, per questo motivo viene
-    filtrata da molti degli ebuild presenti nel tree di Portage. Usare
-    <c>-Os</c> non è raccomandato.
+    Comunque, può causare alcuni problemi, il che spiega perchè è filtrato da
+    molte delle ebuild nel tree. Usare <c>-Os</c> non è raccomandato.
   </li>
 </ul>
 
@@ -323,7 +343,7 @@
 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 perfino <c>-O2 -g2 -ggdb</c> (per riportare errori e verificare
+<c>-O1</c> o persino <c>-O0 -g2 -ggdb</c> (per riportare errori e trovare
 possibili problemi) e ricompilare il pacchetto.
 </p>
 
@@ -359,11 +379,10 @@
 <p>
 In particolare, rende più difficile risolvere problemi di applicazioni scritte
 in Java, benchè Java non sia l'unico codice interessato dall'utilizzo di questa
-flag. Così mentre la flag può aiutare, può anche rendere il debug più
-difficile; i backtrace saranno totalmente inutilizzabili. Tuttavia, 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>.
+flag. Così finchè la flag può aiutare, può anche rendere il debug più difficile;
+i backtrace in particolare saranno inutili. Comunque, Se non si ha intenzione di
+fare molto debug e non si ha aggiunto nessun'altra CFLAG relativa al debug come
+<c>-ggdb</c>, allora provare a usare <c>-fomit-frame-pointer</c>.
 </p>
 
 <impo>
@@ -457,8 +476,8 @@
 </p>
 
 <p>
-Non c'è bisogno di usare queste flag globalmente in CFLAGS o CXXFLAGS, in quanto
-danneggeranno solamente la prestazioni. Ti faranno sentire come se tu avessi
+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.
@@ -520,7 +539,7 @@
 </p>
 
 <p>
-Il filtraggio/sostituzione delle flag è fatto in molti degli ebuild nel Portage
+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
@@ -556,7 +575,7 @@
 </p>
 
 <p>
-Si continuerà ad incappare in problemi quando si compila un pacchetto con flag
+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
@@ -571,13 +590,13 @@
 <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.
+Probabilmente non si dovrebbe impostarle. Si può aver sentito che possono
+velocizzare i tempi di caricamento delle applicazioni o ridurre la dimensione
+dei binari, ma possono anche far cessare di funzionare interamente le proprie
+applicazioni. Non sono ufficialmente 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>
@@ -599,16 +618,16 @@
     </uri>(ndt in inglese)
   </li>
   <li>
-    Capitolo 5 dei <uri link="/doc/it/handbook/">Manuale di Installazione
+    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>(in
-    inglese, ndt), 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
+    <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>



-- 
gentoo-commits@g.o mailing list