Pipeline des P4
-
Hallo,
wie kann ich verhinden (ausser vielleicht durch Inline-Assembler), dass die Pipeline nach dem Schalten des Rundungsmodus (Pentium 4) leer läuft?
Gruß
Boris
-
gar nicht - der prozessor macht das ja nicht aus spass an der freude. am besten unterlässt du es, damit herumzuspielen - oder du machst es global. der p4 is optimiert zwischen zwei rundungsmodi schnell umzuschalten - eine davon braucht C immer (truncate) um konvertierungen in ints zu ermöglichen. d.h. jedes andere umschalten (i.d.r. von round-to-nearest weg) wird also immer den besagten effekt auslösen.
Es sei noch darauf hingewiesen, dass der P4 nicht allein mit diesem problem ist - da der trend aber ohnehin zu sse/2 geht, spielt die problematik keine besonders grosse rolle.
-
camper schrieb:
gar nicht - der prozessor macht das ja nicht aus spass an der freude. am besten unterlässt du es, damit herumzuspielen - oder du machst es global. der p4 is optimiert zwischen zwei rundungsmodi schnell umzuschalten - eine davon braucht C immer (truncate) um konvertierungen in ints zu ermöglichen. d.h. jedes andere umschalten (i.d.r. von round-to-nearest weg) wird also immer den besagten effekt auslösen.
Ob Du es glaubst oder nicht, es gibt Anwendungsbereiche in denen schnelle Rundungsmodi-Wechsel durchaus Sinn machen.
Was meinst Du mit global?camper schrieb:
Es sei noch darauf hingewiesen, dass der P4 nicht allein mit diesem problem ist - da der trend aber ohnehin zu sse/2 geht, spielt die problematik keine besonders grosse rolle.
Ok, aber wie bekomme ich zwei Gleitkommzahlen mittels SSE/2 multipliziert?
Sollte jemand aber ein P2 oder ein K6 verwenden, klemme ich diese ab.
-
hjdt schrieb:
camper schrieb:
gar nicht - der prozessor macht das ja nicht aus spass an der freude. am besten unterlässt du es, damit herumzuspielen - oder du machst es global. der p4 is optimiert zwischen zwei rundungsmodi schnell umzuschalten - eine davon braucht C immer (truncate) um konvertierungen in ints zu ermöglichen. d.h. jedes andere umschalten (i.d.r. von round-to-nearest weg) wird also immer den besagten effekt auslösen.
Ob Du es glaubst oder nicht, es gibt Anwendungsbereiche in denen schnelle Rundungsmodi-Wechsel durchaus Sinn machen.
Was meinst Du mit global?du misverstehst mich. nat. gibt es diverse stellen an denen man den modus wechseln möchte/sollte/muss. da aber bereits zwei modi vom compiler gebraucht werden, wird ein dritter modus stets den beschriebenen effekt haben (der prozessor kann immer nur schnell in den vorher aktiven modus umschalten). brauchst du als einen dritten modus und ist die geschichte zeitkritisch, dann musst du entweder den modus einmal ändern (und damit in kauf nehmen, das die standardrundungspolicy von round-to-nearest sich im ganzen programm (bzw. thread) ändert und gegebenenfalls fehlerhafte ergebnisse produziert), oder den gesamten code, der diesen anderen modus benötigt konzentrieren, um die anzahl der wechsel zu minimieren.
camper schrieb:
Es sei noch darauf hingewiesen, dass der P4 nicht allein mit diesem problem ist - da der trend aber ohnehin zu sse/2 geht, spielt die problematik keine besonders grosse rolle.
Ok, aber wie bekomme ich zwei Gleitkommzahlen mittels SSE/2 multipliziert?
Sollte jemand aber ein P2 oder ein K6 verwenden, klemme ich diese ab.per optimierung oder - im falle von assemblerroutinen sinnvoll - indem du mehrere codepfade anbietest, die dann zur laufzeit ausgewählt werden (global per aufruf über einen pointer den du zu programmbeginn entsprechend den fähigkeiten des prozessors initialisierst).
-
camper schrieb:
da aber bereits zwei modi vom compiler gebraucht werden, wird ein dritter modus stets den beschriebenen effekt haben (der prozessor kann immer nur schnell in den vorher aktiven modus umschalten). brauchst du als einen dritten modus und ist die geschichte zeitkritisch, dann musst du entweder den modus einmal ändern (und damit in kauf nehmen, das die standardrundungspolicy von round-to-nearest sich im ganzen programm (bzw. thread) ändert und gegebenenfalls fehlerhafte ergebnisse produziert), oder den gesamten code, der diesen anderen modus benötigt konzentrieren, um die anzahl der wechsel zu minimieren.
Da hat der AMD einen Vorteil, bei jeder Modi-Änderung speichert er das entsprechende Flag und somit muss die Pipeline nicht leer laufen. Ich frage mich warum das Intel nicht tut. Das sehe ich eher als optimal an. Aber das ist ein anderes Thema. In meinem Fall ist es mit dem Konzentrieren so ein Sache. Das haut leider nicht hin und falsch dürfen die Ergebnisse auch nicht werden, deshalb brauche ich eine Vielzahl von Modi-Wechseln.
camper schrieb:
Ok, aber wie bekomme ich zwei Gleitkommzahlen mittels SSE/2 multipliziert?
Sollte jemand aber ein P2 oder ein K6 verwenden, klemme ich diese ab. per optimierung oder - im falle von assemblerroutinen sinnvoll - indem du mehrere codepfade anbietest, die dann zur laufzeit ausgewählt werden (global per aufruf über einen pointer den du zu programmbeginn entsprechend den fähigkeiten des prozessors initialisierst).Mittels SSE/2 habe ich ein paar Routinen implementiert und musste feststellen,
dass auf einem AMD64 dieser Code 40% langsamer ist als ordinäre FPU-Befehle.
-
camper schrieb:
der p4 is optimiert zwischen zwei rundungsmodi schnell umzuschalten
Echt? Das hab ich noch nie gelesen... Wäre zwar nicht unvernünftig, aber die FPU ist beim P4 soundso unbrauchbar langsam. Und wirklich schnell ist das Umschalten sicher auch nicht, es ist nur vielleicht nicht ganz so gähnend langsam wie bei früheren FPUs.