| View previous topic :: View next topic |
| Author |
Message |
xveilsidex
Guru
Joined: 27 Dec 2005
Posts: 370
Location: Bari
|
 Posted: Sun Jan 13, 2008 1:08 pm Post subject: |
 |
|
| flameyes quali cflag e ldflag, quindi mi consigli ? |
|
| Back to top |
|
 |
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Sun Jan 13, 2008 2:55 pm Post subject: |
|
|
| xveilsidex wrote: | | Non sono pienamente d'accordo nel mettere prescott sul centrino-duo o core-duo xkè i prescott utilizzavano un architettura piu' vekkia (netburst) rispetto a quella core. |
Non c'entra. Controlla anche su http://gentoo-wiki.com/Safe_Cflags#Intel_Core_Solo.2FDuo e apri il link segnalato nelle note; -march=prescott rende ridondante -msse3, differentemente da -march=pentium-m. La questione di gcc-4.2 è una mia confusione, non contarla.
| Flameeyes wrote: | | -fforce-address può creare problemi con certe applicazioni specie se mangiano registri a colazione pranzo e cena (FFmpeg, Mplayer, xine). |
Confermo per ffmpeg, ho impostato l'eccezione dentro a /etc/portage/env/, mplayer e xine compilano normalmente.
| Flameeyes wrote: | | Per quanto riguarda -mfpmath=sse... ormai _dovrebbe_ essere stabile, ma ha il problema di cambiare il formato delle variabili in virgola mobile. Certo software (ma sinceramente non ho un esempio sotto mano) non gradisce questo perché assume che x86 == math i387. Usare a proprio rischio e pericolo. |
Non ho ancora incontrato problemi con questa opzione; comunque, come dicevo prima, dovrebbe essere molto utile con i core dothan e sonoma, che usano -march=pentium-m ma non hanno il baco dei banias (in questi core il codice sse lavora molto lento). Qui su uno yonah entriamo nel "non chiaro" che circonda buona parte delle opzioni di gcc  |
|
| Back to top |
|
|
xveilsidex
Guru
Joined: 27 Dec 2005
Posts: 370
Location: Bari
|
| Posted: Sun Jan 13, 2008 3:15 pm Post subject: |
|
|
@riverdragon, grazie x la dritta non l'avevo notata quella nota!  quindi dovrei togliere pentium-m e mettere prescott giusto?
| riverdragon wrote: | | Non ho ancora incontrato problemi con questa opzione; comunque, come dicevo prima, dovrebbe essere molto utile con i core dothan e sonoma, che usano -march=pentium-m ma non hanno il baco dei banias (in questi core il codice sse lavora molto lento). Qui su uno yonah entriamo nel "non chiaro" che circonda buona parte delle opzioni di gcc |
cmq penso che per il yonoh entriamo nel "non chiaro" xkè è una "versione di transazione" tra il prescott e i core 2 duo! cmq è veramente un po inkasino utilizzare le flags corrette specialmente x queste versioni di procio. quali ldflags hai impostato? |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Sun Jan 13, 2008 5:23 pm Post subject: |
|
|
Qui nel make.conf io ho | Code: |
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer -fforce-addr -mfpmath=sse"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -s -Wl,--as-needed" |
|
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Mon Jan 14, 2008 10:51 am Post subject: |
|
|
| Flameeyes wrote: | | djinnZ, le LDFLAGS sono flag per il linker. GCC non fa nulla al linker se non invocarlo, quindi no, non centra assolutamente nulla col codice interno di GCC. |
Allora perchè cc1 (mi sbagliavo sul nome dell'eseguibile, scusa la solita distrazione) compilato senza -Wl,-O1 funziona mentre con va soggetto a continui crash e di quando in quando (sempre in maniera irripetibile) riporta un errore di stack smashing protection?
Non mi riferisco ad errori nel compilare ma ad un errore interno al compilatore (e con le vecchie binutils 2.16 mi sono ritrovato un paio di volte a doverlo ricostruire in binario su un altro computer, perchè non funzionava più del tutto).
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est 
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
Flameeyes
Retired Dev
Joined: 30 Mar 2005
Posts: 189
Location: London, Europe
|
| Posted: Mon Jan 14, 2008 12:07 pm Post subject: |
|
|
Probabilmente un difetto del linker che stai usando con il codice che proviene da gcc, o il codice di gcc che è rotto e il tuo linker lo mostra. Non può essere solo gcc però, il linker si occupa di -Wl,-O1 quindi è quello che può far casini.
_________________
You want to know what I'm working on right now? Just follow my blog. |
|
| Back to top |
|
|
Manwhe
Tux's lil' helper
Joined: 25 Jun 2007
Posts: 127
|
| Posted: Tue Jan 15, 2008 10:12 am Post subject: |
|
|
Ciao a tutti.
Ho un Intel Core 2 Duo T5500
CHOST="i686-pc-linux-gnu" ,ACCEPT_KEYWORDS="x86"
GCC 4.1.2
ho trovato questo link http://gentoo-install.com/install.
Viene consigliato di usare come CFLAGS
i686 = Intel Core Solo/Duo 2 (Allendale, Conroe, Merom) -march=prescott -msse3 -mfpmath=sse -O2 -fomit-frame-pointer -pipe
e come LDFLAGS
"-Wl,-O1 -Wl,--as-needed"
Nella vostra immensa esperienza, sono impostazioni affidabili? o rischio di ritrovarmi pacchetti che non si compilano? |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Tue Jan 15, 2008 11:36 am Post subject: |
|
|
| Manwhe wrote: | | -mfpmath=sse |
c'è un thread aperto da cazzantonio sui problemi di precisione numerica che comporta questa flag per il resto il problema è se consente di incrementare le prestazioni o meno ma non ho trovato alcunchè di affidabile per dire su quale cpu e bene e su quale è male.
| Manwhe wrote: | | "-Wl,-O1 -Wl,--as-needed" |
A parte i problemi che ho riscontrato con -O1 e che credo siano dovuti alla versione del gcc (ed ai suoi bachi interni) e di binutils più vecchie e pesantemente patchate rispetto alla gentoo normale (e dimenticavo di dire che i miei problemi sono aumentati da quando ho cambiato da -march=athlon a athlon-xp), quindi molto specifici, alcuni pacchetti non vogliono saperne di funzionare con queste flag e devi compilarli senza (bashrcng è molto utile).
Poi ci sono gli autotools (in senso lato) bastardi come quello di mplayer ma anche quelli non sono problemi irrisolvibili.
Io per eccesso di prudenza ho deciso di disabilitarle entrambe sul compilatore le binutils e librerie base (libc, stl etc.) anche perchè non mi hanno dato un grande incremento di prestazioni (per kde invece la differenza c'è e non richiede alcuno strumento per notarla).
La cosa molto positiva di --as-need è che comporta problemi di compilazione o di linking a runtime nell'avvio ma non rende il codice assolutamente instabile (come le -O999 -fwtf-omg), quindi il programma o non funziona o non viene compilato, non mi è mai capitato che desse i numeri.
Per me ne vale la pena, quelle due o tre bestemmie ogni volta che aggiorni sono ripagate dalla maggiore velocità di avvio delle applicazioni.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
xveilsidex
Guru
Joined: 27 Dec 2005
Posts: 370
Location: Bari
|
| Posted: Tue Jan 15, 2008 12:39 pm Post subject: |
|
|
| Manwhe wrote: | Ciao a tutti.
Ho un Intel Core 2 Duo T5500
CHOST="i686-pc-linux-gnu" ,ACCEPT_KEYWORDS="x86"
GCC 4.1.2
ho trovato questo link http://gentoo-install.com/install.
Viene consigliato di usare come CFLAGS
i686 = Intel Core Solo/Duo 2 (Allendale, Conroe, Merom) -march=prescott -msse3 -mfpmath=sse -O2 -fomit-frame-pointer -pipe
e come LDFLAGS
"-Wl,-O1 -Wl,--as-needed"
Nella vostra immensa esperienza, sono impostazioni affidabili? o rischio di ritrovarmi pacchetti che non si compilano? |
Dicono che con -march=prescott la flag msse3 è ridondante! |
|
| Back to top |
|
|
ashlar
Tux's lil' helper
Joined: 14 Jun 2006
Posts: 140
|
| Posted: Tue Jan 15, 2008 6:25 pm Post subject: |
|
|
anche io avevo una mattinata da perdere e allora mi sono detto proviamo
a fare un bell', con le seguenti | Quote: | | LDFLAGS="-Wl,-O1 -Wl,--sort-common -s -Wl,--as-needed" |
. Sonoriuscito a ricompilare tutto eccetto binutils che da il seguente messaggio...
| Code: | * ERROR: sys-devel/binutils-2.18 failed.
* Call stack:
* ebuild.sh, line 46: Called src_compile
* environment, line 2690: Called toolchain-binutils_src_compile
* environment, line 3232: Called die
* The specific snippet of code:
* make info || diefunc "$FUNCNAME" "$LINENO" "$?" "make info failed";
* The die message:
* make info failed
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/sys-devel/binutils-2.18/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-devel/binutils-2.18/temp/environment'.
* This ebuild used the following eclasses from overlays:
* /usr/portage/eclass/toolchain-binutils.eclass
* /usr/portage/eclass/eutils.eclass
* /usr/portage/eclass/multilib.eclass
* /usr/portage/eclass/toolchain-funcs.eclass
* /usr/portage/eclass/portability.eclass
* /usr/portage/eclass/libtool.eclass
* /usr/portage/eclass/flag-o-matic.eclass
* /usr/portage/eclass/gnuconfig.eclass |
Avete idea di cosa posso fare per risolvere? |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Tue Jan 15, 2008 6:59 pm Post subject: |
|
|
| ashlar wrote: | | -Wl,--sort-common -s |
mi sa che è questo (per un problema di passaggio parametri) forse sarebbe utile postare l'errore (qualched riga più sopra).
Io continuo a dire che è meglio evitare di rischiare col compilatore libc etc. tanto non ho riscontrato questo grande incremento di prestazioni a suo tempo (al contrario di qt e kde che ne hanno praticamente bisogno).
Per cominciare prova a mettere l'opzione per ultima e bada bene che --sort-common è ancora sconsigliata se non ricordo male.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
Flameeyes
Retired Dev
Joined: 30 Mar 2005
Posts: 189
Location: London, Europe
|
| Posted: Tue Jan 15, 2008 8:32 pm Post subject: |
|
|
NON usate -s.
Portage si occupa dello striping degli eseguibili, e sa quando può farlo e quando no. Usare -s indistintamente può causare gravi problemi.
_________________
You want to know what I'm working on right now? Just follow my blog. |
|
| Back to top |
|
|
ashlar
Tux's lil' helper
Joined: 14 Jun 2006
Posts: 140
|
| Posted: Tue Jan 15, 2008 10:06 pm Post subject: |
|
|
| Quote: | | LDFLAGS="-Wl,-O1 -Wl,--as-needed" |
Come suggeritomi ho messo le ldflags sopra, ancora non riesco a compilare binutils mi danno il seguente errore :
| Code: |
Doing info in libiberty
make[2]: Entering directory `/var/tmp/portage/sys-devel/binutils-2.18/work/build/libiberty'
/var/tmp/portage/sys-devel/binutils-2.18/work/binutils-2.18/missing makeinfo --split-size=5000000 --split-size=5000000 -I/var/tmp/portage/sys-devel/binutils-2.18/work/binutils-2.18/libiberty /var/tmp/portage/sys-devel/binutils-2.18/work/binutils-2.18/libiberty/libiberty.texi
WARNING: `makeinfo' is missing on your system. You should only need it if
you modified a `.texi' or `.texinfo' file, or any other file
indirectly affecting the aspect of the manual. The spurious
call might also be the consequence of using a buggy `make' (AIX,
DU, IRIX). You might want to install the `Texinfo' package or
the `GNU make' package. Grab either from any GNU archive site.
make[2]: *** [libiberty.info] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/binutils-2.18/work/build/libiberty'
make[1]: *** [info-libiberty] Error 1
make[1]: Leaving directory `/var/tmp/portage/sys-devel/binutils-2.18/work/build'
make: *** [do-info] Error 2
*
* ERROR: sys-devel/binutils-2.18 failed.
|
Ho risolto downgradando a sys-apps/texinfo-4.8-r5 non chiedetemi perchè però |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Wed Jan 16, 2008 8:20 pm Post subject: |
|
|
| riverdragon wrote: | | Con il Core Duo se lavori a 32 bit [...] da quando avrai gcc-4.2 installato aggiungere -mtune=generic. |
Mi è venuto lo scrupolo di controllare, e avevo ragione: | http://gcc.gnu.org/gcc-4.2/changes.html wrote: | # -mtune=generic can now be used to generate code running well on common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel Core 2.
# -mtune=native and -march=native will produce code optimized for the host architecture as detected using the cpuid instruction. |
|
|
| Back to top |
|
|
xveilsidex
Guru
Joined: 27 Dec 2005
Posts: 370
Location: Bari
|
| Posted: Thu Jan 17, 2008 10:30 am Post subject: |
|
|
| riverdragon wrote: | | riverdragon wrote: | | Con il Core Duo se lavori a 32 bit [...] da quando avrai gcc-4.2 installato aggiungere -mtune=generic. |
Mi è venuto lo scrupolo di controllare, e avevo ragione: | http://gcc.gnu.org/gcc-4.2/changes.html wrote: | # -mtune=generic can now be used to generate code running well on common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel Core 2.
# -mtune=native and -march=native will produce code optimized for the host architecture as detected using the cpuid instruction. |
|
@riverdragon xkè non l'hai utilizzato sulla tua macchina " -mtune=generic ", hai gcc piu vekkie? cmq leggevo ke -mtune=generic è per utilizzare i baniri su altre macchine, se si utilizza i binari solo per la propria macchina conviene utilizzare -mtune=native per una migliore ottimizzazione.
| riverdragon wrote: |
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer -fforce-addr -mfpmath=sse"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -s -Wl,--as-needed" |
| Flameeyes wrote: |
NON usate -s.
Portage si occupa dello striping degli eseguibili, e sa quando può farlo e quando no. Usare -s indistintamente può causare gravi problemi. |
@Flameyes conviene usare sort common in questo modo : ?
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed" |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Thu Jan 17, 2008 10:59 am Post subject: |
|
|
| xveilsidex wrote: | | @riverdragon xkè non l'hai utilizzato sulla tua macchina " -mtune=generic ", hai gcc piu vekkie? cmq leggevo ke -mtune=generic è per utilizzare i baniri su altre macchine, se si utilizza i binari solo per la propria macchina conviene utilizzare -mtune=native per una migliore ottimizzazione. |
Non uso -mtune=generic perché in gcc 4.1.2 non è contemplata (ho anche spulciato il manuale, -mtune esiste ma non è possibile passargli né generic né native).
Non so dove hai letto quello che dici, ma l'estratto che ho riportato precedentemente è tratto dal sito della GNU (http://gcc.gnu.org/gcc-4.2/changes.html), e se uno sviluppatore intel dice che l'opzione corretta è -mtune=generic sono propenso a dargli fiducia. |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Thu Jan 17, 2008 11:01 am Post subject: |
|
|
https://forums.gentoo.org/viewtopic-t-83375.html
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Thu Jan 17, 2008 12:56 pm Post subject: |
|
|
| Non si capisce quale sia il problema, né chi abbia trasgredito le linee guida. |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Thu Jan 17, 2008 1:12 pm Post subject: |
|
|
 ho saltato il "@xveilsidex", scusa ma non mi ero accorto che avevi risposto nel frattempo.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
ashlar
Tux's lil' helper
Joined: 14 Jun 2006
Posts: 140
|
| Posted: Thu Jan 17, 2008 2:39 pm Post subject: |
|
|
vi aggiorno sull'andamento della ricompilazione totale...
è andato tutto al primo (o quasi) colpo eccetto il pacchetto amanith (necessario per FretsonFire) che mi da un errore alquanto strano...provo a segnalarvelo:
| Code: |
../src/support/glew.c:7027: error: assignment of read-only location
../src/support/glew.c:7030: error: assignment of read-only location
../src/support/glew.c:7031: error: assignment of read-only location
../src/support/glew.c:7034: error: assignment of read-only location
../src/support/glew.c:7035: error: assignment of read-only location
../src/support/glew.c:7038: error: assignment of read-only location
../src/support/glew.c:7039: error: assignment of read-only location
make[1]: *** [glew.o] Error 1
make[1]: *** Waiting for unfinished jobs....
../include/amanith/geometry/gmatrix.h: In member function ‘const DATA_TYPE** Amanith::GMatrix<DATA_TYPE, ROWS, COLS>::Data() const [with DATA_TYPE = double, unsigned int ROWS = 2u, unsigned int COLS = 2u]’:
../include/amanith/geometry/gmatrix.h:167: instantiated from ‘Amanith::GMatrix<DATA_TYPE, ROWS, COLS>::GMatrix(const Amanith::GMatrix<DATA_TYPE, ROWS, COLS>&) [with DATA_TYPE = double, unsigned int ROWS = 2u, unsigned int COLS = 2u]’
../include/amanith/geometry/gmatrix.h:2414: instantiated from here
../include/amanith/geometry/gmatrix.h:326: warning: dereferencing type-punned pointer will break strict-aliasing rules
../include/amanith/geometry/gmatrix.h: In member function ‘const DATA_TYPE** Amanith::GMatrix<DATA_TYPE, ROWS, COLS>::Data() const [with DATA_TYPE = double, unsigned int ROWS = 3u, unsigned int COLS = 3u]’:
../include/amanith/geometry/gmatrix.h:167: instantiated from ‘Amanith::GMatrix<DATA_TYPE, ROWS, COLS>::GMatrix(const Amanith::GMatrix<DATA_TYPE, ROWS, COLS>&) [with DATA_TYPE = double, unsigned int ROWS = 3u, unsigned int COLS = 3u]’
../include/amanith/geometry/gmatrix.h:2416: instantiated from here
../include/amanith/geometry/gmatrix.h:326: warning: dereferencing type-punned pointer will break strict-aliasing rules
../include/amanith/geometry/gmatrix.h: In member function ‘const DATA_TYPE** Amanith::GMatrix<DATA_TYPE, ROWS, COLS>::Data() const [with DATA_TYPE = double, unsigned int ROWS = 4u, unsigned int COLS = 4u]’:
../include/amanith/geometry/gmatrix.h:167: instantiated from ‘Amanith::GMatrix<DATA_TYPE, ROWS, COLS>::GMatrix(const Amanith::GMatrix<DATA_TYPE, ROWS, COLS>&) [with DATA_TYPE = double, unsigned int ROWS = 4u, unsigned int COLS = 4u]’
../include/amanith/geometry/gmatrix.h:2418: instantiated from here
../include/amanith/geometry/gmatrix.h:326: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[1]: Leaving directory `/var/tmp/portage/media-libs/amanith-0.3-r1/work/amanith/build'
make: *** [sub-build-make_default-ordered] Error 2
*
* ERROR: media-libs/amanith-0.3-r1 failed.
* Call stack:
* ebuild.sh, line 46: Called src_compile
* environment, line 2018: Called die
* The specific snippet of code:
* emake || diefunc "$FUNCNAME" "$LINENO" "$?" "emake failed"
* The die message:
* emake failed
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/media-libs/amanith-0.3-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-libs/amanith-0.3-r1/temp/environment'.
* This ebuild used the following eclasses from overlays:
* /usr/portage/eclass/eutils.eclass
* /usr/portage/eclass/multilib.eclass
* /usr/portage/eclass/toolchain-funcs.eclass
* /usr/portage/eclass/portability.eclass
*
* Messages for package media-libs/amanith-0.3-r1:
*
* ERROR: media-libs/amanith-0.3-r1 failed.
* Call stack:
* ebuild.sh, line 46: Called src_compile
* environment, line 2018: Called die
* The specific snippet of code:
* emake || diefunc "$FUNCNAME" "$LINENO" "$?" "emake failed"
* The die message:
* emake failed
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/media-libs/amanith-0.3-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-libs/amanith-0.3-r1/temp/environment'.
* This ebuild used the following eclasses from overlays:
* /usr/portage/eclass/eutils.eclass
* /usr/portage/eclass/multilib.eclass
* /usr/portage/eclass/toolchain-funcs.eclass
* /usr/portage/eclass/portability.eclass |
ovviamente il buffer del terminale è pieno fino in cima dell' "error: assignment of read-only location " |
|
| Back to top |
|
|
Flameeyes
Retired Dev
Joined: 30 Mar 2005
Posts: 189
Location: London, Europe
|
| Posted: Thu Jan 17, 2008 6:23 pm Post subject: |
|
|
ashlar, l'errore che riporti non mi pare essere relativo a nulla che tu possa mettere in CFLAGS o LDFLAGS. Pare più un errore interno del programma, o relativo a qualche libreria che ha reso costante qualcosa che prima non era.
Per quanto riguarda --sort-common, non l'homai usato di persona, quindi non saprei dire qual'è la sua affidabilità, l'ho visto chiamato in causa più di un paio di volte come causa di problemi da altri sviluppatori però.
E -mtune=generic è veramente _generico_, utile praticamente solo se si stanno compilando binari per varie macchine diverse, altrimenti è molto meglio evitarlo, preferendo -march=native (-mtune è comunque un'aggiunta, serve per permettere al codice binario di esere compatibile con una data versione dell'architettura, ma aggiungendo possibili ottimizzazioni per una versione successiva; per esempio -march=i586 -mtune=pentium4 permette di avere binari che funzionano su qualsiasi processore di classe Pentium o successiva, ma con dei percorsi ottimizzati per pentium4; a meno che non si stia utilizzando un chroot per compilare su una macchina superiore diversa, -mtune è molto inutile).
_________________
You want to know what I'm working on right now? Just follow my blog. |
|
| Back to top |
|
|
ashlar
Tux's lil' helper
Joined: 14 Jun 2006
Posts: 140
|
| Posted: Thu Jan 17, 2008 6:41 pm Post subject: |
|
|
come al mio solito ho risolto con la forza bruta, ho dawngradato glew alla versione 1.3.5 e tutto sembra andare  |
|
| Back to top |
|
|
!equilibrium
Bodhisattva
Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC
|
| Posted: Fri Jan 18, 2008 4:47 pm Post subject: |
|
|
| djinnZ wrote: | | c'è un thread aperto da cazzantonio sui problemi di precisione numerica che comporta questa flag |
il problema della precisione in virgola mobile delle FPU è trascurabile visto che il 99.999% dei pacchetti presenti in portage richiedono una precisione di 2 (o la massimo 3) valori dopo la virgola, quindi una risoluzione di 32bit è generalmente sovra dimensionata (le FPU hanno come minimo una risoluzione di 64bit quindi stiamo già facendo una strace di bit innocenti); in quel 0.001% restano ovviamente quegli applicativi per uso scientifico/matematico dove potrebbe essere obbligatoriamente richiesta una risoluzione effettiva di 80bit (a parte il fatto che non ne ho trovati in portage...), in tal caso basta usare mfpmath=sse,i387 per la compilazione di quel pacchetto ³.
| djinnZ wrote: | | per il resto il problema è se consente di incrementare le prestazioni o meno ma non ho trovato alcunchè di affidabile per dire su quale cpu e bene e su quale è male. |
- il coprocessore x87 è un semplice processore lineare, questo vuol dire che le varie operazioni in virgola mobile che deve compiere, vengono eseguite una alla volta (FIFO) senza nessun tipo di parallelismo, cosa invece che avviene con le moderne FPU SIMD;
- x87 dispone di un numero limitato di registri a differenza delle FPU SIMD che ne dispongono in abbondanza; inoltre le FPU SIMD possono smistare il 'register pressure' su altre FPU (tipo MMX e 3DNow) se presenti e quindi usare un numero estremamente elevato di registri;
- le FPU SIMD della AMD possono essere usate in contemporanea in modo da aumentare il parallelismo dei calcoli in virgola mobile 1;
- sui più noti OS ² a 64bit l'x87 viene totalmente ignorato dai compilatori (lo stesso gcc usa mfpmath=sse come valore di default, se non diversamente richiesto);
¹ io so che solo Windows è in grado di supportare a pieno quest'aspetto e che viene largamente usato per migliorare le performance delle riproduzioni audio/video;
² compreso Windows (ovviamente la versione a 64bit);
³ a dirla tutta, non sta all'utente finale fare questo tipo di check, ma *dovrebbe* essere compito degli autotools di quel pacchetto in modo da garantire la risoluzione in virgola mobile adeguata in base alle CFLAGS rilevate.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Fri Jan 18, 2008 6:08 pm Post subject: |
|
|
grazie per aver ripetuto l'intervento anche se bastava il link (questo è favorire la pigrizia) IMHO.
Appunto solo che non devi presumere l'uso per calcolo per poter avere problemi, quando e se trovo il tempo riverifico (se le costanti vengono sovradimensionate non ti ritrovi con i problemi di troncamento? A me pare che potrebbero spuntare fuori.) ma concordo nel dire che è meglio lasciar fare ai devel che hanno una precisa idea di quel che c'è nel codice.
In ogni caso mi domando sempre, su una architettura x86 che gira su processori amd ed anche su processori amd64 (in pratica -march=athlon-xp), quale guadagno ci possa essere tra fpmath=sse e fpmath=i387 nell'impiego "normale" e come questo incide sull'impegno della cpu (in termini di calore/assorbimento).
Per il momento mi pare che non ne valga la pena (soprattutto perchè dovrei comunque andare di -e system) ma mi farebbe piacere essere smentito ed aggiungere l'ennesima ricerata (mi cospargo il capo di cenere per l'orrido neologismo ed invoco pietà per il pessimo umorismo).
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist
Last edited by djinnZ on Tue Jan 22, 2008 5:56 pm; edited 1 time in total |
|
| Back to top |
|
|
xveilsidex
Guru
Joined: 27 Dec 2005
Posts: 370
Location: Bari
|
| Posted: Sun Jan 20, 2008 3:19 pm Post subject: |
|
|
| riverdragon wrote: | | xveilsidex wrote: | | Non sono pienamente d'accordo nel mettere prescott sul centrino-duo o core-duo xkè i prescott utilizzavano un architettura piu' vekkia (netburst) rispetto a quella core. |
Non c'entra. Controlla anche su http://gentoo-wiki.com/Safe_Cflags#Intel_Core_Solo.2FDuo e apri il link segnalato nelle note; -march=prescott rende ridondante -msse3, differentemente da -march=pentium-m. La questione di gcc-4.2 è una mia confusione, non contarla.
| Flameeyes wrote: | | -fforce-address può creare problemi con certe applicazioni specie se mangiano registri a colazione pranzo e cena (FFmpeg, Mplayer, xine). |
Confermo per ffmpeg, ho impostato l'eccezione dentro a /etc/portage/env/, mplayer e xine compilano normalmente.
| Flameeyes wrote: | | Per quanto riguarda -mfpmath=sse... ormai _dovrebbe_ essere stabile, ma ha il problema di cambiare il formato delle variabili in virgola mobile. Certo software (ma sinceramente non ho un esempio sotto mano) non gradisce questo perché assume che x86 == math i387. Usare a proprio rischio e pericolo. |
Non ho ancora incontrato problemi con questa opzione; comunque, come dicevo prima, dovrebbe essere molto utile con i core dothan e sonoma, che usano -march=pentium-m ma non hanno il baco dei banias (in questi core il codice sse lavora molto lento). Qui su uno yonah entriamo nel "non chiaro" che circonda buona parte delle opzioni di gcc |
se setto come cflag -march=prescott per il mio core duo nella configurazione del kernel devo settare come cpu "Pentium4 ecc... " o "core2 or newer " ? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Forum italiano (Italian)
