# native o core2?

## publiosulpicio

Salve a tutti. Ho un processore intel core2 duo, e utilizzo gentoo a 64 bit. Qualcuno di voi ha capito qual è la differenza tra march=native e march=core2 e quale è meglio utilizzare? Qui http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel#Pentium_4 dice di utilizzare core2, ma vorrei capire perché è meglio di native (se c'è effettivamente una differenza). Grazie!

----------

## riverdragon

A quanto ho capito io -march=native dovrebbe far sì che gcc capisca da solo l'architettura (quindi non sia un'ottimizzazione specifica ma sia solo un modo generico per richiamare quella corretta), ma non ci metterei la mano sul fuoco.

----------

## publiosulpicio

 *riverdragon wrote:*   

> A quanto ho capito io -march=native dovrebbe far sì che gcc capisca da solo l'architettura (quindi non sia un'ottimizzazione specifica ma sia solo un modo generico per richiamare quella corretta), ma non ci metterei la mano sul fuoco.

 

Lo penso anch'io. Però vorrei essere sicuro che specificare manualmente l'archittettura giusta sia la cosa migliore, o almeno la stessa cosa.

----------

## Apetrini

A mio parere è meglio usare "native" poiché fa un check sull'architettura e sul tipo di cpu e apporta le varie ottimizzazioni "safe" (sempre sulla specifica cpu)."core2" invece apporta ottimizzazioni per tutta la generica famiglia "Core 2 Duo".

Non è escluso che "native" faccia una selezione a grana piu fine per tipo specifico di cpu (visto che la famiglia Core 2 Duo è ampia).

Se non oggi, in futuro ci potranno essere delle ottimizzazioni di nuovo tipo che saranno abilitate solo con "native", ma non con core2 visto che quest'ultimo deve rispondere all'intera famiglia.

Teoricamente l'uso di "-march=native" rende un attimino piu lento il processo di build per il fatto di dover effettuare il check della cpu all'inizio della compilazione. Dovrebbe trattarsi comunque di cose irrisorie, credo porti via qualche manciata di millisecondi a ebuild.

P.s. sembra che qualcuno si sia già accorto di qualche differenza http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38749 .

----------

## fbcyborg

Ho sentito che march=native è supportato solo da una certa versione di gcc in poi, ma non ricordo quale sia esattamente. Quindi per ora ho ancora core2, per una CPU Intel Q9400 Core2 Quad.

----------

## Apetrini

Da gcc-4.3 c'è l'opzione "native".

E comunque basta provare, se cambi la stringa nel make.conf e lanci a compilare qualsiasi pacchetto che usa gcc, il gcc blocca tutto e riporta un errore se non riconosce il parametro.

----------

## djinnZ

l'unica controindicazione di "native" è in relazione ai pacchetti binari perchè diventa più difficile capire per quale cpu hai compilato. Ma se non usi i pacchetti binari o non compili in un chroot su una macchina dedicata (come facevo io quando avevo ancora l'illusione di poter usare linux liberamente) l'osservazione non ti tange.

----------

## K.a.o.s.

Per chi vuole sapere cosa viene passato con -march=native piuttosto che -march=core2 o -march=quellochevuole:

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

```

Ad esempio, da me, tra le varie cose, con -march=native passa:

```
options passed:  -v test.c -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf

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

 l2-cache-size=2048 -mtune=core2 -O2
```

mentre con -march=core2:

```
options passed:  -v test.c -D_FORTIFY_SOURCE=2 -march=core2 -O2
```

 *Quote:*   

> Da gcc-4.3 c'è l'opzione "native". 
> 
> 

 

No, da GCC 4.2.3, tuttavia -march=core2 funziona solo con GCC superiore a 4.3.

EDIT:

Dopo tanto leggere, il mio primo post sul forum di Gentoo   :Very Happy: Last edited by K.a.o.s. on Tue Sep 22, 2009 7:49 pm; edited 1 time in total

----------

## fbcyborg

Molto interessante questa cosa!!!

Allora io sono a posto.. avevo già settato giusto...  :Smile: 

----------

## canduc17

Fiko. Io avevo core2, ma adesso ho aggiornato il make.conf con native...

GRazie K.a.o.s.!

----------

## lordalbert

bah... non ho capito se la scelta migliore sia core2 o native

----------

## ago

 *K.a.o.s. wrote:*   

> 
> 
> Dopo tanto leggere, il mio primo post sul forum di Gentoo  
> 
> 

 

Benvenuto!!!!

 *lordalbert wrote:*   

> bah... non ho capito se la scelta migliore sia core2 o native

 

personalmente per il momento mi fido di core2..nulla vieta che la scelta di native possa portare più vantaggi....però pensandoci bene..mettiamo per assurdo che native rende piu ottimizzata la cosa..puoi guadagnare qualcosina in compilazione...nulla di più   :Smile: 

----------

## fbcyborg

Alla fine mi viene da pensare che sia meglio mettere native qualora non si sappia con certezza quale sia la flag giusta. Io ad esempio avevo già core2, e mettere native sarebbe stata la stessa cosa, perché automaticamente avrei avuto un march=core2. Quindi, sempre che non ci siano vantaggi ulteriori riguardanti le ottimizzazioni, march=native o core2 è la stessa cosa (attenzione.. è la stessa cosa se core2 è proprio la flag per il vostro processore!)

----------

## ago

 *fbcyborg wrote:*   

> 
> 
> Quindi, sempre che non ci siano vantaggi ulteriori riguardanti le ottimizzazioni, march=native o core2 è la stessa cosa (attenzione.. è la stessa cosa se core2 è proprio la flag per il vostro processore!)
> 
> 

 

bene si...giusto per togliermi lo sfizio stamattina ho fatto un test, ho compilato un pacchetto con -march=core2 (che è la flag che uso) e lo stesso pacchetto senza flag -march, giusto per testare la differenza! ecco i risultati:

con: CFLAGS="-march=core2 -O2 -pipe" abbiamo:

```

root ago # time emerge -q audacious

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) media-sound/audacious-2.1

>>> Installing (1 of 1) media-sound/audacious-2.1

real   1m19.163s

user   1m18.356s

sys   0m27.232s

```

con CFLAGS="-march=native -O2 -pipe" abbiamo:

```

root ago # time emerge -q audacious

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) media-sound/audacious-2.1

>>> Installing (1 of 1) media-sound/audacious-2.1

real   1m17.950s

user   1m18.164s

sys   0m27.296s

```

provo anche senza nessun -march quindi: CFLAGS="-O2 -pipe" e abbiamo:

```

time emerge -q audacious

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) media-sound/audacious-2.1

>>> Installing (1 of 1) media-sound/audacious-2.1

real   1m18.772s

user   1m17.687s

sys   0m26.963s

```

e infine per dare l'idea commento CFLAGS E CXXFLAGS e ottengo:

```

root ago # time emerge -q audacious

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) media-sound/audacious-2.1

>>> Installing (1 of 1) media-sound/audacious-2.1

real   1m20.668s

user   1m17.681s

sys   0m27.195s

```

Risultato finale del test?beh questo era un semplice pacchetto..magari provare a farlo con roba tipo glibc da un po più l'idea..per il resto giudicate voi  :Very Happy: 

P.S. faccio notare che senza nessun -march è andato di poco più veloce rispetto a _march=core2 come è giusto che sia ma chissà le varie ottimizzazioni di native come vanno..

----------

## Apetrini

E uno scherzo?

Fammi capire bene... perché stai testando i tempi di compilazione invece dei tempi di esecuzione dei binari?

Se vuoi capire se usando la due flag ci siano differenze poi cominciare a fare il diff dei 2 binari, per vedere se in quel caso differiscono.

----------

## ago

non frantendiamoci ho fatto il test cosi..giusto per considerare anche il tempi di compilazione(che non cambiano per niente)

per quanto riguarda l'apertura e/o considerazione dei binari a occhio non ho notato nulla...poi questo discorso va fatto con il cambiamento del -march e magari un emerge di world o system

----------

## K.a.o.s.

 *Quote:*   

> giusto per considerare anche il tempi di compilazione(che non cambiano per niente)

 

Mah, magari dirò una stupidata... ma siamo sicuri che non c'entri ccache? L'avevi disattivato?

In genere -march non influenza più di tanto i tempi di compilazione se non ricordo male, ma -O0 più lento a compilare di -O2 non ce lo vedo   :Rolling Eyes: .

 *Quote:*   

> per quanto riguarda l'apertura e/o considerazione dei binari a occhio non ho notato nulla...

 

Infatti le CFLAGS non influenzano eccessivamente l'apertura dei programmi (se il binario è più grosso, impiega più tempo, ma ottimizzando quasi allo stesso modo la differenza non si nota). Se vuoi fare un benchmark, dovresti ricompilare le gtk (e le varie cose legate) e usare un tool come gtkperf. Questo ovviamente se usi Gnome.

Oppure ricompilare world e usare una suite come Phoronix   :Razz:  .

 *Quote:*   

> Benvenuto!!!!

 

Grazie   :Wink: .

----------

## ago

 *K.a.o.s. wrote:*   

> 
> 
> Mah, magari dirò una stupidata... ma siamo sicuri che non c'entri ccache? L'avevi disattivato?
> 
> 

 

Su questa macchina non l'ho mai attivato  :Smile: 

 *K.a.o.s. wrote:*   

> ma -O0 più lento a compilare di -O2 non ce lo vedo  .

 

se ti riferisci a quando ho commentato le flag....beh ho ottenuto quel risultato..magari come detto prima ci vorrebbe un emerge del world o system per notare meglio...

 *K.a.o.s. wrote:*   

> Se vuoi fare un benchmark, dovresti ricompilare le gtk (e le varie cose legate) e usare un tool come gtkperf. Questo ovviamente se usi Gnome.
> 
> Oppure ricompilare world e usare una suite come Phoronix  

 

non mi interessa particolarmente  :Wink: 

----------

## ciro64

Uhm.. mi intrometto sperando di non dire una cavolata:

guarando col mio core2 q9450

```

$ LC_ALL=C gcc -Q --help=target  -march=native -msse4.1 |grep enab > piu

$  LC_ALL=C gcc -Q --help=target  -march=native |grep enab > meno

$  $ diff piu meno 

11a12

>   -mno-sse4                         [enabled]

15,19d15

<   -msse                             [enabled]

<   -msse2                            [enabled]

<   -msse3                            [enabled]

<   -msse4.1                          [enabled]

<   -mssse3                           [enabled]

```

Quindi ciò significa che il native non necessariamente include le ottimizzazioni per la simd "avanzate" ?

Oppure, sbaglio ad interpretare (o ad aver scritto il comando) ?

Grazie per evntuali precisazioni.

Visto che è stato menzionata la phoronix-test-suite posso dire che col mio sistema ottengo in vari tests (ho provato grphicsmagick, ffmpeg ecc) performances  di almeno il 20% superiori rispetto a distro che usano pacchetti precompilati.

Sisi.. il lavorìo che sta dietro al mondo gentoo oltre a mpegnare in una più profonda comprensione dei sistemi, gratifica anche per risultati di questo tipo.

almeno.. per me è così  :Smile: 

----------

## K.a.o.s.

@ciro64

Ma sai che mi hai messo in crisi  :Laughing: ?

Il tuo comando mi dice che non ho abilitato le varie sse, mentre il mio sì.

Per dire:

```

gcc -Q --help=target -march=native -O2 | grep enab

  -m64                              [enabled]

  -m80387                           [enabled]

  -m96bit-long-double               [enabled]

  -malign-stringops                 [enabled]

  -mcx16                            [enabled]

  -mfancy-math-387                  [enabled]

  -mfp-ret-in-387                   [enabled]

  -mfused-madd                      [enabled]

  -mglibc                           [enabled]

  -mhard-float                      [enabled]

  -mieee-fp                         [enabled]

  -mno-sse4                         [enabled]

  -mpush-args                       [enabled]

  -mred-zone                        [enabled]

  -msahf                            [enabled]

  -mstackrealign                    [enabled]

  -mtls-direct-seg-refs             [enabled]
```

Mentre il mio:

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

...

options enabled:  -falign-labels -falign-loops -fargument-alias

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

 -fcaller-saves -fcommon -fcprop-registers -fcrossjumping

 -fcse-follow-jumps -fdefer-pop -fdelete-null-pointer-checks

 -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types

 -fexpensive-optimizations -fforward-propagate -ffunction-cse -fgcse

 -fgcse-lm -fguess-branch-probability -fident -fif-conversion

 -fif-conversion2 -findirect-inlining -finline

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

 -fipa-pure-const -fipa-reference -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 -fpeephole -fpeephole2 -freg-struct-return

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

 -fsched-interblock -fsched-spec -fsched-stalled-insns-dep

 -fschedule-insns2 -fsigned-zeros -fsplit-ivs-in-unroller

 -fsplit-wide-types -fstrict-aliasing -fstrict-overflow -fthread-jumps

 -ftoplevel-reorder -ftrapping-math -ftree-builtin-call-dce -ftree-ccp

 -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce

 -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im

 -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=

 -ftree-pre -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-sra

 -ftree-switch-conversion -ftree-ter -ftree-vect-loop-version -ftree-vrp

 -funit-at-a-time -funwind-tables -fvar-tracking -fvect-cost-model

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

 -maccumulate-outgoing-args -malign-stringops -mcx16 -mfancy-math-387

 -mfp-ret-in-387 -mfused-madd -mglibc -mieee-fp -mmmx -mno-sse4 -mpush-args

 -mred-zone -msahf -msse -msse2 -msse3 -mssse3 -mtls-direct-seg-refs

...
```

A chi dar ragione?   :Rolling Eyes: 

Secondo me sono sottointese da core2 e -msse4.1 le specifica ulteriormente. IMHO Gcc vede come disabled quelle non passate direttamente.

 *Quote:*   

> performances di almeno il 20% superiori rispetto a distro che usano pacchetti precompilati. 

 

Dipende anche dalla distro binaria. Io avevo fatto qualche test con Arch, ma il guadagno non era eccessivo (tranne nel test con Java). C'è da dire che usavo cflags "relativamente esotiche" con un leggero calo delle prestazioni. In ogni caso tu hai a disposizione le sse4.1 e ottieni un guadagno maggiore visto che le distro binarie non le supportano.   :Wink: 

----------

## ciro64

Uhm io sono un po' troppo niùbbo per esprimermi in modo sicuro.

Il tuo metodo direi che è decisamente più valido  :Smile: 

Notavo nel tuo output sono presenti tutte le simd fino ssse3 ; c'è quel -no-sse4 che   :Rolling Eyes: 

provando col tuo sistema ottengo output analogo al tuo.

Invece, se aggiungo:

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

```

ecco che compaiono.

```
...-malign-stringops -mcx16 -mfancy-math-387 -mfp-ret-in-387 -mfused-madd

 -mglibc -mieee-fp -mmmx -mpush-args -mred-zone -msahf -msse -msse2 -msse3

 -msse4.1 -mssse3 -mtls-direct-seg-refs

...
```

Quindi la tua opinione mi sa che è decisamente veritiera  :Smile: 

pensavo che con "native" non fosse necessario "imporgli" sse4.1.

Beh comunque grazie; alla fine mi hai aiutato tu a chiarire il tutto.

Ciao  :Smile: 

PS: ho provato a dare un'occhiata con gcc 4.4.1 (altra distro) e non è stato necessario mettere -msse4.1

ri-ciao.  :Smile: 

...........................................................................

E, tanto per vedere cosa si può ottenere, guardando

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

ecco il mio risultatino con core2 q9450 @2,66 GHz  :Very Happy: 

```
#####################################

GraphicsMagick:

Operation: HWB Color Space

148 Iterations Per Minute

148 Iterations Per Minute

149 Iterations Per Minute

Average: 148.33 Iterations Per Minute

#####################################

```

----------

## mack1

Core2 non abilita sse4.1 dal man di gcc-4.1.1:

 *Quote:*   

> 
> 
> core2
> 
>  Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support.
> ...

 

Non hanno ancora inserito il supporto alla famiglia i7 che dovrebbe comprendere di default sse4*, native imposta da solo il valore di march/mtune corretto.

 *Quote:*   

> 
> 
> native
> 
>  This selects the CPU to tune for at compilation time by determining the processor type of the compiling machine. Using -mtune=native will produce code optimized for the local machine under the constraints of the selected instruction set. Using -march=native will enable all instruction subsets supported by the local machine (hence the result might not run on different machines).
> ...

 

Ciao

----------

## Elbryan

Per sapere quali sono le opzioni del compilatore senza ricorrere alla creazione di un file di test e successiva rimozione si può utilizzare:

```

gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'

```

Inoltre voglio ricordare che -march=native non funziona su distcc e, come dice mack1, la flag sse4 va esplicitata manualmente.

Ricordo che è sempre meglio specificare per esteso le CFLAGS poiché certi programmi (come ffmpeg) fanno controllo sulle flag del precompilatore ed a me, per esempio, non riconosceva "native" per cui non mi abilitava le estensioni.

----------

## K.a.o.s.

 *Quote:*   

> Ricordo che è sempre meglio specificare per esteso le CFLAGS poiché certi programmi (come ffmpeg) fanno controllo sulle flag del precompilatore ed a me, per esempio, non riconosceva "native" per cui non mi abilitava le estensioni.

 Sicuro che non sia perchè non hai abilitato la flags -custom-cflags (e/o -cpudetection)?   :Confused: 

----------

## Elbryan

 *K.a.o.s. wrote:*   

>  *Quote:*   Ricordo che è sempre meglio specificare per esteso le CFLAGS poiché certi programmi (come ffmpeg) fanno controllo sulle flag del precompilatore ed a me, per esempio, non riconosceva "native" per cui non mi abilitava le estensioni. Sicuro che non sia perchè non hai abilitato la flags -custom-cflags (e/o -cpudetection)?  

 

Sì, sarà anche per quel motivo lì ( :Razz: ).. però comunque sia non tutti hanno tale flag per regolarne il comportamento.

----------

