# CFLAGS e ottimizzazioni

## loxdegio

Buongiorno a tutti  :Very Happy:  Sono di nuovo qui!

Come da titolo vagando nel web alla ricerca di come impostare al meglio (ormai si tratta di limature nent'altro), mi sono imbattuto in questo flag

```
-mfpmath=both
```

E mi chiedevo se e quali miglioramenti potesse portare rispetto a

```
-mfpmath=387
```

o

```
-mfpmath=sse
```

Io già mi trovo più che bene, le stesse ottimizzazioni le sto usando su un portatile con Atom 455 e vi dico che gli hanno davvero dato un boost assurdo, ma ho letto di quel flag che combina i due tipi di ottimizzazione che ho proposto come alternativi e di un tizio che ha fatto un test che gli confermava una velocità di esecuzione di quasi 1/4 rispetto all'utilizzo del solo sse.

E' ovvio che sono ottimizzazioni utili solo in caso di necessità di resa su processi multimedia o di calcolo in senso stretto, ma usando Matlab per necessità accademiche e un altro paio di cose, sarei interessato a capire gli effetti di queste modifiche se qualcuno mi sapesse illuminare  :Very Happy: 

Ulteriori informazioni: ho un intel core 2 duo e la mia variabile CFLAGS è già settata in questo modo

```
CFLAGS="-O2 -march=native -mtune=native -mfpmath=sse -mmmx -fomit-frame-pointer -pipe"
```

----------

## ciro64

-mfpmath si riferisce alla fpu (registri ad 80 bits nel caso di 387 e se non erro a 128 bits nel caso dei registri sse2) comunque unità del processore che "si occupano" dei calcoli in virgola mobile.

Bisogna vedere che tipo di microprocessore hai.

Ad esempio parlando di qualche annetto fa il Pentium 4 nei calcoli x87 andava la metà rispetto ad un Athlon di pari frequenza.

Con le istruzioni sse2 si ottenevano invece ristultati prestazionalmente ottimi e comunque dati "più precisi coi 128 bits pittosto degli 80 di x87)

Se stai usando un Intel con sistema a 32 bits potrebbe dare ristultati migliori come velocità.

Perchè se non erro per i sistemi a 64 bits, questa impostazione è già settata come "-mfpmath=sse" di default.

----------

## loxdegio

Ciao, Grazie innanzitutto per la risposta  :Very Happy: 

Comunque quanto al prcessore in mio possesso è un Intel Core 2 Duo come ho già indicato nel primo post, mentre invece quanto alla tua ultima affermazione

 *Quote:*   

> Se stai usando un Intel con sistema a 32 bits potrebbe dare ristultati migliori come velocità.
> 
> Perchè se non erro per i sistemi a 64 bits, questa impostazione è già settata come "-mfpmath=sse" di default.

 

In quanto ho un sistema a 64bit e il comando

```
gcc -c -Q -march=native --help=target | grep mfpmath
```

mi restutuisce

```
-mfpmath=                         387
```

(copiato papale papale all'output)

Ma la mia domanda in sostanza potrebbe essere riformulata in questo modo

 *Quote:*   

> E' meglio lasciare l'impostazione di default (quindi 387 in questo caso), o ottengo più miglioramenti con sse? O, come ho letto in un articolo (era relativo ad un utente Ubuntu è per quello che volevo conferme), è meglio settare "both" (oppure "387,sse" o ancora "sse,387") lasciando decidere al compilatore/al codice (non ho ancora bene capito la questione) quale fpu usare?

 

Facendo un altro paio di ricerche credo di aver trovato una risposta valida in questo articolo, ma la questione rimane aperta: ho letto da diverse fonti che l'opzione -mfpmath=both e varianti sia sperimentale e instabile, viene quindi consigliato di non usarlo. Gli articoli/post erano, però, abbastanza vecchiotti e non indicavano la versione di GCC a cui si riferivano quello che mi chiedo: è ancora così? O ci sono comunque dei campi in cui può essere utilizzata?

----------

## ciro64

Per vedere tutte le flags abilitate, prova con questo comando in terminale; avrai un resoconto di tutte le flags abilitate o meno. In precedenza anch'io specificavo in make.conf -mfpmath=sse.

```

echo 'int main(){return 0;}' > test.c && gcc -v -Q -march=native -O2 test.c -o test && rm test.c test

```

Per vedere la variazione puoi come prima cosa lanciare il comando così come l'ho scritto, mentre in un altro terminale lo lanci con l'aggiunta prima o dopo -O2 l'opzione -mfpmath=sse

Quindi confrontare i 2 outputs.

Perdonami se ti sto dando un consiglio probabilmente macchinoso, ma non sono un informatico..... diciamo che faccio un po' l'autodidatta e che per me Gentoo e Funtoo sono il top (Adoro il lavoro che ha svolto Daniel Robbins per creare queste metadistribuzioni).

Sicuramente in questo forum potrai trovare risposte molto più valide ed intelligenti rispetto a quanto sia in grado di dirTi io.

Son felice se apprezzi *too .... io ne sono "innamorato" , è un fulmine  :Very Happy:   :Very Happy:   :Very Happy: 

Ciao  :Smile: 

PS: Mentre chiudevo il post, m'è venuto in mente che, leggendo la guida Gentoo l'opzione -fomit-frame-pointer  va bene per i sitemi a 32 bits mentre è sconsigliata per quelli a 64.

Sinceramente non so il perchè... se qualcuno vuol darci "lumi" su questo argomento sarà davvero ottimo  :Smile: 

PS2: Scusa se riprendo nuovamente il post.

Forse alcuni miglioramenti in senso di velocità potresti averlo facendo un'aggiunta alle LDFLAGS.

Ormai è tempo che l' opzione -Wl,--as-needed è attivata di default.

Io aggiungo un altra opzione scrivendo in /etc/portage/make.conf

```

LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu"

```

(che son sempre migliorie dedotte leggendo le varie discussioni nel forum).

Buon tutto  :Smile: 

----------

## loxdegio

Ciao, intanto ti ringrazio una volta ancora per i consigli che mi stai dando e spero che la discussione possa crescere ancora, perché ok i consigli della wiki, ma gentoo senza un'adeguata ottimizzazione che scopo ha?  :Razz: 

In ogni caso ora le mie CFLAGS hanno questo aspetto

```
CFLAGS="-O2 -march=core2 -mtune=core2 -mcx16 -msahf -msse4.1 -mfpmath=sse -pipe"
```

In più ho notato che anche con la compilazione verbosa di gcc non viene nemmeno lontanamente considerata la flag -mfpmath, nemmeno tra le flags mascherate, quindi non ti saprei minimamente dire quale possa essere l'impostazione di default e nemmeno se ce ne sia una. Le uniche più o meno relative alla questione che ho trovato sono:

```
-mfancy-math-387 -mfp-ret-in-387 -mmmx -mno-sse4 -msse -msse2 -msse3 -mssse3
```

da cui deduco che una possibile impostazione di default penda verso la 387 e la necessità di aggiungere a mano la

```
-msse4.1
```

supportata dal mio processore e togliere la

```
-mmmx
```

----------

## ciro64

Dalle Use che metti posso capire che la tua cpu debbaessere un "Penryn" se "core2 duo" oppure "Yorkfiled" se Quad-core.

Secondo me potresti usare semplicemente ma efficaemente un bel:

```

CFLAGS="-march=native -O2 -pipe"

CXXFLAGS="${CFLAGS}"

FFLAGS="${CFLAGS}"

FCFLAGS=${CFLAGS}"

LDFLAGS="$LDFLAGS} -Wl,--hash-styile=gnu"

```

Con -march=native, gcc va già a "pescare" anche le varie SIMD della tu cpu.

Puoi vederle con, per esempio

```

grep "sse\|avx" /proc/cpuinfo 
```

Questo in caso di processori più recenti che hanno anche le AVX

Puoi comunque al limite postare per l'appunto

```

cat /proc/cpuinfo

```

Ci sono comunque varie discussioni nel forum.... dove vengono menzionate flags "esotiche". il fatto è poi il discorso relativo alla stabilità........

Per esempioo se aggiungi -ffast-math come flag, vedrai che già portage ti "sgrida" (o meglio dice attento che quest'impostazione può finire nel malfunzionamente sia della comiplazione che del funzionamento proprio)

So che c'è chi la usa.... asserenndo di non riscontrar problemi....... anche nei sistemi tipo Freebsd vien proposta.

Personalmente nol la uso. 

Comunque se ricerchi bene sul forum trovi più di un discussione in merito.

Ciao  :Smile: 

----------

## djinnZ

@ciro64

Uno dei problemi di -march=native è che puoi trovarti con flag ridondanti o deleterie. la risposta del gcc a questa flag è abilitare contemporaneamente tutte le flag di ottimizzazione supportate anche se ridondanti od in semicontrasto.

L'esempio tipico sono mmx ed sse. Stando alle specifiche delle cpu attuali le istruzioni mmx sono eseguite più lentamente rispetto alle sse ma con native ti ritroverai il codice mmx con incremento delle dimensioni dell'eseguibile per il duplice supporto o con degrado di prestazioni perchè supportate solo le prime.

Altro e più serio problema è che potresti trovarti con le flag di ottimizzazione alterate ad ogni aggiornamento del compilatore.

La mia esperienza personale mi ha insegnato che in un modo o nell'altro se la toolchain non è compilata esattamente con le stelle cflags qualche rogna minore (crash incomprensibili e similia) ti capita.

Vedi quali cflags vengono attivate da -march native e ti regoli di conseguenza leggendo sul manulae del gcc cosa implicano, rimuovendo quello che trovi inutile.

Non mi ricordo quale pacchetto mi si incasinava perchè nelle use avevo -mmx (quindi il supporto assembly dedicato era omesso) ma il complilatore agiva ottimizzando anche per il codice mmx (mi pare fosse vlc).

In più, se hai più macchine, rischi di non poter capire eventuali pacchetti binari per cosa sono stati compilati.

Di mio evito -march=native e mi affido ad una sommaria pulizia della riga di ottimizzazione che questo produce. Quando aggiorno gcc vado a vedere se è cambiato qualcosa e mi regolo di conseguenza.

Se vedo, come mi è capitato, che hanno rimosso sse4 per gli amd non solo correggo CFLAGS ma vado di emerge -e @world.

Poi ognuno si regola come fa più comodo.

----------

## sabayonino

 :Shocked:   sarà anche una questione di gusti ...

guardate qua (gcc 4.8.2-r2) :

Haswell i7-4770 con supporto alle avx2

Con  -march=native

```
# gcc -c -Q -march=native --help=target | grep enabled

  -m64                              [enabled]

  -m80387                           [enabled]

  -m96bit-long-double               [enabled]

  -mabm                             [enabled]

  -maes                             [enabled]

  -malign-stringops                 [enabled]

  -mavx                             [enabled]

  -mavx2                            [enabled]

  -mbmi                             [enabled]

  -mbmi2                            [enabled]

  -mcx16                            [enabled]

  -mf16c                            [enabled]

  -mfancy-math-387                  [enabled]

  -mfentry                          [enabled]

  -mfma                             [enabled]

  -mfp-ret-in-387                   [enabled]

  -mfsgsbase                        [enabled]

  -mfxsr                            [enabled]

  -mglibc                           [enabled]

  -mhard-float                      [enabled]

  -mhle                             [enabled]

  -mieee-fp                         [enabled]

  -mlong-double-80                  [enabled]

  -mlzcnt                           [enabled]

  -mmovbe                           [enabled]

  -mpclmul                          [enabled]

  -mpopcnt                          [enabled]

  -mpush-args                       [enabled]

  -mrdrnd                           [enabled]

  -mred-zone                        [enabled]

  -mrtm                             [enabled]

  -msahf                            [enabled]

  -msse                             [enabled]

  -msse2                            [enabled]

  -msse3                            [enabled]

  -msse4                            [enabled]

  -msse4.1                          [enabled]

  -msse4.2                          [enabled]

  -mssse3                           [enabled]

  -mstackrealign                    [enabled]

  -mtls-direct-seg-refs             [enabled]

  -mxsave                           [enabled]

  -mxsaveopt                        [enabled]

```

con -march=core-avx2

```
gcc -c -Q -march=core-avx2 --help=target | grep enabled

  -m64                              [enabled]

  -m80387                           [enabled]

  -m96bit-long-double               [enabled]

  -malign-stringops                 [enabled]

  -mfancy-math-387                  [enabled]

  -mfentry                          [enabled]

  -mfp-ret-in-387                   [enabled]

  -mglibc                           [enabled]

  -mhard-float                      [enabled]

  -mieee-fp                         [enabled]

  -mlong-double-80                  [enabled]

  -mno-sse4                         [enabled]

  -mpush-args                       [enabled]

  -mred-zone                        [enabled]

  -mstackrealign                    [enabled]

  -mtls-direct-seg-refs             [enabled]

```

"native" ha abilitato tutte le istruzioni ssse (e guardando le varie descrizioni , per lo più sono a supporto multimediale) e qualcun'altra

mentre "core-avx2"  è stato molto più "rilassato"

core-avx2 è l'-march riconosciuto per questo tipo di processore se passato il parametro "native" al compilatore

```
# gcc -march=native -E -v - </dev/null 2>&1 | grep cc1

 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/cc1 -E -quiet -v - -march=core-avx2 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=core-avx2 -fstack-protector
```

 :Shocked: 

esigenze a parte ... a chi dare ragione ?

meglio una "pompatina" al codice con i pro e contro come il primo caso ... o stare rilassati ed accontentarsi di poco ?

per chi utilizza il pc prevalentemente per multimedia,editing etc , direi che conviene più la prima   :Rolling Eyes: 

Source :

https://wiki.gentoo.org/wiki/Safe_CFLAGS

https://wiki.gentoo.org/wiki/GCC_optimization

http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options

[edit] per curiosità sto installando il gcc-4.9 .

ho visto che hanno cambiato anche :

 *Quote:*   

> * Optimizing for other Intel microarchitectures have been renamed to -march=nehalem, westmere, sandybridge, ivybridge, haswell, bonnell. 
> 
> * -mtune=intel can now be used to generate code running well on the most current Intel processors, which are Haswell and Silvermont for GCC 4.9. 

 

----------

## Realnot

-march=native tutta la vita  :Very Happy: 

----------

## loxdegio

 *sabayonino wrote:*   

>   sarà anche una questione di gusti ...
> 
> guardate qua (gcc 4.8.2-r2) :
> 
> [ ... ]
> ...

 

Vedo che usi allegramente le ultime versioni di gcc anche se ancora sotto le keywords ~*, dici che per un uso desktop abbastanza rilassato sono già stabili? Se sì cosa conviene usare? Le versioni su overlay o quelle presenti nel portage? 

Grazie comunque per i consigli applicati al tuo processore  :Very Happy: 

Devo dire in ogni caso che ci sto cominciando a capire qualcosa in più dopo aver aperto questa discussione. Non si smette mai di imparare di certo  :Smile: , ma direi che qualcosa di più rispetto a prima la so  :Razz: 

[edit] Già che ci sono... Ho letto da qualche parte che l'ottimizzazione -march=core2 è meglio di -march=atom sui processori Atom (appunto). Quanto è vera questa cosa secondo voi? Porterebbe miglioramenti o è un'affermazione che lascia un po' il tempo che trova?

----------

## sabayonino

 *loxdegio wrote:*   

>  *sabayonino wrote:*     sarà anche una questione di gusti ...
> 
> guardate qua (gcc 4.8.2-r2) :
> 
> [ ... ]
> ...

 

ho settato keyword in "amd64" nel make.conf , e dipendenze permettendo , quasi tutto gira su questa "chiave" , tranne qualche applicazione e relative dipendnenze

attualmente rimosso il 4.8.2 ed installato il 4.9

```
# gcc-config -l

 [1] x86_64-pc-linux-gnu-4.7.3

 [2] x86_64-pc-linux-gnu-4.9.0 *

```

 e ricompilato tutto .e per l'uso che ne faccio io , il pc (principale , con Kde 4.12.x , xbmc ,vlc,amarok,thundebird,firefox,libreoffice ed altro) al momento non dà segni di sbalamento   :Rolling Eyes: 

gli altri pc hanno solo lo tsretto necessario per far girare Boinc   :Twisted Evil: 

di norma quando installo un compilatore e passo di configurazione  eseguo questi passi (ognuno ha il suo metodo ...)

Boostrap e riemersione di tutto :

```
# bash /usr/portage/scripts/bootstrap.sh
```

controllo CFLAGS e lo imposto 

(attualmente CFLAGS="-O2 -march=native -mfpmath=sse -pipe" , anche se da man di gcc è indicato chiaramente che mfpmath è impostato in sse di default  nei sistemi a 64bit ma a me risultava sempre 387   :Confused:   )

 *Gcc Options wrote:*   

> For the i386 compiler, you must use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default. 
> 
> https://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options

 

ad esempio , un pacchetto a caso :

```
* app-backup/rsnapshot-1.3.1-r2

   Install date: Sat May 24 18:26:33 2014

   USE=""

   CFLAGS="-O2 -march=native -mfpmath=sse -pipe"

```

presumo che se non indicavo esplicitamente mfpmath=sse , il pachetto sarebbe stato compilato con il valore di default (387) specificato da "native" et simili.

poi se ci saranno delle migliorie o regressioni per i pacchetti compilati con questa "ottimizzazione" lo vedrò strada facendo.

per quanto riguarda la "rindondanza" accennata da djdiniz  è chiaramente indicata anche nel Wiki Gentoo - GCC optimization e links annessi

Tornano allo switch di compilatore , una volta effettuato bootstrap , smanetto eventualemnte con le flags di compilazione e poi giù di 

```
# emerge -e --keep-going @{system,world}
```

 il tempo necessario a ricompilare tutto (dipende oltre dal pc anche da quanta roba hai installato ; poco più di 4 ore per quello indicato sopra)

alcune CFLAGS possono anche essere disabilitate (o abilitate) a livello di ebuild per scelta dei developers o dei manteiners dell'ebuild ; scelta tecnica alla quale non sto ad  indagare ...

ad esempio firefox :

```
# Finalize and report settings

   mozconfig_final

   if [[ $(gcc-major-version) -lt 4 ]]; then

      append-cxxflags -fno-stack-protector

   elif [[ $(gcc-major-version) -gt 4 || $(gcc-minor-version) -gt 3 ]]; then

      if use amd64 || use x86; then

         append-flags -mno-avx

      fi

   fi
```

```
# genlop -i firefox

[...]

* www-client/firefox-29.0.1

   Install date: Fri May 23 20:39:44 2014

   USE="gstreamer -bindist -hardened -+jit -+minimal -pgo -pulseaudio -selinux -system-cairo -system-icu -system-jpeg -system-sqlite -test"

   CFLAGS="-march=native -pipe -mno-avx"

```

quando il compilatore passa ON l'istruzione "avx"

```
# gcc -c -Q -march=native --help=target | grep avx

  -mavx                                 [enabled]

  -mavx2                                [enabled]

[...]

```

Posso solo dire che CFLAGS potrebbe essere un puro gioco o esercizio , con i processori moderni si fa fatica a vedere miglioramenti eclatanti (tranne eventuali disastri ) , certo che le ottimizzazioni per alcune applicazioni hanno dei vantaggi.

Ad esempio , girando Boinc (si ne sono un utilizzatore    :Razz:   ) , c'è un progetto che ha ottimizzato le proprie applicazioni per i processori che supportano le istruzioni AVX , la stessa applicazione con il solo supporto alle sse3 (quella di default) impiegava circa 3-4 ore ad essere eseguita , mentre la stessa applicazione ottimizzata con le avx impiegava almeno la metà del tempo delle sse3 sempre sullo stesso Pc

Ovviamente l'applicazione è stata ottimizzata dai devs che hanno fornito l'applicazione.

(per i curiosi : progetto Asteroids@Home)

[edit] se possessore di CPU intel potrebbe interessare anche https://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints

----------

## ciro64

Grazie del consiglio djinnZ  :Smile: 

----------

## djinnZ

-help=target non funziona bene. Mi sono scocciato di ripeterlo.

L'unica cosa da fare è prendere l'output di gcc -march=native e controllare ad ogni cambio di gcc per vedere se non è il caso di ricompilare indipendentemente daòlla strada che si è scelta.

-march=native non lo si rimpiazza con -march=cpu. è da imbecilli, lo si rimpiazza con una serie di flag specifiche a cominciare da --param *-cache-line-size (se,mbra una stupidaggine ma per quel che ho letto influenza direttamente la gestione delle variabili register elemento critico per quelle parti di codice che prevedono contatori e semafori, è dai tempi del K&R che si insiste sulla necessità di non ricorrervi troppo senza per questo evitare di usarle).

Anche -march=cpu in realtà non fa altro che attivare -mtune=cpu e -mcpu=cpu ed una serie di flag specifiche, Diverse flag (come anche -O*) non sono altro che dei raggruppamenti per evitare linee di comando chilometriche, e ci si affida al manuale.

Manuale alla mano vedi cosa implicano e poi regolarti per creare minimi comuni denominatori che non siano solo compilare con -march=i686 (approccio alla RH od alla MS) su hardware non omogeneo. Un esempio potrebbe essere lottimizzazione per codice x64 intel o non intel, se scegli la via intel su amd non funzionerà se scegli la via amd funzionerà su entrambi ma sugli intel perderai qualcosa in prestazioni (se fai rendering o number cruncing ha un peso, se ci navighi ... è da psicopatici applicarsi IMHO).

Se hai una sola macchina potresti poter presente l'evenienza di poter migrare direttamente il sistema da intel ad amd o viceversa o solo voler avere maggior controllo.

La presenza di assembly inline è l'elemento più critico da tener presente.

----------

## sabayonino

@djdiniz

tu come ti muoveresti in questa situazione con passando dal 4.7.3 al 4.9 :

gcc 4.7.3

```
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 -E -quiet -v - -march=corei7-avx -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=generic

```

gcc 4.9.0

```
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1 -E -quiet -v -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -fstack-protector-strong

```

Stesso processore.

Si nota chiaramente un aumento delle flags del compilatore per la cpu in uso (molte disabilitate)...

Inoltre come hai ben detto per evitare luunghe stringhe di parametri  voci quali "core2" "pentium-bello" "pentium-brutto" etc , non sono altro che degli "alias" che richiamano specifiche di quella tipologia di processore.

----------

## ciro64

Spero di non sovrappormi nella discussione: vedendo il link di Sabayonino che porta al sito Intel, mi vien da chiedere: "che succede se io impongo -m32 o -m64" ?

Considerando che ho un sistema 64 bits multilib.

Significa che se imponessi "-m64" arriverei ad un sistema simile al profilo "nomultilib" di Gentoo ?

Grazie per qualsiasi chiarificazione.

----------

## sabayonino

 *ciro64 wrote:*   

> Spero di non sovrappormi nella discussione: vedendo il link di Sabayonino che porta al sito Intel, mi vien da chiedere: "che succede se io impongo -m32 o -m64" ?
> 
> Considerando che ho un sistema 64 bits multilib.
> 
> Significa che se imponessi "-m64" arriverei ad un sistema simile al profilo "nomultilib" di Gentoo ?
> ...

 

dal man di gcc

```
These ‘-m’ switches are supported in addition to the above on x86-64 processors in 64-bit environments.

-m32

-m64

-mx32

-m16

    Generate code for a 16-bit, 32-bit or 64-bit environment. The -m32 option sets int, long, and pointer types to 32 bits, and generates code that runs on any i386 system.

    The -m64 option sets int to 32 bits and long and pointer types to 64 bits, and generates code for the x86-64 architecture. For Darwin only the -m64 option also turns off the -fno-pic and -mdynamic-no-pic options.

    The -mx32 option sets int, long, and pointer types to 32 bits, and generates code for the x86-64 architecture.

    The -m16 option is the same as -m32, except for that it outputs the .code16gcc assembly directive at the beginning of the assembly output so that the binary can run in 16-bit mode. 
```

----------

## ciro64

mmhh... son sempre il solito stupido: forse mi bastava leggere bene il responso delle mie flags attive:

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

options passed:  -v test.c -march=core-avx2 -mcx16 -msahf -mmovbe -maes

 -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2

 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c

 -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt

 --param l1-cache-size=32 --param l1-cache-line-size=64

 --param l2-cache-size=8192 -mtune=core-avx2 -O2

options enabled:  -faggressive-loop-optimizations -falign-labels

 -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg

 -fcaller-saves -fcombine-stack-adjustments -fcommon -fcompare-elim

 -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdefer-pop

 -fdelete-null-pointer-checks -fdevirtualize -fdwarf2-cfi-asm

 -fearly-inlining -feliminate-unused-debug-types -fexpensive-optimizations

 -fforward-propagate -ffunction-cse -fgcse -fgcse-lm -fgnu-runtime

 -fguess-branch-probability -fhoist-adjacent-loads -fident -fif-conversion

 -fif-conversion2 -findirect-inlining -finline -finline-atomics

 -finline-functions-called-once -finline-small-functions -fipa-cp

 -fipa-profile -fipa-pure-const -fipa-reference -fipa-sra

 -fira-hoist-pressure -fira-share-save-slots -fira-share-spill-slots

 -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno

 -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants

 -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls

 -foptimize-strlen -fpartial-inlining -fpeephole -fpeephole2

 -fprefetch-loop-arrays -free -freg-struct-return -fregmove

 -freorder-blocks -freorder-functions -frerun-cse-after-loop

 -fsched-critical-path-heuristic -fsched-dep-count-heuristic

 -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic

 -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic

 -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column -fshrink-wrap

 -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types

 -fstrict-aliasing -fstrict-overflow -fstrict-volatile-bitfields

 -fsync-libcalls -fthread-jumps -ftoplevel-reorder -ftrapping-math

 -ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp -ftree-ch

 -ftree-coalesce-vars -ftree-copy-prop -ftree-copyrename -ftree-cselim

 -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre

 -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon

 -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre

 -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink

 -ftree-slp-vectorize -ftree-slsr -ftree-sra -ftree-switch-conversion

 -ftree-tail-merge -ftree-ter -ftree-vect-loop-version -ftree-vrp

 -funit-at-a-time -funwind-tables -fvar-tracking -fvar-tracking-assignments

 -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387 -mabm

 -maccumulate-outgoing-args -maes -malign-stringops -mavx -mavx2 -mbmi

 -mbmi2 -mcx16 -mf16c -mfancy-math-387 -mfma -mfp-ret-in-387 -mfsgsbase

 -mfxsr -mglibc -mhle -mieee-fp -mlong-double-80 -mlzcnt -mmmx -mmovbe

 -mpclmul -mpopcnt -mpush-args -mrdrnd -mred-zone -mrtm -msahf -msse -msse2

 -msse3 -msse4 -msse4.1 -msse4.2 -mssse3 -mtls-direct-seg-refs -mvzeroupper

 -mxsave -mxsaveopt

Accidenti... c'è proprio da diventar matti qui -m64 è abilitato di default; quindi boh non riesco a capire bene cosa vogliano indicare li sul sito di Intel  :Rolling Eyes:  beh se mi gira stasera proverò a chattare con qualche esperto di Intel.... non sarebbe la I volta  :Razz: 

Ciao e Grazie  :Smile: 

----------

## djinnZ

 *sabayonino wrote:*   

>  *gcc 4.7.3 wrote:*   /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 -E -quiet -v - -march=corei7-avx -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=generic  *gcc 4.9.0 wrote:*   /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1 -E -quiet -v -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -fstack-protector-strong 
> 
> Si nota chiaramente un aumento delle flags del compilatore per la cpu in uso (molte disabilitate)...

 In che senso disabilitate? facendo la verifica con --help=target almeno fino al 4.6 non mi riportava -m64 con -march=amdqualcosa abilitate ma -msahf (che è valida solo su codice a 64 bit) lo era o qualcosa del genere.

Avevo aperto un thread sull'argomento ma come al solito appena chiedo qualcosa di meno banale si defilano tutti.

Se hai singola macchina ed hai scelto -march=native te ne freghi altamente (non ho detto che è sbagliato, solo che sarebbe il caso di porsi un minimo il problema, nel mio caso farei prima a mettere -march=native -mno-mmx -mno-no3dnow ma faccio una via di mezzo tra i7 e amd64) ma, in base al pastrocchio delle differenze, sarebbe una buona idea lanciare un emerge -e @system. O comunque andare a ricompilare quei pochi pacchetti del genere vlc, librerie di interfaccia all'hardware e simili che supportano ampiamente assembly inline.

Questo era il senso della mia considerazione. Non sarà una grande differenza ma in termini di prestazioni e stabilità dovresti guadagnarci.

Evidente che la cpu prima non era supportata ed adesso lo è.

Purtroppo non vedo molto da togliere finchè non è chiaro se le sse sono implicite a -march o meno. Ad ora ho trovato solo risposte contraddittorie.

Sono a spasso quindi non posso verificare direttamente ma per semplificare parto da un gcc -Ev -march=-march=haswell per vedere cosa implica di default. E le flag in questione le scarto. le -mno-vattelappesca le riporto ed in genere aggiungo anche un -no-mmx visto che le sse sono più veloci a prescindere sulle cpu più recenti (se poi usi qualche vecchia bestialità che ha codice mmx inline potresti avere problemi, come per la questione della -mfpmath=sse).

Per inciso -mmmx (ed ovviamente USE="-mmx") è implicita a -march stando al manuale.

Se non pensi di averne bisogno (nel mio caso su hardened è veramente inutile, il debugging non è che sia tanto attuabile) puoi pensare ad aggiungere -g0 e disabilitare il supporto al debugging simbolico e riduci la dimensione degli eseguibili.

----------

## sabayonino

@djdiniz

si infatti l'haswell all'epoca non era completamente supportato dal gcc-4.7 e veniva riconosciuto (o meglio i devs di gcc lo hanno inserito) nella categoria "i7-avx". 

ora ci sono più flag e come ho notato , parecchie di quelle indicate sono "-mno-*"

ora  con i gcc di ultima generazione e le nuove CPU hanno pensato di dividere un pò il "parco macchine" per così dire...

se per ogni cpu che esce ci mettono 5-6 nuove flag credo che sia molto più comodo creare questi "alias" altrimenti si diventa scemi  a sceglierle.

come già detto quando passo ad un nuovo compilatore , ricompilo tutto partendo dal bootstrap (anche se dopo con un -e @system mi ricompila gli stessi pacchetti ... ma tanto  utilizzo ccache e non ci perdo troppo tempo pure compilando in ram)

per quanto riguarda -g0 tempo fa avevo avuto problemi con molti pacchetti (ora non ricordo quali) , sta di fatto che l'ho tolto.

giusto per curiosità avevo provato anche le "mirabolanti e mitologiche" features  indicate in "graphite". (con tanto di flag abilitata in gcc (era d'obbligo)

```
-floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block  -ftree-vectorize "
```

ma con KDE sono stati più dolori che gioie.

(vivo bene anche senza , ma la curiosità spesso va soddisfatta)

con "-mfpmath-fast"  ha dato problemi con sqlite ed un paio di pacchettini...

 :Shocked:   poi va a finire che ci si accontenta del "tradizionale standard" ...

[edit] per gli amanti dei particolari : (2002) Analisi di

MMX e SSE e 3DNow!

----------

## sabayonino

 *djinnZ wrote:*   

> 
> 
> Per inciso -mmmx (ed ovviamente USE="-mmx") è implicita a -march stando al manuale.

 

riguardo a questo mi sono messo a smanettare , inserendo tutte le flag in CFLAGS al posto di -march=native impostando -mno-mmx (di default abilitatata e mantenendo -mtune=haswell) e reimpostando "-Og" (dopo moolto tempo)

e per quanto riguarda la compilazione di gcc-4.7 e 4.9 ne esce questo :

CFLAGS

 *Quote:*   

> CFLAGS="-Og  -mfpmath=sse -mno-mmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -fstack-protector-strong -pipe"
> 
> 

 

genlop riporta questo :

 *Quote:*   

> * sys-devel/gcc-4.7.3-r1
> 
>    Install date: Wed May 28 23:30:03 2014
> 
>    USE=""
> ...

 

come vedi per conto suo  , l'ottimizzazione è passata da "-Og" a "-O2" (sarà impostata direttamente dall'ebuild ? devo controllare...ora non ne ho voglia)

per il 4.7 -mtune se l'è impostato come da "manuale" a "core-avx2". e s'è preso tutte le "-mno-*" .... ma "-mno-mmx" è tornata in "-mmmx" nonostante sia stata dichiarata "-mno-mmx"  in CFLAGS

per il 4.9 : idem con patatine.stesso comportamento.

posso dedurre che il compilatore per sè stesso richiede "mmx" forzatamente.(o sarà colpa di -mtune ?? )

 *Quote:*   

> [edit] Beccato...
> 
> ```
> * strip-flags: CFLAGS: changed '-Og -mno-mmx -mfpmath=sse -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -fstack-protector-strong -pipe' to '-mno-mmx -mno-3dnow -mno-sse4a -mno-sha -mno-lwp -mno-fma4 -mno-xop -mno-tbm -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mtune=haswell -pipe -O2'
> 
> ...

 

per  midnight commander "mno-mmx"  è stato rispettato

 *Quote:*   

> * app-misc/mc-4.8.11
> 
>    Install date: Wed May 28 23:18:43 2014
> 
>    USE="gpm nls spell X -+edit -mclib -samba -sftp -+slang -test -+xdg"
> ...

 

L'editor nano

 *Quote:*   

> * app-editors/nano-2.3.2
> 
>    Install date: Wed May 28 23:52:39 2014
> 
>    USE="ncurses nls unicode -debug -justify -+magic -minimal -slang -spell"
> ...

 

altri pacchetti sono stati compilati con "-mno-mmx" come richiesto , altri no.

Quindi presumo che a livello di ebuild i Devs gentoo abbiano forzato alcuni parametri (come per firefox ed altri) per motivi a cui non mi interesso.mi affido ai devs...   :Twisted Evil: 

[edit] nell'altro PC (stesso hardware) , ma con applicazioni multimediali e server-grafico , impostando "-mno-mmx" in CFLAGS e "-mmx" nelle USE globali (con ovvia ricompilatina con il cambio USE)  ,  alcuni pacchetti (transcode,libvpx ed un altro che non ricordo) forzavano l'utilizzo di USE="mmx" . (tramite package.use).

----------

## djinnZ

In alcuni makefile non solo negli ebuild -mmmx viene reimpostato forzatamente perchè il codice è ottimizzato per mmx, stessa cosa per le ottimizzazioni -O. In altri potrebbero essersene dimenticati, per questo non è raccomandato giocare troppo con le cflags, ma nemmeno sconsigliato, si deve procedere con cautela.

Comunque se non mi sbaglio è -mtune che impone alcune ottimizzazioni minime. Solo mi domando perchè non hanno semplificato la vita a tutti supportando direttamente le cpu per modello.

Il punto che sottolineavo. tra l'altro, è che non serve ricompilare tutto ad ogni cambio di versione del gcc, è utile farlo solo in un caso come questo, perchè le impostazioni sono cambiate radicalmente.

Se poniamo caso, volessi mantenere la vecchia toolchain (per esempio hai un qualche pacchetto binario che non può farne a meno) ma, sullo stesso gcc 4.7.3 volessi impostare CFLAGS="-march=corei7-avx -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7-avx -fstack-protector-strong", che dovrebbe comunque essere più rispondente alla cpu dell'ottimizzazione generica inizale, dovresti comunque ricompilare tutto IMHO.

Se la riga dovesse mantenersi uguale invece mi pare solo un ulteriore contributo all'inquinamento di questo sfortunato pianeta. A meno che non siano riportati problemi specifici al rilascio (ma l'ultima seria è stata al passaggio dalla libc5 alla libc6).

----------

## sabayonino

 *djinnZ wrote:*   

> on mi sbaglio è -mtune che impone alcune ottimizzazioni minime. Solo mi domando perchè non hanno semplificato la vita a tutti supportando direttamente le cpu per modello.

 

tipo un raggruppamento come questo  ??

----------

## djinnZ

Si, ma più accurato. realmente modello per modello, di modo da rendere inutile stà marea di parametri.

----------

## sabayonino

un dubbio mi sorge ; 

```
CFLAGS="-Og -march=haswell -mfpmath=sse -mno-mmx -pipe"
```

"haswell" implica -mmmx ma poi viene passato -mno-mmx

quest'ultimo dovrebbe essere preso in considerazione annullando quello passato di default in haswell.

qui l'editor "nano"  passando tutti i parametri singolarmente

 *Quote:*   

> USE="ncurses nls spell unicode -debug -justify -+magic -minimal -slang"
> 
>    CFLAGS="-Og -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -fstack-protector-strong -mfpmath=sse -mno-mmx -pipe"

 

Qui sempre "nano" passando "-march=haswell" (che implica -mmmx) e poi imponendo -mno-mmx

 *Quote:*   

> USE="ncurses nls spell unicode -debug -justify -+magic -minimal -slang"
> 
>    CFLAGS="-Og -march=haswell -mfpmath=sse -mno-mmx -pipe"
> 
> 

 

in questo caso "mmx" verra effettivamente disabilitato ?

 :Question: 

----------

## ciro64

Perdonate la mia immenza ignoranza..... però penso se "haswell" (che ho anch'io, il 4771) di default (intendo usando il -march=native") permette l'uso delle mmx, perchè toglierle ?

Non so come funzionano i processi produttivi delle cpu..... però per esempio AMD con "Bulldozer" , "Vishera" ecc ha tolto le 3dnow (purtroppo o meno le SIMD di AMD on han dettato legge ma quelle di Intel si)

Quindi se un set di istruzioni è solo una ridondanza.... penso gli stessi produttori eliminerebbero queste istruzioni !inutili in quanto sorpassate ( il più contiene il meno), a meno di permettere forse maggior compatibilità con softwares + vecchi.......?

Mah non credo.... se attivo p.e. sse2 è chiaro che mmx debbano essere specificate; non "eliminate".

Però è solo un pensiero anzi una domanda visto che sono un po' ignorantotto in materia.

Ciao.

----------

## sabayonino

 *ciro64 wrote:*   

> 
> 
> Mah non credo.... se attivo p.e. sse2 è chiaro che mmx debbano essere specificate; non "eliminate".
> 
> 

 è un dubbio Amletico che si pongono tutti ultimamente   :Laughing: 

dovremmo sequestrare un capo tecnico della Intel e porgli 'sta domanda   :Razz: 

----------

## ciro64

Carissimo Sabayonino..... ho provato anche ad effettuare chat con il supporto di Intel, ma chi ho incontrato non sapeva nemmeno cosa fosse gcc  :Surprised: 

Tutto ciò mi spaventa un po'  :Rolling Eyes: 

In Intel ci sono anche i forums con diverse discussioni; però possibile che su 3 prove che ho fatto nessuno abbia saputo darmi una risposta corretta al riguardo ?

Per esempio mi ero lasciato "ingolosire" dall' opzione -Ofast (che da quel che ho capito abiliterebbe -O3 e -ffast-math"

Un tempo quando provavo ad usare l'opzione -ffast-math portage o gcc stesso mi estrapolava degli "warnings" scritti in rosso dicendo che sostanzialmente non è garantita ne la riuscita della compilazione del sorgente ne, eventualmente, del sup corretto funzionamento (dell'ebuild per chi usa *too).

Invece, volendo un po' ripercorrere il cammino (ma tanto non sono sufficientemente intelligente per capire tante cose) di Daniel Robbins (che è il mio "idolo informatico" per aver inventato sifatti gioielli) ho provato anche a "bazzicare i sistemi *BSD. E, stranamente in vari forums vedevo che questa -ffast-math la usassero quasi come bersi un bicchiere d'acqua. Effettivamente la cosa è molto complessa....... e purtroppo non sono sufficientemente intelligente per capire a fondo molte cose che possono però essere fondamentali.

Per questo chiedo spesso un aiuto "con fede" considerando che chi (§Grazie) mi risponde per aiutarmi come una sorta di "maestro", dato che non sono un informatico ma un autodidatta su queste cose..... solo che mi affascinano in una maniera indescrivibile.

W *too io dico...... non posso che portar sul palmo della mia mano destra tutte le invezioni del geniale inventore di Gentoo ....

Ma.... se sto sbagliando, se sto andando fuori di testa, se sto commettendo erori anche nello scrivere posts, riprendetemi.....

Sono solo una persona che desidera affinare le proprie conoscenze riguardo questo sistema che per me è il top (e ne ho provati tanti........)

Per finire e non volendo dilungarmi troppo...... vi chiedo di perdonarmi se scrivo magari cose errate..... ma desidero davvero col cuore di arricchirmi riguardo questo sistema che come scrivo nella mia firma digitale "....è il più eclettico e geniale del pianet......."

Vi auguro un Super Buon tutto  :Smile: 

Ciao:)

----------

## sabayonino

 :Shocked:   più che il forum di Intel , creddo che dovresti agganciarti su quello di GCC/FSF https://gcc.gnu.org/

In giro non esiste solo GCC , intel ha un suo compilatore (ed è presente pure in portage,sys-devel/icc mi sembra) , poi c'è CLAM/LLVM annch'esso in portage

e chissà quanti altri   :Rolling Eyes: 

qui siamo un pò tutti autodidatta   :Very Happy:   ... le esperienze altrui vengono assimilate nel bene e nel male   :Twisted Evil: 

----------

## ciro64

Mah.... anche se un po' vecchiotta" come discussione ..... chissà cosa deciderà "la massa"  :Very Happy: 

http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1

io spero in openRC + GCC, il resto lo lascerei ad *BSD.... coi loro problemi di licenza.

Ciao Grande, sei un maestro per me !!!

----------

## djinnZ

Il problema con mmx e 3dnow è che pur essendo vecchie e di fatto più lente nell'esecuzione rispetto alle sse sono ancora direttamente supportate in alcuni pacchetti. Anche se abiliti sse e disabiliti mmx il codice è sempre e solo per mmx.

Disabilitarle può essere un modo per lasciarle alle spalle, non specificandole comunque vengono riabilitate, sono diversi i makefile che ridefiniscono le opzioni del compilatore.

Quanto alle declamazioni sacerdotali sull'utilità di --fast-math od il divieto di usarla... resta sempre la solita religione dell'omologazione cui vorrebbero costringerci.

Anche la stabilità è un concetto relativo. Una cosa è un server che deve stare acceso 24/24 un'altra il pc che usi per andare a consultare la posta e poi lo lasci spento l'intera giornata.

Il primo non deve bloccarsi, il secondo ... ti interessa che si avvii nel minor tempo possibile.

Sacrifichi la stabilità a vantaggio delle prestazioni se non ti comporta problemi che il pc vada in crash.

Non esiste una soluzione "giusta" eseiste solo un modo giusto di affrontare i problemi ed alla fine conduce sempre a soluzioni differenti.

Scusa se non posso seguirti ma il mio portatile mi ha lasciato e sarò ancora latitante per un bel pò.

----------

## ciro64

Sopero vivamente che tu possa arrivafe ad un'ottima soluzione  :Smile: 

Ciao  :Smile: 

----------

## loxdegio

Salve a tutti riprendo questo topic per completare con le ultime informazioni che mi sono state fornite  :Wink: 

In quest'altro topic mi è stato consigliato di aggiungere -Wl,--sort-common alle LDFLAGS in modo da produrre dei link ancora più ottimizzati. In questo modo le LDFLAGS perfette (ripeto: per le informazioni da me raccolte finora) sarebbero

```
LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu -Wl,--sort-common"
```

Continuo a sperare che questo topic possa servire a chiunque si avvicini a Gentoo e in generale al mondo della compilazione(/programmazione)  :Very Happy: 

EDIT: aggiungerei anche che per chi, come me, possiede ancora un "vetusto" netbook con Intel Atom incorporato, sono cambiate alcune cose a partire dalle flage -march e -mtune che ora presentano il valore bonnell: quindi atom risulta deprecato.

----------

## ciro64

Queste fan già parte delle LDFLAGS di default:

```

emerge --info|grep LDFL

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

```

Io ho invece aggiunto "-Wl,--hash-style=gnu" ma non sovrascrivendo ma implementandola:

LDFAGS="${LDFLAGS} -Wl,--hash-style=gnu". 

Ciao  :Smile: 

----------

## sabayonino

 *loxdegio wrote:*   

> 
> 
> EDIT: aggiungerei anche che per chi, come me, possiede ancora un "vetusto" netbook con Intel Atom incorporato, sono cambiate alcune cose a partire dalle flage -march e -mtune che ora presentano il valore bonnell: quindi atom risulta deprecato.

 

per quale compilatore ? tutti o dal 4.9 ???

per il 4.9 suppongo :

```
Optimizing for other Intel microarchitectures have been renamed to -march=nehalem, westmere, sandybridge, ivybridge, haswell, bonnell. 
```

IA-32/x86-64

http://gcc.gnu.org/gcc-4.9/changes.html

https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%29

a ritroso non noto inserimenti di questo genere.  :Wink:  (o patch)

----------

## loxdegio

 *sabayonino wrote:*   

>  *loxdegio wrote:*   
> 
> EDIT: aggiungerei anche che per chi, come me, possiede ancora un "vetusto" netbook con Intel Atom incorporato, sono cambiate alcune cose a partire dalle flage -march e -mtune che ora presentano il valore bonnell: quindi atom risulta deprecato. 
> 
> per quale compilatore ? tutti o dal 4.9 ???

 

Chiedo venia pensavo di averlo scritto  :Razz:  Comunque sì dalla 4.9  :Very Happy: 

----------

## ciro64

mmm vedo che c'è ancora qualche idiosincrasico al "-march=native" .......  :Rolling Eyes: 

----------

## ago

 *ciro64 wrote:*   

> Queste fan già parte delle LDFLAGS di default:
> 
> ```
> 
> emerge --info|grep LDFL
> ...

 

queste NON sono le LDFLAGS di default.

Il default è:

```
-Wl,-O1 -Wl,--as-needed
```

----------

## sabayonino

sbaglio o hanno aggiornato questa pagina :

http://wiki.gentoo.org/wiki/Safe_CFLAGS#Find_cpu-specific_options

Find cpu-specific options

 :Shocked: 

----------

## source-based

Si devono averla aggiornata perchè qualche giorno fa,non c'erano i suggerimenti per i vari processori,peccato che il non è contemplato.Puó anche essere giusto visto che AMD E 2500 è un processore penoso.Con Kali Linux,driver Ati Catalist e pyrit arrivo a 6000 PMK/s con CPU+GPU sotto massimo sforzo.Appena ho tempo vedo qualche FLAG e Gentoo possono aiutarmi.

----------

## loxdegio

Arrivo 6 mesi dopo l'ultimo messaggio per far presente uno scriptino che presumibilmente rende esplicite le CFLAGS fondamentali per il proprio processore passando come parametri delle CFLAGS generiche. Forse così risulta poco comprensibile, ma dopo la dimostrazione pratica tutto verrà svelato.

Scrivendo sul terminale:

```
$ gcc -v -E -x c -g0 -O2 -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | perl -pe 's/ -mno-\S+//g; s/^.* - //g;'
```

mi esce come risultato:

```
-march=bonnell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -mfxsr --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=bonnell -O2 -fstack-protector-strong
```

Che sono le CFLAGS che assegnerebbe GCC passando al compilatore "g0 -O2 -march=native -mtune=native", direi che è un metodo meno generico che "-march=native -O2" e più rapido che doversi studiare tutte le CFLAGS esplicite date dal compilatore ricavate con lo script fornito in uno dei primi post del topic:

```
echo 'int main(){return 0;}' > test.c && gcc -v -Q -march=native -O2 test.c -o test && rm test.c test
```

PS: pare che "-fstack-protector-strong" rallenti un sacco l'esecuzione dei compilati (io l'ho riservato al solo kernel), nonostante aumenti la sicurezza dell'area di memoria di esecuzione. Se volete escludere questa flag nel make.conf potete sostituirla con/aggiungere "-fno-stack-protector"

----------

## ciro64

Interessante, ma il -mtune , una volta specificato il -march è (mi sembra) "ridondante" .... o sbaglio ?

Riguardo il -fstack-protector ..... a livello kernel ci vuole gcc 9.x per poter settare su "strong".

Quale versione di gcc stai "controllando" ?

E ci sono infiniti quesiti su questo argomento ... per esempio un mio amico che usa Gentoo da che è nata ritiene importante il -ftree-vectorize (attivato da -O3 per esempio)

Inoltre il -Ofast (ovvero = -O3 -ffast-math) che però ho provato ma alla fine son ritornato ad un livello meno aggressivo in quanto non solo c'entra un ebuild in particolare ma tuttto il sistema..... per esempio php compilava ma ciò che avevea a che fare con php non andava.... al chè son tornato con flags meno agggressive ovvero il semplice "-march=native -O2 -pipe" che comunque permetti ad avere in molti softwares prestazioni analoghe a precompiled ma in alcuni software si arriva a un 20% faster fino ad un 4x faster  :Razz: )

Prova a vedere questo link

In particolare questo

E questa per me è una Vittoria  :Very Happy:  tutto dipende da come gcc "sceglie" gli algoritmi di compilazione.

E in teoria più avanzano i processori rispetto a "generic" le performances dovranno migliorare ulteriormente nel tempo le performances.

Per esempio ani fa un Pentium 4 contro un Athlon andava in fpu la metà per le x87

Perchè Intel decise che nuovo standard dovessero essere le sse2. (parlo del 2008 più o meno).

Attivare -march=native su uno dei primi AMD 64 non porta a nulla.... le istruzioni coinciderebbero con "generic" ... ma andando avanti le istruzioni con le nuove cpu allora il "divario" si vede eccome in certi casi (chiaramente ove gli algoritmi di gcc "scelgono" di usare SIMD avanzate e inesistenti in "generic"  :Smile: 

Grazie per l'intervento ed eventuali delucidazioni;se ho scrito cose blasfeme correggetemi ..... grazie   :Smile: 

PS: perdonatemi o bannatemi per la mia logorrea..... ultimamete stavo provando PCBSD che usa clang ... non più gcc.

La differenza di reatività non ha bisogno di benchmarcks ... si vede ad occhio. Se volete in c-ray Gentoo is 20% faster in phoronix C-Ray bench.

Ciao a Tutti  :Smile: 

----------

## loxdegio

Allora,.. Sì come al solito mi sono dimenticato di segnare la versione di GCC che dovrebbe essere 4.8+ (la .8 usa di default -fstack-protector-normal e la .9 -fstack-protector-strong, ma ho letto che rallentano un sacco l'esecuzione a causa delle protezioni che attivano sulla memoria e quindi per sistemi desktop è meglio usare -fno-stack-protector tranne sul kernel, mentre è meglio usare lo strong su sistemi server che necessitano di maggiori protezioni). Ovviamente, a meno che il nostro amico non venga dal futuro, la versione 9.x di GCC non esiste ancora essendo arrivati solo alla 4.10  :Razz: 

Quanto ad -O3 è scritto ovunque che usarlo su tutto il sistema non è consigliabile, mentre si invita a selezionare alcune flags specifiche, come -ftree-vectorize ad esempio, tra quelle che verrebbero mascherate e attivate con -O3.

Comunque ti sei concentrato troppo sulle flags specifiche che risultano a me, io ho postato lo scriptino perché mi pare utile se non si sa da dove partire, ma è ovvio che il mio voleva essere un esempio di utilizzo non un'imposizione di quali flags mettere, ognuno è libero di settare quello che gli pare. Ripeto che ho reso noto quel comando bash solo per aiutare gente digiuna di GCC ad avere delle CFLAGS un po' più particolareggiate di "-g0 -O2 -march=native" pur non sapendo nulla dei paramentri da passare al compilatore

----------

## sabayonino

per saperne di più...

```
$ man gcc

[...]

-fstack-protector

    Emit extra code to check for buffer overflows, such as stack smashing attacks. This is done by adding a guard variable to functions with vulnerable objects. This includes functions that call alloca, and functions with buffers larger than 8 bytes. The guards are initialized when a function is entered and then checked when the function exits. If a guard check fails, an error message is printed and the program exits. 

[...]

-ftree-vectorize

    Perform loop vectorization on trees. This flag is enabled by default at -O3

[...]

-O3

Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options. 

[...]

```

----------

## loxdegio

Ecco qui la documentazione relativa allo script/comando bash che ho proposto 4 post sopra: https://wiki.gentoo.org/wiki/Distcc#Using_distcc_with_Portage

----------

## loxdegio

Riporto di nuovo su l'argomento per dare altri spunti reperiti sulla documentazione di Arch Linux (precisamente in /etc/makepkg.conf).

Per chi non vuole impazzire troppo a trovare le flags più adatte

```
CFLAGS="-ffat-lto-objects -ftracer -ftree-vectorize -g0 -march=native -O2 --param=ssp-buffer-size=4 (-pipe)"
```

Per chi si fida degli script:

```
CFLAGS="-ffat-lto-objects -ftracer -ftree-vectorize -g0 $(gcc -v -E -x c -march=native - < /dev/null 2>&1 | grep cc1 | perl -pe 's/ -mno-\S+//g; s/^.* - //g;') -O2 --param=ssp-buffer-size=4 (-pipe)"
```

Per il resto delle flags sembrano utili:

```
CXXFLAGS="${CFLAGS}"

CPPFLAGS="${CFLAGS}"

LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-z -Wl,relro"
```

Devo ancora provarle in pratica, ma volevo farle presente in modo da avere anche altri feedback  :Very Happy: 

Ovviamente per le CFLAGS rimane sempre il classico "-g0 -march=native -O2 (-pipe)" per chi non ama rischiare  :Wink: 

----------

