# AMD Phenom II X4 - FX-4300 und 3dnow!

## Erdie

Ich bin von Phenom II X4 auf FX-4300 migriert. IMHO unterstürzt der FX 3dnow! nicht mehr, welches ich aber als Flag in der make.conf stehen habe. 

1. Muß ich neucompilieren oder wird das einfach ignoriert?

2. Was bedeutet  das flag "3dnowprefetch", welches unter  /proc/cpuinfo erscheint?

Danke

Erdie

----------

## Klaus Meier

Du löscht das Flag aus der make.conf und machst ein emerge -uDN world.

----------

## franzf

 *Klaus Meier wrote:*   

> Du löscht das Flag aus der make.conf und machst ein emerge -uDN world.

 

Tjo, wenns nur ein USE-Flag wär wäre das die Lösung. Aber hier geht es wohl um CFLAGS, die evtl. sogar automatisch über den march angeschalten wurden. Da hilft mMn. nur ein emerge -e world. Keine Ahnung ob das so ohne weiteres nach dem CPU-Tausch noch geht...

----------

## Klaus Meier

Na wenn er die Kiste booten kann, dann wird es wohl gehen... Denke mal, der gcc wird kein 3dnow verwenden.

----------

## Erdie

Die Cflags habe ich schon gändert. Der Rechner funktioniert seit Tagen problemlos obwohl ich (noch) nichts kompiliert habe. Aber es ist  richtig, dass eine mit USE=3DNow! kompiliertes binary theoretisch auf einer CPU ohne 3DNow! Prolbeme bereiten sollte?

Es steht sowieso eine Switch von GCC 4.7 nach 4.8 an. Da kann man das doch gleich verbinden.

----------

## Klaus Meier

Ändern des Flags ohne Kompilieren bringt dir erst mal gar nichts. Was hast du denn bei -march gesetzt?

Des weiteren wird jetzt das Flag ja nur von einigen wenigen Paketen berücksichtigt. Es wird nur im Bereich Multimedia verwendet, es sollte eigentlich alles wichtige laufen. Wenn eine Anwendung diesen Code enthält und dieser Code wird von einer CPU ohne 3dnow Einheit ausgeführt, dann bumm.

Du solltest auf alle Fälle ein emerge -uDN world machen. Ob 3dnow Code per default ohne dieses Flag erzeugt wurde, kann ich so nicht sagen. Solltest du Abstürze bekommen, wäre ein emerge -e world angebracht.

----------

## Erdie

 *Klaus Meier wrote:*   

> Ändern des Flags ohne Kompilieren bringt dir erst mal gar nichts. Was hast du denn bei -march gesetzt?
> 
> 

 

Das ist schon klar  :Wink:  ich habe für -march die Angaben für save cflags gesetzt, wie sie im wiki stehen. Dannach war mein Plan, im Laufe der  Updatezyklen  alles nach und nach zu bauen, da ich bei der CPU Abwärtskompatibilitt vermutet habe. Bei 3DNow scheint das nicht so zu sein. Mich wundert nur, das ffmpeg definitiv funktionierte, obwohl es mit 3DNow Unterstützung gebaut war. Ich möchte nur verstehen, warum das so ist. Nach meinem Verständnis hätte zumindest ffmpeg crashen müssen. Es funktioniert aber offenbar alles und ich habe keine Erklärung dafür.

----------

## franzf

Mach mal cat /proc/cpuinfo und schau nach nem 3dnow in den flags, vielleicht wird es ja doch noch unterstützt.

USE=3dnow (oder sse oder avx) aktivieren meist eigene optimierte Codepfade: Besimmte Funktionen werden dann direkt in Assembler geschrieben. Normalerweise wird aber bei der Ausführung geschaut ob die CPU das überhaupt unterstützt.

Mit 3dnow in den CFLAGS entscheidet der Compiler, welchen Stellen er die entsprechenden Befehle spendiert. Ich kann mir sehr gut vorstellen, dass der GCC da einfach direkt SSE(x) Befehlssätze nimmt. Kann der alte Phenom ja, und AFAIK sogar den AVX.

----------

## py-ro

3dnow ist eine sub optimale Erweiterung, deine CPU wird auch die diversen SSE Varianten kennen, die alle samt schneller sind, daher wird vermutlich in ffmpeg da wo optimierter code genutzt wird eher diese verwendet.

Bye

Py

----------

## Erdie

@Py-ro

das könnte ein Erklärung sein. Unter /proc/cpuinfo finde ich nur

3dnowprefetch und diverse sse Varianten bis sse4. Die habe ich jetzt alle gesetzt. Der Rechner macht  jetzt ein -e world, da ich auf gcc 4.8.* umgestiegen bin. Dabei wird alles andere gleich mit erschlagen.

P.S: Deshalb auch meine Frage, was 3dnowprefetch sein soll, ein USE Flag in der der Art gibt es nicht.

----------

## Erdie

-e @world lief überigens einwandfrei durch. Sowas hatte ich noch nie. Irgendwas hakt sonst immer. Das ist doch schon mal erste Sahne.

@Franz: Der Phenom kann bis sse3. Mit dem FX ist noch sse4 dazugekommen.

----------

## Klaus Meier

Mach dir doch jetzt keinen Stress... Was ist wichtiger? Dass es problemlos läuft oder dass du weißt, warum  :Rolling Eyes:   :Rolling Eyes:   :Rolling Eyes: 

----------

## franzf

 *Klaus Meier wrote:*   

> Mach dir doch jetzt keinen Stress... Was ist wichtiger? Dass es problemlos läuft oder dass du weißt, warum   

 

Dass er weiß warum, denn diese Erkenntnis hilft ihm vielleicht später weiter.

(Meine Meinung, ich doktor auch gern an Problemen rum, die sich irgendwann auf magische Weise von selbst gelöst haben - steckt auch oft ein fieser Bug dahinter  :Wink: )

----------

## Klaus Meier

Ok, in diesem Fall ist es wohl gar nicht so schwer. Der gcc erzeugt keinen 3dnow Code, wenn eine bessere sse-Einheit verfügbar ist.

----------

## kurisu

 *franzf wrote:*   

>  *Klaus Meier wrote:*   Mach dir doch jetzt keinen Stress... Was ist wichtiger? Dass es problemlos läuft oder dass du weißt, warum :roll:  :roll:  :roll: 
> 
> Dass er weiß warum, denn diese Erkenntnis hilft ihm vielleicht später weiter.
> 
> (Meine Meinung, ich doktor auch gern an Problemen rum, die sich irgendwann auf magische Weise von selbst gelöst haben - steckt auch oft ein fieser Bug dahinter ;))

 

+1

Gewiss verkörpert Erstzitiertes zweifellos einen pragmatischen Ansatz, nichtsdestominder ergibt sich daraus eine interessante Technik der Deduktion. Denn nicht zuletzt bin ich gerade deshalb bei Gentoo, weil ich gerne genau wissen möchte, weshalb etwas nicht funktioniert. Aber jedem, wie ihm beliebt.

----------

## Klaus Meier

Du hast ja Recht mit deiner Aussage, aber sie trifft auf den Fall von Erdie nicht zu. Du willst wissen, warum etwas nicht geht. Dagegen ist ja nichts einzuwenden. Erdie wollte aber wissen, warum es geht. Das ist etwas anderes,   :Rolling Eyes:   :Rolling Eyes:   :Rolling Eyes: 

Und ich sagte ja auch nicht, dass es irrelevant ist, ich sagte, es ist wichtiger, dass es funktioniert.

----------

## franzf

Zwei kleine Beispiele:

```
#include <iostream>

void pre_test() {

    int x = 0x12345678;

}

void test() {

    int x;

    while(x++ < 10)

        std::cout << x << '\n';

}

int main() {

    pre_test();

    test();

}
```

Abspeichern als test1.cpp, kompilieren mit

```
g++ -O2 test1.cpp -o test1
```

Ausführen mit ./test1.

Ausgabe:

```
1

2

3

4

5

6

7

8

9

10
```

Also alles klar geht ja  :Smile: 

Dann lass beim Kompilieren das "O2" weg und schon gibt das Programm keinen Muckser mehr von sich.

Hintergrund: int x in test() ist nicht korrekt initialisiert ("default initialized"). Der Optimierer führt zero-initialization durch, was zu dem erwarteten Ergebnis führt. Ohne Optimierer erhält x den Wert der gerade im Speicher liegt. Der ist recht sicher größer als 10, dadurch ist die Bedingung "x < 10" immer falsch.

Zweites Beispiel:

```
#include <iostream>

struct Test {

    int x;

};

int main() {

    Test *t = new Test;

    delete t;

    t->x = 6;

    std::cout << t->x << '\n';

}
```

Spechern als test2.cpp, Kompilieren wie oben (mit oder ohne O2 ist hier wurscht).

Wunderbar, das funktioniert. Gibt "6" aus.

Dann eine kleine Änderung:

```
#include <iostream>

struct Test {

    int x;

};

int main() {

    Test *t = new Test;

    delete t;

    Test *t2 = new Test;

    t2->x = 500;

    t->x = 6;

    std::cout << t2->x << '\n';

}
```

Erwartete Ausgabe: 500. Gibt aber immer noch 6 aus.   :Shocked: 

(g++ -fsanitize=address erstellt ein binary das bei solchen ungültigen Speicherzugriffen die Ausführung abbricht)

Das war zweimal "undefined behaviour". Oft geht sowas gut, aber ändert man was (Compileroptionen, Code) geht es plötzlich nicht mehr. Ich hab das schon ein paarmal gesehen, dass sich (vor allem unerfahrene Programmierer) da wenig sagen lassen. "Geht doch". Und in diesen Fällen ist es wirklich gut zu wissen WARUM es vielleicht geht (automatische zero initialization, Zugriff auf zufälligerweise noch validen Speicher).

Genauso ist es gut zu wissen dass SSE >>> 3dnow, und dass es am Ende vielleicht doch Multimediaanwendungen gibt, die crashen könnten (wenn handoptimiert und kein runtime-check)  :Wink: 

----------

## Child_of_Sun_24

Der FX4300 (Wie alle Prozessoren aus der Serie) emulieren 3dnow falls entsprechende Flags gesetzt sind, dadurch wird die Codeausführung "verlangsamt" ob das jetzt spürbar ist oder nicht kann ich dir nicht sagen.

-march kannst du ruhig auf bdver2 stellen (Piledriver) und die 3dnow Option nimmst du raus, nach und nach werden dann die wichtigsten Pakete beim wöchentlichem/monatlichem emerge world -avuDN --with-bdeps=y  :Very Happy:  auf die neuen Flags umgestellt. Es ist also nicht wirklich notwendig alles sofort neu zu kompilieren.

----------

## Erdie

 *Child_of_Sun_24 wrote:*   

> Der FX4300 (Wie alle Prozessoren aus der Serie) emulieren 3dnow falls entsprechende Flags gesetzt sind, dadurch wird die Codeausführung "verlangsamt" ob das jetzt spürbar ist oder nicht kann ich dir nicht sagen.
> 
> -march kannst du ruhig auf bdver2 stellen (Piledriver) und die 3dnow Option nimmst du raus, nach und nach werden dann die wichtigsten Pakete beim wöchentlichem/monatlichem emerge world -avuDN --with-bdeps=y  auf die neuen Flags umgestellt. Es ist also nicht wirklich notwendig alles sofort neu zu kompilieren.

 

Genauso habe ich es gemacht. Und da  gerade die Umstellung von gcc 4.7 auf 4.8 auf dem Plan stand, habe ich doch gleich alles kompiliert. Wenn das durchläuft ist es ja kein Akt. Kostet etwas Strom und eine Nacht +  1/2 Tag. 

bdver2 hatte ich laut Wiki benutzt. CPUinfo bringt auch Ver. 2 

Die Umstellung auf FX hat es allein schon wegen 30W weniger Leistungsaufnahme gebracht, selbst wenn hinterher nichts schneller war.

Danke nochmal an alle

Grüße

Erdie

----------

