# Cambiare CPU

## theRealMorpheu5

Se, ipoteticamente, volessi passare ad un P4 - con tutti i cambiamenti hardware che ne deriverebbero - c'è un modo indolore per convertire la mia Gentoo dall'Athlon XP tipo emerge -e world oppure mi conviene rifare l'installazione in toto?

Nel caso di emerge -e world, dovrei cambiare flags e via dicendo, giusto? Una volta fatto hara-kiri, però, dovrei attendere di montare il nuovo hardware prima di poter ricaricare il pinguino. Oltrettutto non sono così convinto di poter crosscompilare agilmente da AMD ad Intel. Forse sarebbe il caso di passare per una -e world con architettura generale i686 per poi ricompilare col P4?

Insomma, non ho nessuna intenzione di farlo nell'immediato, ma è una di quelle cose che è meglio sapere prima piuttosto che poi, non trovate? Parliamone.

----------

## blackfede

Credo che se devi fare una compilazione generale a 686 e poi ricompilare per p4, allora ti conviene ricompilare da capo tutto sul nuovo p4.

----------

## fedeliallalinea

E perche' non compili tutto i686 e lasci cosi'. Almeno se in un futuro cambierai ancora non devi ricompilare piu' niente. Io su desktop lascio tutto compilato per i686.

----------

## theRealMorpheu5

Ma perché ormai, allo stato attuale della tecnologia, un cambio di CPU implica quasi un cambio dell'intero sistema e quindi non è una di quelle cose che si fanno un giorno sì ed uno no.

----------

## xchris

potresti fare il passaggio ->i686->p4 solo per il sistema base.

Poi con calma fai il passaggio amd->p4. 

(magari compilati anche lynx/links per non annoiarti nel frattempo  :Very Happy:  )

ciao

----------

## theRealMorpheu5

Uhm, sì, potrebbe essere un'idea. Per il sistema di base che pacchetti devo ricompilare? Avevo sentito parlare di un fantomatico baselayout, sarà questo oppure mi devo tirare giù a manina la lista dei pacchetti e ricompilarli a manina uno alla volta?

----------

## randomaze

 *theRealMorpheu5 wrote:*   

> Per il sistema di base che pacchetti devo ricompilare?

 

La lista la ottieni con:

```

emerge -ep system

```

se togli la p inizia a compilare....

----------

## sorchino

Ma se invece al momento del cambio di cpu metti su il live cd, ti ricompili il sistema direttamente da athlon a p4?

----------

## fedeliallalinea

Io resto sempre dell'idea di mettere cflag piu' generali come i686.

----------

## xchris

@fedeliallalinea

dovremmo fare un test per vedere quanto si guadagna tra i686 e P4 (o altra)

@[Alexi_Laiho]

appena ti chrooti inizia ad usare binari per amd.(e non e' detto che gradisca)

ciao

----------

## fedeliallalinea

 *xchris wrote:*   

> @fedeliallalinea
> 
> dovremmo fare un test per vedere quanto si guadagna tra i686 e P4 (o altra)

 

Probabilmente si guadagna qualcosa ma non penso che faccia questa grande differenza.

----------

## xchris

si è probabile...

se hai suggerimenti su un app da testare.. sarò lieto di provare.

Pensavo a DVD->DIVX ma se non sbaglio l'ebuild di mplayer non sfrutta le ottimizzazione.

ciao

----------

## fedeliallalinea

 *xchris wrote:*   

> Pensavo a DVD->DIVX ma se non sbaglio l'ebuild di mplayer non sfrutta le ottimizzazione.

 

Con mplayer e' vero ma con xine?

----------

## randomaze

Forse si possono prendere i tempi con lame.

Oppure guardando il tempo di avvio di qualche "bisonte" come mozilla...

----------

## xchris

se lame e' un test affidabile... c'e' da piangere

```

xchris@lyra xchris $ lame lame.wav lame.mp3 -b 320

Assuming raw pcm input file

LAME version 3.96 MMX  (http://www.mp3dev.org/)

CPU features: MMX (ASM used), SSE, SSE2

Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz

Encoding lame.wav to lame.mp3

Encoding as 44.1 kHz 320 kbps j-stereo MPEG-1 Layer III (4.4x) qval=3

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA

 25787/25790 (100%)|    0:43/    0:43|    0:43/    0:43|   15.376x|    0:00

average: 320.0 kbps   LR: 25782 (99.97%)   MS: 8 (0.03102%)

Writing LAME Tag...done

ReplayGain: -13.4dB

xchris@lyra xchris $ ##### fatto con -02 -arch=i686 -pipe

```

```

xchris@lyra xchris $ lame lame.wav lame.mp3 -b 320

Assuming raw pcm input file

LAME version 3.96 MMX  (http://www.mp3dev.org/)

CPU features: MMX (ASM used), SSE, SSE2

Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz

Encoding lame.wav to lame.mp3

Encoding as 44.1 kHz 320 kbps j-stereo MPEG-1 Layer III (4.4x) qval=3

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA

 25787/25790 (100%)|    0:44/    0:44|    0:44/    0:44|   15.282x|    0:00

average: 320.0 kbps   LR: 25782 (99.97%)   MS: 8 (0.03102%)

Writing LAME Tag...done

ReplayGain: -13.4dB

xchris@lyra xchris $ ##### fatto con -02 -arch=pentium4 -pipe

```

----------

## fedeliallalinea

[quote="xchris"]se lame e' un test affidabile... c'e' da piangere[quote]

Sarebbe bello se possibili provare a compilare lame con gcc 2.95 e vedere quello che sa fare. Mi hanno detto che crea eseguibili piu' snelli.

----------

## randomaze

 *xchris wrote:*   

> se lame e' un test affidabile... c'e' da piangere
> 
> 

 

Perché? Perché per i flag generici ci mette un sec in più?

Comunque c'é qualcosa che non va bene, mi sa che anche l'ebuild di lame (o lame stesso) taroccano un poco i flags, infatti:

```

CPU features: MMX (ASM used), SSE, SSE2

xchris@lyra xchris $ ##### fatto con -02 -arch=i686 -pipe

```

Quelli sono flags che vanno bene sul P4 ma non sull'AMD (che non supporta le SSE2)... mi sa che nel configure (o simili) ci sono routine di auto-detect del processore!

----------

## xchris

magari provo + tardi

intanto una verità ancor + schiacciante :S

```

xchris@lyra xchris $ lame lame.wav lame.mp3 -b 320

Assuming raw pcm input file

LAME version 3.96 MMX  (http://www.mp3dev.org/)

CPU features: MMX (ASM used), SSE, SSE2

Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz

Encoding lame.wav to lame.mp3

Encoding as 44.1 kHz 320 kbps j-stereo MPEG-1 Layer III (4.4x) qval=3

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA

 25787/25790 (100%)|    0:45/    0:45|    0:45/    0:45|   14.857x|    0:00

average: 320.0 kbps   LR: 25782 (99.97%)   MS: 8 (0.03102%)

Writing LAME Tag...done

ReplayGain: -13.4dB

xchris@lyra xchris $ ##### fatto con -03 -arch=pentium4 -pipe

```

----------

## xchris

 *randomaze wrote:*   

> 
> 
> Perché? Perché per i flag generici ci mette un sec in più?
> 
> Comunque c'é qualcosa che non va bene, mi sa che anche l'ebuild di lame (o lame stesso) taroccano un poco i flags, infatti:
> ...

 

a dire il vero i flags generici sono + veloci.  :Sad: 

e se metti -03 e' ancor peggio.

Vero che rileva il processore.

Inventiamoci magari un test + efficace. (anche se gia' questo mi fa pensare molto)

ciao

----------

## fedeliallalinea

Prova ad aggiungere la flags -fomit-frame-pointer

----------

## xchris

aggiungendo -fomit-frame-pointer

```

xchris@lyra xchris $ lame lame.wav lame.mp3 -b 320

Assuming raw pcm input file

LAME version 3.96 MMX  (http://www.mp3dev.org/)

CPU features: MMX (ASM used), SSE, SSE2

Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz

Encoding lame.wav to lame.mp3

Encoding as 44.1 kHz 320 kbps j-stereo MPEG-1 Layer III (4.4x) qval=3

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA

 25787/25790 (100%)|    0:45/    0:45|    0:45/    0:45|   14.714x|    0:00

average: 320.0 kbps   LR: 25782 (99.97%)   MS: 8 (0.03102%)

Writing LAME Tag...done

ReplayGain: -13.4dB

xchris@lyra xchris $ ##### fatto con -02 -arch=pentium4 -fomit-frame-pointer -pipe

```

```

xchris@lyra xchris $ lame lame.wav lame.mp3 -b 320

Assuming raw pcm input file

LAME version 3.96 MMX  (http://www.mp3dev.org/)

CPU features: MMX (ASM used), SSE, SSE2

Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz

Encoding lame.wav to lame.mp3

Encoding as 44.1 kHz 320 kbps j-stereo MPEG-1 Layer III (4.4x) qval=3

    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA

 25787/25790 (100%)|    0:45/    0:45|    0:45/    0:45|   14.724x|    0:00

average: 320.0 kbps   LR: 25782 (99.97%)   MS: 8 (0.03102%)

Writing LAME Tag...done

ReplayGain: -13.4dB

xchris@lyra xchris $ ##### fatto con -03 -arch=pentium4 -fomit-frame-pointer -pipe

```

----------

## randomaze

 *xchris wrote:*   

> Inventiamoci magari un test + efficace. (anche se gia' questo mi fa pensare molto)
> 
> 

 

nbench?

Oppure possiamo vedere se é facile estrapolare i test fatti qui...

EDIT: I sorgenti di almabench

----------

## xchris

proviamo con nbech

confronto tra 

-02 -arch=pentium4 -fomit-frame-ponter -pipe

-03 -arch=pentium4 -fomit-frame-ponter -pipe

-02 -arch=i686 -pipe

```
 

xchris@lyra xchris $ nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)

Index-split by Andrew D. Balsa (11/97)

Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index

                    :                  : Pentium 90* : AMD K6/233*

--------------------:------------------:-------------:------------

NUMERIC SORT        :          1092.8  :      28.03  :       9.20

STRING SORT         :          59.856  :      26.75  :       4.14

BITFIELD            :      3.6675e+08  :      62.91  :      13.14

FP EMULATION        :           98.96  :      47.49  :      10.96

FOURIER             :           15092  :      17.16  :       9.64

ASSIGNMENT          :          31.512  :     119.91  :      31.10

IDEA                :          1491.7  :      22.81  :       6.77

HUFFMAN             :          1051.6  :      29.16  :       9.31

NEURAL NET          :          23.834  :      38.29  :      16.11

LU DECOMPOSITION    :          1086.4  :      56.28  :      40.64

==========================ORIGINAL BYTEMARK RESULTS==========================

INTEGER INDEX       : 40.497

FLOATING-POINT INDEX: 33.317

Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0

==============================LINUX DATA BELOW===============================

CPU                 : 4 CPU GenuineIntel Intel(R) Xeon(TM) CPU 2.80GHz 2791MHz

L2 Cache            : 512 KB

OS                  : Linux 2.6.3-gentoo-r1

C compiler          : 3.3.2

libc                :

MEMORY INDEX        : 11.916

INTEGER INDEX       : 8.931

FLOATING-POINT INDEX: 18.479

Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

* Trademarks are property of their respective holder.

xchris@lyra xchris $ ##### fatto con -02 -arch=pentium4 -fomit-frame-pointer -pipe

```

```

xchris@lyra xchris $ nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)

Index-split by Andrew D. Balsa (11/97)

Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index

                    :                  : Pentium 90* : AMD K6/233*

--------------------:------------------:-------------:------------

NUMERIC SORT        :            1080  :      27.70  :       9.10

STRING SORT         :          59.656  :      26.66  :       4.13

BITFIELD            :      3.6413e+08  :      62.46  :      13.05

FP EMULATION        :          133.32  :      63.97  :      14.76

FOURIER             :           15184  :      17.27  :       9.70

ASSIGNMENT          :          31.125  :     118.44  :      30.72

IDEA                :            1872  :      28.63  :       8.50

HUFFMAN             :          1041.2  :      28.87  :       9.22

NEURAL NET          :          23.912  :      38.41  :      16.16

LU DECOMPOSITION    :            1076  :      55.74  :      40.25

==========================ORIGINAL BYTEMARK RESULTS==========================

INTEGER INDEX       : 43.374

FLOATING-POINT INDEX: 33.314

Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0

==============================LINUX DATA BELOW===============================

CPU                 : 4 CPU GenuineIntel Intel(R) Xeon(TM) CPU 2.80GHz 2791MHz

L2 Cache            : 512 KB

OS                  : Linux 2.6.3-gentoo-r1

C compiler          : 3.3.2

libc                :

MEMORY INDEX        : 11.825

INTEGER INDEX       : 10.129

FLOATING-POINT INDEX: 18.477

Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

* Trademarks are property of their respective holder.

xchris@lyra xchris $ ##### fatto con -03 -arch=pentium4 -fomit-frame-pointer -pipe

```

```

xchris@lyra xchris $ nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)

Index-split by Andrew D. Balsa (11/97)

Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index

                    :                  : Pentium 90* : AMD K6/233*

--------------------:------------------:-------------:------------

NUMERIC SORT        :            1069  :      27.41  :       9.00

STRING SORT         :          59.736  :      26.69  :       4.13

BITFIELD            :      2.9564e+08  :      50.71  :      10.59

FP EMULATION        :          67.706  :      32.49  :       7.50

FOURIER             :           15508  :      17.64  :       9.91

ASSIGNMENT          :          24.601  :      93.61  :      24.28

IDEA                :          1502.2  :      22.98  :       6.82

HUFFMAN             :          1295.9  :      35.93  :      11.47

NEURAL NET          :          23.684  :      38.05  :      16.00

LU DECOMPOSITION    :            1027  :      53.21  :      38.42

==========================ORIGINAL BYTEMARK RESULTS==========================

INTEGER INDEX       : 36.901

FLOATING-POINT INDEX: 32.927

Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0

==============================LINUX DATA BELOW===============================

CPU                 : 4 CPU GenuineIntel Intel(R) Xeon(TM) CPU 2.80GHz 2791MHz

L2 Cache            : 512 KB

OS                  : Linux 2.6.3-gentoo-r1

C compiler          : 3.3.2

libc                :

MEMORY INDEX        : 10.204

INTEGER INDEX       : 8.526

FLOATING-POINT INDEX: 18.263

Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

* Trademarks are property of their respective holder.

xchris@lyra xchris $ ##### fatto con -02 -arch=i686 -pipe

```

in alcuni bench i686 con 02 va meglio. (FOURIER)

e forse e' proprio per questo che i risultati di lame (che dovrebbe andare di Trasformate di Fourier) risulta + veloce.

Che ne dite?

----------

## randomaze

 *xchris wrote:*   

> FLOATING-POINT INDEX: 33.317
> 
> FLOATING-POINT INDEX: 33.314
> 
> FLOATING-POINT INDEX: 32.927
> ...

 

In effetti gli indici fp sono molto simili (anche se continuo ad avere il dubbio che lame si tarocchi i flags a suo piacere...).

Di contro sull'indice intero le differenze sono più marcate... tra la compilazione generica e la O3

Appena posso faccio girare gli stessi test sul mio AMD

----------

## Marculin

ma per usare nbench con diverse flags basta cambiarle in /etc/make.conf e ti fa subito i nuovi test?pensavo bisognasse ricompilare qualcosa....

se vi serve il seguente test è con CFLAGS="-O2 -march=i686 -funroll-loops -pipe"

```

BYTEmark* Native Mode Benchmark ver. 2 (10/95)

Index-split by Andrew D. Balsa (11/97)

Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index

                    :                  : Pentium 90* : AMD K6/233*

--------------------:------------------:-------------:------------

NUMERIC SORT        :          528.32  :      13.55  :       4.45

STRING SORT         :          24.281  :      10.85  :       1.68

BITFIELD            :      1.1123e+08  :      19.08  :       3.99

FP EMULATION        :           25.18  :      12.08  :       2.79

FOURIER             :            7649  :       8.70  :       4.89

ASSIGNMENT          :          5.7087  :      21.72  :       5.63

IDEA                :          691.43  :      10.58  :       3.14

HUFFMAN             :          448.52  :      12.44  :       3.97

NEURAL NET          :          9.0338  :      14.51  :       6.10

LU DECOMPOSITION    :          387.91  :      20.10  :      14.51

==========================ORIGINAL BYTEMARK RESULTS==========================

INTEGER INDEX       : 13.831

FLOATING-POINT INDEX: 13.638

Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0

==============================LINUX DATA BELOW===============================

CPU                 : GenuineIntel Celeron (Coppermine) 802MHz

L2 Cache            : 128 KB

OS                  : Linux 2.6.6

C compiler          : 3.3.2

libc                :

MEMORY INDEX        : 3.353

INTEGER INDEX       : 3.527

FLOATING-POINT INDEX: 7.564

Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

* Trademarks are property of their respective holder.

```

----------

## xchris

 *Marculin wrote:*   

> ma per usare nbench con diverse flags basta cambiarle in /etc/make.conf e ti fa subito i nuovi test?pensavo bisognasse ricompilare qualcosa....
> 
> 

 

una volta cambiate CFLAGS devi riemergere nbench

ciao

----------

## Marculin

grazie....proverò anche con altre cflag....

ps: bisognerebbe metterlo come TIP almeno i newbie provano le varie cflag sul pc+nbech e cosi vedono quali sono migliori   :Rolling Eyes: 

----------

## randomaze

 *randomaze wrote:*   

> Appena posso faccio girare gli stessi test sul mio AMD

 

Fatto... ma mi son dimenticato il file a casa  :Embarassed: 

Comunque i risultati sono pressoche analoghi (differenze minime anche sugli indici) a quelli di xchris, il che mi fa dubitare della bontà di nbench per questi test dato che io ho usato un Athlon-XP 2200+ che, stando a nbench, risulta essere dello stesso livello del doppio Xeon 2.8 usato da xchris

L'altro programmillo (che mi son limitato a compilare e lanciare senza legere le istruzioni) invece non da output e il tempo di esecuzione é praticamente lo stesso con le tre casistiche (i686 02, athlon-xp O2 e athlon-xp O3). Proverò a leggere le istruzioni.

----------

## xchris

a dire il vero non mi stupisco delle prestazioni.

nbench quando gira occupa solo uno dei 4 (finti) processori. (HT attivo)

(risulta il tutto un po' + lento di un P4 2,8 senza HT)

ci servono test + indicati  :Smile: 

(anche se questo test era per vedere quanto le ottimizzazioni influiscono)

ciao

----------

## randomaze

 *xchris wrote:*   

> nbench quando gira occupa solo uno dei 4 (finti) processori. (HT attivo)
> 
> (risulta il tutto un po' + lento di un P4 2,8 senza HT)
> 
> 

 

Beh si ma si suppone che uno dei tuoi 4 (finti) fosse interamente dedicato a nbench mentre sul mio unico girava tutto il sistema.... poi il mio (secondo AMD) sarebbe paragonabile a un 2,2 mentre dai test sembra paragonabile a un 2,8

 *Quote:*   

> 
> 
> (anche se questo test era per vedere quanto le ottimizzazioni influiscono)
> 
> 

 

Spannometricamente siamo nello stesso ordine con l'indice floating-point (quindi multimedia e simili) mentre sull'integer (sistema, compilazione, ...) le CFLAGS generiche causano un degrado nell'ordine del 20% (poco meno con lo Xeon e poco più con l'XP).

Tra l'altro anche la differenza nell'FP mi suona "strana" perché con arch=i686 dovrebbe usare solo 387, MMX e (forse) SSE mentre andando su architettura specifica dovrebbero aggiungersi anche 3DNow! e SSE2... ma pare che non influiscano più di tanto!

 *Quote:*   

> 
> 
> ci servono test + indicati 
> 
> 

 

Si... si potrbbe pensare a qualcosa di meno astratto tipo avvio di FireFox (compilato con USE flag concordate) con pagina DHTML che prende i tempi.

Oppure un rapido testcase con bash/wget all'assalto di un apache/mysql/php.

Appena ho tempo provo a dare un occhiata in giro...

----------

## xchris

 *randomaze wrote:*   

> 
> 
> Beh si ma si suppone che uno dei tuoi 4 (finti) fosse interamente dedicato a nbench mentre sul mio unico girava tutto il sistema.... poi il mio (secondo AMD) sarebbe paragonabile a un 2,2 mentre dai test sembra paragonabile a un 2,8
> 
> 

 

non volevo di certo screditare il tuo AMD  :Very Happy: 

volevo solo dire che HT ha peggiorato le prestazioni in questo caso  :Smile: 

io saro' assente per una settimana.

Quando torno se hai trovato un test attendibile proviamo un po'.

ciao

----------

## randomaze

 *xchris wrote:*   

> non volevo di certo screditare il tuo AMD 
> 
> 

 

In realtà lo stavo screditando io visto che dati i risultati non credo ai test  :Razz: 

 *xchris wrote:*   

> 
> 
> io saro' assente per una settimana.
> 
> 

 

Ma come, ci pacchi la cena pre-webbit?

 *xchris wrote:*   

> 
> 
> Quando torno se hai trovato un test attendibile proviamo un po'.
> 
> 

 

Ok... in giro si trova un pò di roba... vediamo se trovo qualcosa di utile!

----------

