# CPU-Wechsel

## MTZ

HiHo,

ich verwende derzeit noch einen Duron 1.3. Das System wurde mit einem Stage3-x86 Package installiert, die spaeter installierten Programme wurden mit USE flags "march=athlon-xp" kompiliert.

Nun wird der CPU durch einen Celeron 2 GHz ersetzt. Kann ich mein System weiter nutzen, oder muss ich die ganzen Pakete neu kompilieren ? Wenn ja sollte ein emerge -u world helfen nachdem die USE flags fuer Celeron umgestellt wurden ?

----------

## schmutzfinger

ich weiss nicht wie es bei den speziellen cpu's ist, aber da der eine intel und der andere amd ist, denke ich mal da gibt es gravierende unterschiede. wenn du jetzt alles neu kompilierst, kann ich mir gut vorstellen, das spätestens nachdem dein compiler für nen intel gebaut ist schluss mit lustig ist, und dein system kaputt ist.und wenn du dann ein halb intel halb amd system hast, dann kannst du es mit keiner von beiden cpus mehr richtig benutzen. ich glaub da gab es schon ein paar threads dazu. ich würde sagen 

```
emerge -eD system
```

 mit use flags für x386. dann die neue CPU rein und das selbe nochmal mit den neuen USE Flags.

hab es noch nicht getestet, aber kann mir sehr gut vorstellen, das es geht  :Smile:  .

----------

## Realmaker

Etwas andere Frage: Wieso hast du dich für einen Celeron mit 2 GHz entschieden? Die haben meines Wissens nach die gleiche Leistung wie ein Duron mit deutlich weniger Mhz

----------

## andreh

Bei meinem Update von einem AMD K6-II 400MHz auf einen Pentium IV 2.4GHz kam es zu keinen Problemen, obwohl das System komplett mit "-march=k6-2 ..." gebaut wurde. Ich konnte alles mit der neuen Intel CPU starten und habe dann einfach das gesamte System neugebaut. Kann also von keinen gravierenden Einschränkungen sprechen.

----------

## MTZ

 *Realmaker wrote:*   

> Etwas andere Frage: Wieso hast du dich für einen Celeron mit 2 GHz entschieden? Die haben meines Wissens nach die gleiche Leistung wie ein Duron mit deutlich weniger Mhz

 

Da dies nun das 4te System ist bei dem ich mit AMD recht viele Probleme habe und da der Celeron ganz preiswert ist, habe ich mich fuer ihn entschieden.

Zudem fuer ein bischen X und DOSBox sollte der reichen  :Smile: 

----------

## siliconburner

celern ist viel zu lahm (beim rendern mit povray ist mein 1000er athlon schneller als mein 2400er celeroin).die reltion preis leitung ist nicht gerechtfertigt. bei dem angegeben k6 und p4 rechner wirds wohl so swein, das k6-2 nichts spezielles hat. versuchs einfach, wenn der celeron drin ist emerge -eD world. und wenn er durchmacht ohne probleme, dann ists o.k. ansonsten, kannst du jetzt, auf i686 kompilen und mit neuem proz auf intel umsteiugen. aber da du stage3 (was ist das?  :Wink:  )  benuzt ists wohl besser neu zu machen wnns nich geht. denk dran 3dnow und andere flags nicht mit reinzusetzen (cat/proc/cpuinfo) die kann der celeron nicht (wenihger cache, weniocger befehle null leistung)

----------

## MTZ

Kleines Info-Update:

Inzwischen habe ich das neue Board+CPU in Betrieb. Eine Neukompilierung des Kernels und der Module hat ausgereicht. Saemtliche Programme, auch XFree, Gnome 2.6 etc. laufen einwandfrei - Obwohl diese mit den athlon-xp USE Flags kompiliert wurden.

----------

## Fibbs

Hmmm, gut möglich dass diese laufen.

Aber optimiert auf die CPU kann man dazu dann nicht wirklich sagen. Ich schätze, dass Du nach einer Neukompilation Deines ganzen Systems (--emptytree) deutlich mehr Performance haben wirst.

----------

## ian!

Damit wirst Du höchstwahrscheinlich Probleme bekommen. Dein Code ist auf Befehle optimiert, die deinem jetzigen System möglicherweise völlig fehlen. Siehe hierzu auch im 'man gcc':  *man gcc wrote:*   

>            While picking a specific cpu-type will schedule things appropriately for that par-
> 
>            ticular chip, the compiler will not generate any code that does not run on the i386
> 
>            without the -march=cpu-type option being used.  i586 is equivalent to pentium and
> ...

 

bzw.

 */etc/make.conf wrote:*   

> # -march=<cpu-type> means to take full advantage of the ABI and instructions
> 
> # for the particular CPU; this will break compatibility with older CPUs (for
> 
> # example, -march=athlon-xp code will not run on a regular Athlon, and
> ...

 

----------

## Shadows

Hi zusammen

Wollte keinen eigenen Thread für das gleiche Problem starten, daher poste ich's hier. Hab da auch ein paar Fragen zu.

Ich hab's genau umgekehrt, hab vorher einen PIII-450 gehabt, ebenfalls mit -march von Stage1 aus kompiliert (Gentoo 1.4rc4) und baue mir jetzt einen Duron 800 ein bzw. habe einen extra Zweitrechner dafür. Ob der Duron an sich jetzt schneller ist, sei mal dahin gestellt, warum ich mich trotzdem dafür entscheide lässt sich in wenigen Punkten zusammenfassen:

- Bogo-mips PIII: 897.84, Duron: 1595.80

- Cache laut memtest86: PIII: L1 32K 4410 MB/s, L2 512K 563 MB/s; Duron: L1 128K 4907 MB/s, L2 64K 2173 MB/s

- AMD Board via KT266, aufrüstbar bis in GHz und auch mit Athlon XP, UDMA-100, DDR-RAM etc; PIII-Board mit 440BX-Chipset, bei 600 / 700 MHz irgendwo Schluss, max UDMA-66, SD-RAM etc.

- PIII-Board evtl. unstabil

Jetzt habe ich aber einige Probleme auf dem System, welche mehr oder weniger heftig sind (also schon vor dem CPU-Wechsel, welcher noch nicht statt gefunden hat).

Als Beispiel wären da zu nennen, dass nach jedem updatedb-Durchlauf der benutzte Speicher (used+shar in xosview zum Beispiel) nicht wieder frei gegeben wird oder das beim rippen und encoden nach ogg einer CD über den Konquerer immer 5 Sekunden vom Track fehlen, von Performance-problemen, welche ich auf dem selben Rechner unter SuSE 7.1 (mit selbst kompiliertem KDE 3.1 und noch ein paar anderen Sachen) nicht habe. Zum Beispiel springt der Sound von XMMS ab und an mal heftigst bei I/O-Operationen mit den disks oder ROM-Laufwerken.

Jetzt habe ich irgendwo - weiß leider nicht mehr genau wo, ob im englischen Gentoo-Forum oder in den Gentoo-Docs, keine Ahnung - gelesen, dass bei gleichzeitiger Verwendung von -O3 und -march Probleme auftreten können, welche sich in Kleinigkeiten wie zum Beispiel den von mir beschriebenen Auswirken können. Eine Verwendung von -O3 und -mcpu soll daher weitgehend safe sein. Hätte ich das mal lieber gehabt, hätte ich mir doch die Probleme evtl. sparen können und durch die Kompatibilität einfach die Platte in den Duron-Rechner einbauen, updaten, fertig. Na ja, war nicht nachgedacht bevor ich mich für -march entschieden habe, und dass ich mit dem PIII mein letztes Intel-System hatte, war damals auch schon 100% klar, die Frage war halt nur wann. Na ja, whatever, selbst schuld.

Da die meisten der beschriebenen Probleme erstmal keine logische Erklärung bringen, gehe ich einfach mal davon aus, dass die Verwendung von -O3 und -march tatsächlich zu buggy Programmen geführt haben.

So, nach dem langatmigen Vorlauf, hier die eigentlichen Fragen:

1. Falls tatsächlich Probleme durch die CFLAGS entstanden sind, ist die Wahrscheinlichkeit hoch, dass auch die libc und der gcc etc. buggy sind. Ein recompile des Systems mit -mcpu dürfte also höchstwahrscheinlich wieder buggy Progs liefern, selbst wenn die CFLAGS diesmal keine Probleme bereiten, richtig?

2. Also am besten wieder von Stage1 auf der Duron-Maschine neu kompilieren würd ich jetzt folgern. Da stelle ich mir aber die Frage, wie ich meine Einstellungen übernehmen kann? Ich hab nämlich keine Lust, alle einzelnen Einstellungen zusammenzusuchen und per Hand rüber zu kopieren. Außerdem müsste ich mir auch Gedanken machen, wann ich sie rüber kopiere. Vor dem Kompilieren, nach dem kompletten Kompilieren? Wo liegen die ganzen Files, hab ich nicht was vergessen, etc.? Hat da schon jemand Erfahrung und ein Rezept, wie man das am einfachsten und sichersten macht, ohne irgendwas zu vergessen - gibt ja nicht nur /etc?

3. Generelle Frage: Wie kann ich portage zwingen, jedes - und damit meine ich wirklich jedes einzelne - Paket auf dem System neu zu kompilieren? Beispielsweise, weil ich USE-Flags geändert habe oder halt statt vorher mit -march jetzt lieber die ganzen Pakete mit -mcpu kompilieren möchte? Hab jetzt einige Änderungen in make.conf gemacht, aber ein emerge -up world sagt mir, dass alle Pakete auf dem aktuellsten Stand sind, ebenso emerge -p world, welches nach meinem Verständnis ja einfach neu kompilierne müsste, egal ob es neuere Versionen gibt oder nicht. Ist wohl nicht auf Klassen anwendbar, genauso, wie ja auch ein emerge blah nur Paket blah neu kompiliert, ohne dependencies zu berücksichtigen / neu zu kompilieren. Wohlgemerkt - nur die aktuell installierten Pakete in den gleichen Versionen, ohne ein einziges Paket upzudaten.

Ich hab mir jetzt erstmal damit geholfen, mit epm -qa eine Liste aller installierten Pakte zu erstellen, welche ich dann einfach (nachdem ich doppelte gefiltert und Versionsnummern entfernt habe versteht sich) mit emerge -up $(cat installed_files.txt) anzeigen lasse, was er machen würde. Damit hätte ich ja quasi jedes Paket, aber evtl. neu auftretende deps (durch Änderung der USE-Flags) werden hier ja nicht berücksichtigt, da ja ein einfacher Aufruf von emerge nur das Paket recompiled, ohne auf die deps zu achten. Also, wirklich sauber ist das nicht. Hab auch in den Docs nix dazu gefunden. Einer auch hier einen Tip?

Greetz

Shad

----------

## Realmaker

Du hättest auch emerge -peD world machen können.

Und emerge -pu world updatet nur auf neue Versionen, nicht auf neue CFLAGS

----------

## Donnergurgler

@Shadows: BogoMips ist kein Benchmark, den Du

architekturübergreifend verwenden kannst. Er lässt nur Vergleiche

zwischen gleichen Prozessor-Architekturen zu und ist nur noch

im Kernel, weil ihn die Leute so toll finden

Ansonsten dürfte der Duron schon etwas schneller sein als der

Pentium. 350 MHz kann der größere Cache des PIII nicht gutmachen.

----------

## Shadows

@Realmaker

 *Realmaker wrote:*   

> Du hättest auch emerge -peD world machen können.

 

Nicht wirklich, denn auch hier fehlen Pakete. Die system-Datei ist meine erstellte, in der anderen habe ich alle überflüssigen Zeilen außer die Programmzeilen aus dem emerge output rausgeschrieben:

```
wc -l system.snapshot.txt emerge-peD.txt

  258 system.snapshot.txt

  245 emerge-peD.txt

  503 total
```

Außerdem  enthält die emerge-Datei das Paket musicbrainz, welches ich derzeit gar nicht auf dem System habe.

Aber was ich ja will ist jedes einzelne derzeit im System installierte Paket einfach nur neu kompilieren, ohne Pakete auszulassen, neue Pakete hinzuzufügen oder Pakete upzudaten und in neuerer Version zu installieren, als ich derzeit auf dem System habe.

 *Realmaker wrote:*   

> Und emerge -pu world updatet nur auf neue Versionen, nicht auf neue CFLAGS

 

Ja, das war mir auch schon klar, aber ich dachte, dass wenigstens eine Änderung an den USE-Flags neue deps mit sich bringen und daher auch bei diesem Aufruf berücksichtigt würde.

@Donnergurgler

Das war auch nicht wirklich als "Benchmark" zu verstehen ;) Mir ist auch klar, dass hier die ganzen Prozessoreigenschaften wie Befehlssätze, Architektur  und ähnliches nicht mit berücksichtigt sind ;)

Aber der Wert ist doppelt so hoch, was bei fast doppelt so viel MHz eigentlich auch zu erwarten ist.

Beim Cache ist ausgleichend, dass L1 beim Duron 4x so groß und zumindest etwas schneller ist und L2 immerhin 4x so schnell.

Mit den richtigen Optimierungen geh ich einfach davon aus, dass er bedeutend schneller sein müsste.

Greetz

Shad

----------

## Batsi

 *Donnergurgler wrote:*   

> @Shadows: BogoMips ist kein Benchmark, den Du architekturübergreifend verwenden kannst. Er lässt nur Vergleiche
> 
> zwischen gleichen Prozessor-Architekturen zu und ist nur noch
> 
> im Kernel, weil ihn die Leute so toll finden

 

 *Shadows wrote:*   

> @Donnergurgler
> 
> Das war auch nicht wirklich als "Benchmark" zu verstehen  Mir ist auch klar, dass hier die ganzen Prozessoreigenschaften wie Befehlssätze, Architektur  und ähnliches nicht mit berücksichtigt sind 
> 
> Aber der Wert ist doppelt so hoch, was bei fast doppelt so viel MHz eigentlich auch zu erwarten ist.

 

Ist eigentlich schon mal jemandem aufgefallen, daß die BogoMips im Prinzip nur "CPU-Frequenz mal zwei" ist? War zumindest bei allen Systemen so, die mir über den Weg gelaufen sind (100MHz bis 2,4GHz).

Von dem her kann man mit dem Wert eigentlich nur die Frequenzen vergleichen.

----------

## amne

Guckst du hier: Bogomips + I'm feeling lucky  :Wink: 

----------

