# Aumentare la prestazioni con l'aiuto delle cflags

## rete27

Ciao... sto provando a variare le cflags per vedere fino a che punto riesco ad ottimizzare la compilazione e di conseguenza tutto l'intero andazzo della macchina.

vi posto il cpuinfo

```

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 7

model name      : Pentium III (Katmai)

stepping        : 3

cpu MHz         : 451.053

cache size      : 512 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr sse

bogomips        : 902.51

clflush size    : 32

```

attualmente le cflags che uso sono

```
-march=pentium3 -O2 -pipe -fomit-frame-pointer
```

ora volevo provare a fare delle modifiche ma non so come posso avere un riscontro, o meglio come posso fare una compilazione "fittizia" ne troppo lunga ma ne troppo breve ?

e come posso monitorare la durata della compilazione stessa ?

----------

## Ic3M4n

secondo me il gioco non ne vale la candela. meglio avere delle impostazioni standard ed utilizzare quelle. L'unica cosa che io ho di differente rispetto a te è l'utilizzo diLDFLAGS -Wl, ---as-needed che dovrebbero "teoricamente" produrre dei file più piccoli, però non è che al momento dell'utilizzo ti rendi conto di aver un computer che scheggia.

----------

## rete27

io ho provato così 

```

#include <stdio.h>

#include <stdlib.h>

int fib (int num)

{

   if (num == 0)

      return 0;

   else if (num == 1)

      return 1;

   else

      return fib(num - 1) + fib(num - 2);

}

int main (int argc, char **argv)

{

   printf("%d\n", fib(atoi(argv[1])));

   

   return 0;

}
```

bene compilate con cc <nomefile> dopo date un bel "time ./<nomefile> 42"

e postate il risultato.

per ora il mio migliore è:

 *Quote:*   

> 
> 
> real    0m7.894s
> 
> user    0m7.894s
> ...

 

che ne dite ? però questo risulatato lo ottenuto su

 *Quote:*   

> processor       : 0
> 
> vendor_id       : GenuineIntel
> 
> cpu family      : 15
> ...

 

sulla macchina di prima il real è attorno ai 58 sec...

che ne dite ?

----------

## Kernel78

Stai cercando di raggiungere un obiettivo effimero seguendo il percorso sbagliato.

Ottenere il tempo più veloce nella compilazione non è assolutamente sinonimo di sistema più veloce, se togli le ottimizzazioni di sicuro compili molto più in fretta ma ti trovi con un sistema "non ottimizzato", ti suggerisco quindi di accantonare il desiderio di spaccare il secondo nella compilazione.

Inoltre avere un sistema spremuto al massimo comporta scegliere CFLAGS specifiche per ogni singolo pacchetto visto che per esempio un programma che fa uso intensivo della cpu potrebbe avvantaggiarsi di -O3 mentre un programma che usa pochissima cpu potrebbe rendere il sistema più performante usando -Os

Secondo me se proprio vuoi un sistema spinto usa CFLAGS standard (così almeno non ti vai a cercare problemi) e comprati un buon quantitativo di RAM per montare / in ram (c'è una discussione che spiega come fare), in questo modo il tempo di caricamento si riduce drasticamente.

----------

## djinnZ

 *Ic3M4n wrote:*   

> ...

 

sono d'accordo, se proprio vuoi cercare prestazioni verifica la possibilità di usare le ldflag (--as-need e -O1 sono solo non supportate mentre tutte le altre sono propriamente sconsigliate, la differenza c'è) e l'ottimizzazione per pacchetto.

In ogni caso l'impatto delle ottimizzazioni varia da programma a programma.

----------

## GiRa

Potresti togliere altri simboli con -momit-leaf-frame-pointer, per quanto riguarda il togliere le liberie linkate ho letto di ebuild che non compilano.

Potresti usare il prelink al limite.

----------

## riverdragon

Momit-leaf-frame-pointer mi risulta sia una versione più leggera di fomit-frame-pointer, che libera alcuni registri senza perdere tutte le informazioni necessarie per il debugging. Se questo è corretto fomit-frame-pointer rende inutile momit-leaf-frame-pointer.

EDIT: da qui: *gnu wrote:*   

> -momit-leaf-frame-pointer
> 
>     Don't keep the frame pointer in a register for leaf functions. This avoids the instructions to save, set up and restore frame pointers and makes an extra register available in leaf functions. The option -fomit-frame-pointer removes the frame pointer for all functions which might make debugging harder.

 

Ma leggete anche qui... dice il contrario  :Confused: 

----------

## GiRa

Su un P3 servono entrambe.

Non chiedete come faccio a saperlo. Me lo ricordo e basta  :Smile:  La teoria è andata persa negli annali.

----------

## Flameeyes

No non servono entrambe, e soprattutto non può esserci nulla di diverso tra P3 e qualsiasi altro processore della famiglia x86. Tenere entrambe ha solo l'effetto di usare -momitetcetcetc quando -fomit-frame-pointer viene filtrata.

E prelink è mezzo inutile (qui un po' di motivazioni), finirebbe probabilmente a richiedere troppo tempo su un P3 e ancora peggio dovrebbe usare l'opzione -m, che con quanto scritto sul link non dà esattamente un bel risultato.

Un consiglio? -O2, -march, -fomit-frame-pointer, e basta. Tentare di spingere GCC spesso può avere effetti contrari.

Il tuo benchmark non è esaustivo, ci sono decine di variabili da considerare, non solo la velocità di masticazione dei numeri, se il programma è piccolo, sarà tenuto in cache dal sistema, se il programma è più complesso, forzare ottimizzazioni pesanti rischia di aumentare la dimensione del codice al punto tale che l'esecuzione diventa più lenta.

Oltretutto il punto cruciale di velocità di un software moderno sta nelle librerie condivise, che usano un registro in meno per le ottimizzazioni, tentare di alzarle troppo rischia di creare codice non funzionante,, o più lento per il save/restore dei registri.

----------

## rete27

Se non sbaglio il prelink velocizza solo l'avvio dei programmi e non aiuta ad aumentare le prestazioni in termini di computazione...ho fatto varie prove con varie cflags e varie ottimizzazioni in fase di compilazione con il classico cc -O3 ma i tempi non cambiano.

la cosa strana è che passando da -O2 a -O3 e inserendo anche -funroll-loops le prestazioni non variano...

non capisco proprio il perché...o che la macchina è già "tirata" e non ne vuole sapere...

----------

## riverdragon

 *Flameeyes wrote:*   

> Tenere entrambe ha solo l'effetto di usare -momitetcetcetc quando -fomit-frame-pointer viene filtrata.

 E quand'è che viene filtrata?

----------

## Cazzantonio

Che io sapessi l'LDFLAG --as-needed aveva seri problemi di compatibilità con un sacco di programmi (gtk mi pare). In pratica usandola eri sicuro che qualche cosa non avrebbe funzionato.

E' cambiato qualcosa? E' diventata "usabile"?

----------

## djinnZ

 *rete27 wrote:*   

> Se non sbaglio il prelink velocizza solo l'avvio dei programmi

 

infatti ma con -O3 crea problemi e quando usi più volte il prelink sullo stesso eseguibile tende ad aumentarne le dimensioni.

 *rete27 wrote:*   

> la cosa strana è che passando da -O2 a -O3 e inserendo anche -funroll-loops le prestazioni non variano...

 in realtà sono i mattoni a beneficiare di -O3 ma poi funzionano male e non serve a molto (e viene filtrata, vedi OOo).

Nota che -O3 sul gcc 4.x corrente i  gentoo "normale" non funziona benissimo.

@cazzantonio: funziona se la usi con criterio su alcuni pacchetti. Ho kdelibs compilato senza e gli applicativi kde compilati con che funzionano egregiamente.

Per esempio mysql va con --as-need ma la sua libreria interna no (quindi in attesa di tovare un modo di convincerlo a compilare giustamente meglio disabilitarla).

----------

## Cazzantonio

 *djinnZ wrote:*   

> @cazzantonio: funziona se la usi con criterio su alcuni pacchetti. Ho kdelibs compilato senza e gli applicativi kde compilati con che funzionano egregiamente.
> 
> Per esempio mysql va con --as-need ma la sua libreria interna no (quindi in attesa di tovare un modo di convincerlo a compilare giustamente meglio disabilitarla).

 Si anche io sapevo che bisognava scegliere con il misurino i programmi compatibili. Siccome l'avevo vista consigliare sportivamente mi era venuto il dubbio che fosse utilizzabile tranquillamente nel make.conf

----------

## Ic3M4n

io è un bel po' che la utilizzo. tutto il sistema è compilato con as needed. non so dirti però se nel frattempo i devel gentoo la filtrino a livello di ebuild.

----------

## Flameeyes

--as-needed NON viene filtrata, e NON deve essere filtrata. Se un pacchetto non compila con --as-needed è rotto, filtrarla nasconderebbe solo il difetto.

Dopo questa premessa, --as-needed non è _ufficialmente_ supportata, ma è comunque stabile, considerando che ricevo buona parte dei bug a riguardo, è da un pezzo che non ne vedo per pacchetti comuni. Molti dev ormai la usano sulle loro macchine e questo aiuta.

Non capisco che problemi dovrebbe avere MySQL: io ce l'ho installato sia da ~amd64 che da amd64 (su un chroot) e funziona perfettamente.

C'è una guida (che ho scritto io) su come correggere i problemi con --as-needed, per chi fosse interessato.

Per il resto, -O3 è più probabile che rompa un eseguibile piuttosto che farlo diventare più veloce... e per quanto riguarda -funroll-loops... scusate, ma a me viene da ridere in faccia a chiunque si aspetti che faccia qualcosa di utile.

Srotolare i cicli è utile solo quando i cicli sono _molto_ piccoli, e in quei casi di solito se ne occupa GCC a fare lo srotolamento. Con -funroll-loops è più probabile che il codice aumenti sproporzionatamente di dimensione, e visto che dubito che siate tutti qua ad usare Xeon con 4MB di cache, vi lascio intuire che effetto fa l'aumentare la dimensione del codice sulla cache del processore.

----------

## Kernel78

 *Flameeyes wrote:*   

> C'è una guida (che ho scritto io) su come correggere i problemi con --as-needed, per chi fosse interessato.
> 
> 

 

presumo tu ti riferisca a questa, giusto ?

----------

## bandreabis

 *Kernel78 wrote:*   

>  *Flameeyes wrote:*   C'è una guida (che ho scritto io) su come correggere i problemi con --as-needed, per chi fosse interessato.
> 
>  
> 
> presumo tu ti riferisca a questa, giusto ?

 

Se ho capito bene questa flag funziona solo su amd64 compilata come x86_64, giusto?

----------

## lavish

 *bandreabis wrote:*   

>  *Kernel78 wrote:*    *Flameeyes wrote:*   C'è una guida (che ho scritto io) su come correggere i problemi con --as-needed, per chi fosse interessato.
> 
>  
> 
> presumo tu ti riferisca a questa, giusto ? 
> ...

 

Secondo me dovresti controllare il tuo inglese  :Wink: 

 *Quote:*   

> This flag should (note again the conditional) work on every Linux platform supported by binutils, but tests are being done only on AMD64 at the moment (some unofficial testing is being done on PPC too, but problems with binutils mix up their validity). It's known not to work on FreeBSD and probably does not work on other non-Linux targets. 

 

----------

## djinnZ

 *Flameeyes wrote:*   

> Non capisco che problemi dovrebbe avere MySQL: io ce l'ho installato sia da ~amd64 che da amd64 (su un chroot) e funziona perfettamente.

 

Mysql non ha alcun problema, funziona perfettamente, ma compilato con --as-need ho avuto problemi di linking verso libmysqlclient con alcuni pacchetti non ricordo se DBD o ODBC.

Visto che per il momento mysql è li quasi per bellezza non ho investigato più di tanto e la ho rimossa. Dopo di che me ne sono dimenticato e mi è venuto a mente quando ho letto il thread.

----------

## Flameeyes

Il problema è negli altri pacchetti (ODBC suppongo, visto che non l'ho mai usato, DBD se è quello di Perl funziona ne son sicuro), non in MySQL  :Smile: 

----------

## !equilibrium

 *rete27 wrote:*   

> flags           : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr sse

 

vedo che il tuo P3 supporta le SSE, quindi potresti provare ad usare -mfpmath=sse, ma prima di farlo assicurati due cose:

- che la velocità di clock della FPU sia uguale e NON inferiore a quella della CPU;

- che sia una SSE completa, cioè che abbia una FPU di tipo 'double precision' e non 'single precision', altrimenti il gioco non ne vale la candela (il beneficio che ottieni non è apprezzabile)

----------

## cloc3

 *Flameeyes wrote:*   

> --as-needed NON viene filtrata, e NON deve essere filtrata.

 

io addirittura mi aspetterei qualcosa del tutto opposto, ma non so se quello che penso sia vero o abbia senso.

secondo me, se un pacchetto funziona bene con --as-needed e gli sviluppatori upstream e/o l'estensore dell'ebuild hanno configurato opportunamente le cose, emerge dovrebbe selezionare automaticamente la flag senza l'intervento esplicito dell'utente.

è una stupidaggine pazzesca o è qualcosa che accade realmente in qualche occasione?

----------

## MeMyselfAndI

non essendo supportata direttamente da portage non credo che possa avvenire automaticamente.. non avrebbe molto senso !

----------

## Flameeyes

Alcuni upstream (gettext, libiconv, elfutils, gxine) "vedono" un linker compatibile con --as-needed e lo attivano di default nel configure script.

Se fossi ancora nel team KDE avrei probabilmente inserito una dipendenza su binutils moderne e forzato --enable-new-ldflags (che non fa altro che abilitare --as-needed su Gentoo, visto che --enable-new-dtags è _sempre_ abilitato) per le ebuild di KDE...

----------

## djinnZ

 *cloc3 wrote:*   

> emerge dovrebbe selezionare automaticamente la flag senza l'intervento esplicito dell'utente

 

emerge no gli automake si, lo so per esperienza personale con mplayer (e ci ho messo un pezzo ad accorgermene che anche se la disabilitavo nel make.conf la usava ugualmente su una precedente versione, probabilmente dipendeva da binutils perchè in seguito ho disabilitato --as-need e -O1 per gcc e binutils a causa di problemi del preprocessore).

----------

## Flameeyes

Hai scelto proprio un pacchetto che _non_ usa automake (o autoconf per quel che importa)... MPlayer ha un suo proprio build system.

----------

## rete27

dopo aver provato un po di cflags ho capito 2 cose :

1) come mi ha detto Ic3M4n il gioco non vale la candela...

2) fib.c non puo essere usato per testare le "prestazioni" o meglio il risultato in termini di secondi non è un indice affidabile da punto di vista prestazionale.

Dalle mie prove ho imparato a usare al meglio le use e ho capito che è meglio avere un sistema un po meno "tirato" ma affidabile perché è inutile riuscire a compilare il tempi record ma poi avere degli ebuild che in fase di compilazione generano errore facendo fermare il compilatore.

----------

## Cazzantonio

Visto il consiglio recente di Flameeyes ho provato a ricompilare tutto con --as-needed. Contrariamente a quanto sempre sostenuto (che le cflags/ldflags personalizzate con cambiano granché) si nota un miglioramento sensibile (nei tempi di avvio) con --as-needed. Sono abbastanza contento di questa cosa visto che la macchina è vecchiotta e ogni botta di vita è sempre gradita.

----------

## Kernel78

 *Cazzantonio wrote:*   

> Visto il consiglio recente di Flameeyes ho provato a ricompilare tutto con --as-needed. Contrariamente a quanto sempre sostenuto (che le cflags/ldflags personalizzate con cambiano granché) si nota un miglioramento sensibile (nei tempi di avvio) con --as-needed. Sono abbastanza contento di questa cosa visto che la macchina è vecchiotta e ogni botta di vita è sempre gradita.

 

giusto per curiosità come hai fatto ? Ti sei limitato a modificare il make.conf e dare un emerge -e world o hai fatto altro ?

----------

## MeMyselfAndI

io ho fatto cosi' e lo uso da un po senza problemi.

----------

## Cazzantonio

 *Kernel78 wrote:*   

> giusto per curiosità come hai fatto ? Ti sei limitato a modificare il make.conf e dare un emerge -e world o hai fatto altro ?

 

Per generare la lista dei pacchetti:

```
emerge -pe world |grep ebuild|cut -d"]" -f2|sed -e 's/ /=/'|cut -d" " -f1 >pacchetti
```

Per compilare

```
nohup emerge -1 `cat pacchetti` &
```

emerge -e world è sempre rischioso perché se ti si interrompe rischi di dover ripartire daccapo...

```
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--as-needed -s"
```

Mi si era interrotta la compilazione di gcc per qualcosa riguardo alle librerie fortran, tuttavia l'ho ricompilato per ultimo ed è andato liscio.

----------

## bandreabis

 *Cazzantonio wrote:*   

>  *Kernel78 wrote:*   giusto per curiosità come hai fatto ? Ti sei limitato a modificare il make.conf e dare un emerge -e world o hai fatto altro ? 
> 
> Per generare la lista dei pacchetti:
> 
> ```
> ...

 

LDFLAG -O1 non centra con CFLAG -O2, giusto?

----------

## Cazzantonio

 *bandreabis wrote:*   

> LDFLAG -O1 non centra con CFLAG -O2, giusto?

 ?? Più o meno come il governo con la piogga.

----------

## bandreabis

 *Cazzantonio wrote:*   

> ...
> 
> Per compilare
> 
> ```
> ...

 

 *Quote:*   

> nohup emerge -1pv `cat pacchetti`
> 
> nohup: ignoring input and appending output to `nohup.out'

   :Question: 

----------

## Kernel78

 *bandreabis wrote:*   

>  *Cazzantonio wrote:*   ...
> 
> Per compilare
> 
> ```
> ...

 

non colgo il motivo della tua perplessità ...

----------

## bandreabis

 *Kernel78 wrote:*   

>  *bandreabis wrote:*    *Cazzantonio wrote:*   ...
> 
> Per compilare
> 
> ```
> ...

 

Cioè: è tutto normale? Bene.   :Razz: 

----------

## Kernel78

 *bandreabis wrote:*   

> Cioè: è tutto normale? Bene.  

 

detto in soldoni nohup mette il processo in background (detto proprio alla grezza, in realtà fa ben di più ...)

----------

## Cazzantonio

Dovresti documentarti sui programmi prima di usarli... se nohup avesse cancellato il tuo hd?

almeno dare "man nohup" per capire cosa fa...

P.S. perché non quotare solo la parte di testo rilevante? Quotare tutto un post crea quelle fastidiose "pidamidi di citazioni" che rendono il tutto più illeggibile

----------

## Flameeyes

--enable-new-dtags non serve assolutamente a nulla su Gentoo: i nuovi dtags sono abilitati forzosamente in binutils da una cosa come almeno almeno tre anni.

E sì, --as-needed dà una sferzata all'avvio  :Wink:  Non si noterà molta differenza durante l'esecuzione, ma l'avvio migliora parecchio specie per quelle applicazioni (per esempio quelle di DE complessi come KDE e GNOME) che avrebbero una ventina di librerie presenti che non vengono utilizzate.

----------

## djinnZ

sono su hardened e gcc 3.x (quindi la cosa va presa con le pinze da voialtri, potrebbe essere vero il contrario) ma -O1 si è mostrata assai più disastrosa di --as-need, in particolare con i problemi (a sorpresa) del compilatore (gcc1).

Quelle ldflags su binutils e gcc le eviterei, al massimo solo --as-need.

@flameyes: già, bacio ancora la terra sotto i piedi tuoi che la hai introdotta e di drittzt che mi ha indirizzato sulla tua pagina di chiarimenti.

L'unico dubbio che ancora mi rimane è se abilitare l'ottimizzazione per sse.

----------

## Onip

Alcuni consigli da uno che --as-needed ce l'ha da più di un anno.

ewo sviluppato da uno dei 'nostri'. Utile per chi sta emergendo il mondo.

Bug che segnala pacchetti problematici con --as-needed.

bashrc-ng utile (con il modulo perpackage) per poter impostare delle eccezioni alle LDFLAGS per i packages di cui sopra. E' in via di sviluppo l'equivalente per la verisione nuova di bashrc, sviluppata dal nostro mod !equilibrium.

Saluti.

----------

## Cazzantonio

 *Flameeyes wrote:*   

> E sì, --as-needed dà una sferzata all'avvio 

 Si è proprio una cosa sensibile. Finora mi sono sempre tenuto lontano dal mondo dell'ottimizzazione (a parte pochi esperimenti iniziali), tuttavia --as-needed è una delle poche flag che migliorano sensibilmente l'uso del pc.

----------

## Flameeyes

-Wl,-O1 non dovrebbe causare alcun problema in realtà, considerando che viene solo usata per le librerie condivise.. non dipende comunque dalla versione di gcc ma di binutils.

----------

## xveilsidex

 *Flameeyes wrote:*   

> -Wl,-O1 non dovrebbe causare alcun problema in realtà, considerando che viene solo usata per le librerie condivise.. non dipende comunque dalla versione di gcc ma di binutils.

 

 io ho queste  cflags  e ldflags sul mio centrino duo 1.66 ghz

CFLAGS="-O2 -march=pentium-m -msse3 -pipe  -fomit-frame-pointer "

LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-zdynsort -Wl,--as-needed" 

in teoria sarebbe meglio avere solo queste? 

CFLAGS="-O2 -march=pentium-m -msse3"

LDFLAGS="-O1 -Wl,--as-needed"

----------

## djinnZ

Le cflags vanno bene sono le ldflags, una è ridondante come leggi sopra le altre due mi pare che siano ancora sconsigliate.

@flameyes: veramente pensavo che dipendesse dal codice interno di gcc (stack smash, errori e crash non riproducibili) patch hardening comprese

----------

## xveilsidex

 *djinnZ wrote:*   

> Le cflags vanno bene sono le ldflags, una è ridondante come leggi sopra le altre due mi pare che siano ancora sconsigliate.
> 
> @flameyes: veramente pensavo che dipendesse dal codice interno di gcc (stack smash, errori e crash non riproducibili) patch hardening comprese

 

forse ricordo male ma anche formit-frame-pointer non da grandi vantaggi! cmq con il mio centrino duo ( ke non è un core due duo ) posso mettere  come march nocona  ??

----------

## riverdragon

Con il Core Duo se lavori a 32 bit è meglio mettere -march=prescott e da quando avrai gcc-4.2 installato aggiungere -mtune=generic. Sul mio core duo:

```
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer -fforce-addr -mfpmath=sse"
```

-mfpmath=sse potrebbe essere ridondante, è necessario sui pentium-m successivi al core banias (come dothan e sonoma).

----------

## xveilsidex

 *riverdragon wrote:*   

> Con il Core Duo se lavori a 32 bit è meglio mettere -march=prescott e da quando avrai gcc-4.2 installato aggiungere -mtune=generic. Sul mio core duo:
> 
> ```
> CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer -fforce-addr -mfpmath=sse"
> ```
> ...

 

Si lavoro a 32 bit cmq 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. cmq il mio è un yonoah x questo volevo sapere se era compatibile con la flag nocona oppure continuare ad utilizzare la dicitura pentium-m ( o forse la prescott come dici tu )  xkè con le gcc-4.2 bisognera' mettere -mtune=generic ? (x il fatto che fonderanno nel kernel l'architettura x86_32 x86_64?)  ma se non metti la flag -msse3 questa non viene attivata o è sempre attivata automaticamente?

----------

## Flameeyes

-fforce-address può creare problemi con certe applicazioni specie se mangiano registri a colazione pranzo e cena (FFmpeg, Mplayer, xine).

-fomit-frame-pointer è più o meno necessario su x86, perché libera un registro, e x86 ne ha veramente pochi. Senza -fomit-frame-pointer, per esempio, è impossibile compilare alcune parti di xine, mentre altre parti di FFmpeg (ottimizzazioni SSE o MMX) sarebbero saltate.

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.

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.

xveilsidex, se _non_ è un Core2 Duo, allora non è un nocona visto che non ha il supporto 64-bit.

----------

## xveilsidex

flameyes quali cflag e ldflag, quindi mi consigli ?

----------

## riverdragon

 *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  :Smile: 

----------

## xveilsidex

@riverdragon, grazie x la dritta non l'avevo notata quella nota!   :Wink:   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?

----------

## riverdragon

Qui nel make.conf io ho

```

CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer -fforce-addr -mfpmath=sse"

LDFLAGS="-Wl,-O1 -Wl,--sort-common -s -Wl,--as-needed"
```

----------

## djinnZ

 *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).

----------

## Flameeyes

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.

----------

## Manwhe

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?

----------

## djinnZ

 *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.

----------

## xveilsidex

 *Manwhe wrote:*   

> Ciao a tutti.
> 
> Ho un Intel Core 2 Duo T5500
> 
> CHOST="i686-pc-linux-gnu" ,ACCEPT_KEYWORDS="x86" 
> ...

 

Dicono che con -march=prescott   la flag msse3 è ridondante!

----------

## ashlar

anche io avevo una mattinata da perdere e allora mi sono detto proviamo 

a fare un bell' *Quote:*   

> emerge  -e system

 , 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...

```
 * 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?

----------

## djinnZ

 *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.

----------

## Flameeyes

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.

----------

## ashlar

 *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 :

```

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ò

----------

## riverdragon

 *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.

 

----------

## xveilsidex

 *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"

----------

## riverdragon

 *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.

----------

## djinnZ

https://forums.gentoo.org/viewtopic-t-83375.html

----------

## riverdragon

Non si capisce quale sia il problema, né chi abbia trasgredito le linee guida.

----------

## djinnZ

 :Embarassed:  ho saltato il "@xveilsidex", scusa ma non mi ero accorto che avevi risposto nel frattempo.

----------

## ashlar

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:

```

../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 "

----------

## Flameeyes

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).

----------

## ashlar

come al mio solito ho risolto con la forza bruta, ho dawngradato glew alla versione  1.3.5 e tutto sembra andare  :Very Happy: 

----------

## !equilibrium

 *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.

----------

## djinnZ

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).

----------

## xveilsidex

 *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 " ?

----------

## riverdragon

Il tuo non è un core2 o successivi, quindi vai col pentium4   :Wink: 

----------

## spillo

Ciao a tutti, sto preparando gentoo anche sul nuovo pc e mi sto documentando per quanto riguarda le ottimizzazioni. In questo topic ho trovato pareri contrastanti a molti altri letti per la rete riguardo a --as-needed, ma se non ho capito male voi non sconsigliereste di usarlo giusto? attualmente io ho queste impostazioni:

```
CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer"

CXXFLAGS="{CFLAGS}"

LDFLAGS="-Wl,-O1"
```

ho questa mezza idea di aggiungere  --as-needed perchè sembrerebbe una buona cosa e comunque Flameeyes ha scritto un'ottima pagina in cui spiega come risolvere molti problemi. anche questa pagina sembra abbastanza rassicurante, se poi consideriamo che questo topic risale a qualche mese fa...

inoltre -O1 mi conviene toglierlo? ho visto causare problemi a molti...

il mio cat /proc/cpuinfo (x4 ovviamente)

```
processor   : 0

vendor_id   : GenuineIntel

cpu family   : 6

model      : 15

model name   : Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz

stepping   : 11

cpu MHz      : 2400.082

cache size   : 4096 KB

physical id   : 0

siblings   : 4

core id      : 0

cpu cores   : 4

fpu      : yes

fpu_exception   : yes

cpuid level   : 10

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

bogomips   : 4802.85

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:
```

----------

## Onip

Io non ho problemi, per adesso, e per i pochi pacchetti non compatibili è possibile utilizzare la directory /etc/portage/env/ per impostare le opportune eccezioni ( sul forum o wiki si trovano un po' più info ).

----------

## djinnZ

ho quasi se non tutto il sistema compilato con -O1 (per esperienza è l'accoppiata -O3 -Wl,-O1 a fare realmente danni gravi ma -O3 si sa che funziona male) e --as-need quindi il grosso dei problemi mi pare che siano stati risolti.

Se proprio ti capita quella singola libreria o quel singolo pacchetto che si impunta non ti costa molta fatica disabilitarli per una prova (e segnalare il problema).

Con kde la differenza si vede, te lo posso assicurare.

Quanto al problema di gcc (eseguibile cc1, parte del preprocessore, sistematicamente danneggiato da -Wl,-O1) usando -fforce-addr i problemi sono spariti (ed OOo è decisamente più spedito nell'avvio) ma voglio specificare che uso il gcc 3.6 in hardening, quindi non so come potrebbero comportarsi le versioni successive.

Se attivi anche --as-need ti consiglio di attivare anche la use glibc-omitfp e ricompilare il sistema oltre a fare un backup del gcc compilato senza ldflags (assai probabilmente non ti servirà mai, ma nel dubbio...).

----------

## spillo

ottimo, quindi credo di andare sul tranquillo...di questa gentoo non ho preparato nemmeno il kernel quindi non devo ricompilare nulla, parto da zero  :Wink:  userò anche O1 visto che non porterebbe problemi (poi vabbè, l'inconveniente capita)...

annoterò l'accorgimento di aggiungere la use glibc-omitfp  :Smile: 

come su kde, spero la differenza si veda anche su gnome che è certamente meno scattante   :Confused: 

Vi ringrazio intanto per le risposte, se avete altro da dire io son qui  :Wink: 

----------

## djinnZ

Già che mi trovo qualcuno mi sa indicare qualche informazione in più su -fforce-addr e -momit-leaf-frame-pointer (indispensabili per compilare OOo, non ho capito il perchè).

----------

## spillo

della prima una minuscola spiegazione si trova qui della seconda non saprei...

----------

## riverdragon

 *djinnZ wrote:*   

> Quanto al problema di gcc (eseguibile cc1, parte del preprocessore, sistematicamente danneggiato da -Wl,-O1) usando -fforce-addr i problemi sono spariti ma voglio specificare che uso il gcc 3.6 in hardening, quindi non so come potrebbero comportarsi le versioni successive.

 Qui gcc 4.1, -force-addr, --as-needed e -O2 (il resto non lo ricordo e non posso recuperarlo ora), nessun problema.

 *Quote:*   

> Se attivi anche --as-need ti consiglio di attivare anche la use glibc-omitfp e ricompilare il sistema oltre a fare un backup del gcc compilato senza ldflags (assai probabilmente non ti servirà mai, ma nel dubbio...).

 Ricompilare il sistema?

Per momit-leaf-eccetera, copio da gentoo.it: *Quote:*   

> Importante:  Non combinare -fomit-frame-pointer con la flag simile -momit-leaf-frame-pointer. Usare quest'ultima flag è scoraggiato, siccome -fomit-frame-pointer svolge già quel compito propriamente. Ancora, è stato dimostrato che -momit-leaf-frame-pointer influisce negativamente sulla prestazioni del codice.

 

----------

## djinnZ

i fatti dimostrano il contrario (solo con OOo ovviamente), per questo non mi riesco a farmi una ragione della faccenda ma non ho trovato nulla.

----------

## xdarma

Buonasera a tutti,

visto che in questo thread si discute anche di LDFLAGS, credo sia il posto più adatto per un mio dubbio di poco conto:

Premesso che:

 *Quote:*   

> -s
> 
> --strip-all
> 
>  Omit all symbol information from the output file.

 

 *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.

 

 *Quote:*   

> -S
> 
> --strip-debug
> 
>  Omit debugger symbol information (but not all symbols) from the output file.

 

Ha senso usare nelle LDFLAGS anche "-Wl,-S" con l'obiettivo di ridurre le dimensioni dei binari?

Qualcuno di voi lo usa già? Come si trova?

In realtà sono cicli CPU sprecati perché portage fa già tutto automagicamente?  :-)

Ciao e grazie.

----------

## djinnZ

Con la use debug disabilitata lo stripe (-S) viene abilitato di default, ovunque è sicuro, per quel che so io; quindi perchè andarsi a cercare guai?

(ovviamente se hai lo spazio du disco ed il tempo per fare una prova nessuno ti dirà che sbagli)

-O1 (con backup in pacchetto binario di gcc/binutils/gettext su cpu amd e profilo hardened) e --as-needed sono decisamente più che sufficienti IMHO.

@riverdragon: avere binari con e senza -fomit-frame-pointer mi ha sempre creato problemi (e non di poco conto) per --as-need è il caso di farlo rilevare ad alcuni automake (glibc si regola di conseguenza se c'è --as-needed nelle ldflags, dai uno sguardo ai log se non mi credi) ed in generale, a meno che non sia intenzionale e ben circoscritto, è meglio non avere flag di ottimizzazione differenti (se per tua scelta vuoi compilare una libreria senza --as-need è una cosa, se ti ritrovi a casaccio librerie compilate con e senza i guai arriverranno prima o poi). Potevo dire ricompilare le librerie base e quelle che potrebbero richiederlo ma fai prima a lanciare un emerge -e system e lasciare il pc a ravanare per una nottata per me.

dimenticavo: -fomit-frame-pointer è sicura e valida solo per cpu x86 ed x86_64 (da intel 486 a core duo due e da amd k5 a athlon64, per capirci) al momento, su altre architetture più esoteriche per nulla quindi se non viene filtrata automaticamente è solo perchè qualche devel se ne è dimenticato od ha voluto evitare di appesantire l'ebuild con test inutili.

----------

## xdarma

 *djinnZ wrote:*   

> Con la use debug disabilitata lo stripe (-S) viene abilitato di default, ovunque è sicuro, per quel che so io; quindi perchè andarsi a cercare guai?

 

beh, proprio guai non direi: sembra che ci sia gente che "computa" tranquillamente con "-s" (nonostante il caveat di Flameeyes) quindi non credo che lo stripe del debug sia tanto rischioso e, almeno nella mia esperienza, sia sotto x86 che sotto ppc con -S non sembra creare problemi, almeno non con il profilo "desktop".

[...un attimo che tocco ferro...]

Comunque se con la USE -debug si arrangia portage a fare lo stripe dei pacchetti che danno questa possibilità, tanto di guadagnato, grazie dell'informazione  :-)

 *djinnZ wrote:*   

> -O1 (con backup in pacchetto binario di gcc/binutils/gettext su cpu amd e profilo hardened) e --as-needed sono decisamente più che sufficienti IMHO.

 

Adesso provo a ricompilare con --as-needed, poi ti saprò dire.

[...un attimo che tocco ferro...]

D'altronde gentoo ti permette anche di raschiare il fondo del barile, se lo vuoi e a tuo rischio e pericolo  :-D

 *djinnZ wrote:*   

> dimenticavo: -fomit-frame-pointer è sicura e valida solo per cpu x86 ed x86_64 (da intel 486 a core duo due e da amd k5 a athlon64, per capirci) al momento, su altre architetture più esoteriche per nulla quindi se non viene filtrata automaticamente è solo perchè qualche devel se ne è dimenticato od ha voluto evitare di appesantire l'ebuild con test inutili.

 

sei sicuro che venga filtrata? l'ho usata anche su ppc e non mi sembra sia sconsigliata nel forum dedicato a ppc.

Anche sul manuale di gcc si parla di 

"It also makes debugging impossible on some machines."

"On some machines, such as the VAX, this flag has no effect"

Quindi non mi sembra "insicura" ma se hai notizie in merito, benvengano.  :-)

----------

## djinnZ

Non ho detto che è insicura ma che è sicura solo per intel/amd x86 ed x86_64. Ovvero per ppc o ia64 semplicemente non ci sono informazioni sufficienti per dire che è sicura e su arm o sg (non chiedermi quale catorcio, mica posso tenerli a mente) crea problemi seri.

Quanto allo stripe c'era un ottimo motivo per non farlo indiscriminatamente (ma tanto per cambiare non lo ricordo adesso), io sono il primo a volerlo fare visto che per hardened è superfluo, visto che dove è possibile portage lo fa è inutile andarsi a cercare guai.

----------

## xdarma

-fomit-frame-pointer

 *djinnZ wrote:*   

> Non ho detto che è insicura ma che è sicura solo per intel/amd x86 ed x86_64. Ovvero per ppc o ia64 semplicemente non ci sono informazioni sufficienti per dire che è sicura e su arm o sg (non chiedermi quale catorcio, mica posso tenerli a mente) crea problemi seri.
> 
> 

 

in un post precedente mi sembrava tu la considerassi sicura e valida solo per x86 e x86_64 escludendo tutte le altre architetture, comunque non è un problema: vista la scarsezza di alternative "desktop" mi tocca tenermi x86 et similia

-S

 *djinnZ wrote:*   

> Quanto allo stripe c'era un ottimo motivo per non farlo indiscriminatamente (ma tanto per cambiare non lo ricordo adesso), io sono il primo a volerlo fare visto che per hardened è superfluo, visto che dove è possibile portage lo fa è inutile andarsi a cercare guai.

 

ma stai parlando dello stripe "tagliamargherite" o dello stripe del debug?

-s non rientra nei miei piani quinquennali

-S sarà forse compreso nelle operazioni di portage ma non sembra dare grattacapi

[...un attimo che tocco ferro...]

--as-needed

ho finito di ricompilare e dopo una decina di giorni di uso "normale" non mi sembra di vedere comportamenti anomali, crash o blocchi delle applicazioni, anzi c'è un leggerissimo miglioramento nei tempi di caricamento. Penso che manterrò questa LDFLAGS.

----------

