FDIV

[aths]

Wie viel Takte kostet es auf einer modernen CPU, einen Single durch einen Single zu dividieren? Mich interessiert nicht die Latenz :) sondern die Zahl der "effektiven" Takte.

[zeckensack]

Netburst/x87: 23 Takte
Netburst/skalares SSE: 22 Takte
Netbust/Vektor-SSE: 32 Takte (vier Ergebnisse)
K8/x87: 16 Takte
K8/skalares SSE: 16 Takte
K8/Vektor-SSE: 33 Takte (vier Ergebnisse)
K7/x87: 16 Takte
K7/skalares SSE: 16 Takte
K7/Vektor-SSE: 29 Takte (vier Ergebnisse)

Bei Netburst ist sogar dokumentiert, dass die Latenz 23 Takte ist und ebenfalls nur alle 23 Takte eine Division gestartet werden kann. Dh es gibt kein Pipelining für aufeinanderfolgende Divisionen.
Beim K7 und K8 habe ich so eine klare Aussage nicht gefunden. Die angegebenen Werte sind die reine Ausführungslatenz. Der Verdacht liegt allerdings nahe, dass es ähnlich wie bei Netburst läuft.

Mit 3DNow! lässt sich eine Division wahrscheinlich pipelinen (ist das ein Verb? :ugly:).

[BlackBirdSR]

Der K7 kann anscheinend alle 13 Takte eine neue Divison starten
http://www.aceshardware.com/read.jsp?id=85

[aths]

Netburst/x87: 23 Takte
Netburst/skalares SSE: 22 Takte
Netbust/Vektor-SSE: 32 Takte (vier Ergebnisse)
K8/x87: 16 Takte
K8/skalares SSE: 16 Takte
K8/Vektor-SSE: 33 Takte (vier Ergebnisse)
K7/x87: 16 Takte
K7/skalares SSE: 16 Takte
K7/Vektor-SSE: 29 Takte (vier Ergebnisse)

Bei Netburst ist sogar dokumentiert, dass die Latenz 23 Takte ist und ebenfalls nur alle 23 Takte eine Division gestartet werden kann. Dh es gibt kein Pipelining für aufeinanderfolgende Divisionen.
Beim K7 und K8 habe ich so eine klare Aussage nicht gefunden. Die angegebenen Werte sind die reine Ausführungslatenz. Der Verdacht liegt allerdings nahe, dass es ähnlich wie bei Netburst läuft.

Mit 3DNow! lässt sich eine Division wahrscheinlich pipelinen (ist das ein Verb? :ugly:).*Übelst hust*

Jede aktuelle CPU kann doch pro Takt ein komplettes MAD auch mit FP ausführen, oder nicht? FDIV ist immer noch ca. eine Größenordnung (Faktor 10, hier eher Faktor 20, ich progge ohne SSE) teurer??

Wird FDIV für Single zu beschleunigt, oder intern noch immer mit Extended gerechnet egal welches Zielformat gewünscht ist?

[zeckensack]

*Übelst hust*

Jede aktuelle CPU kann doch pro Takt ein komplettes MAD auch mit FP ausführen, oder nicht? FDIV ist immer noch ca. eine Größenordnung (Faktor 10, hier eher Faktor 20, ich progge ohne SSE) teurer??Ja, quasi. Division ist auch ein ganz klitzekleines Quäntchen komplizierter :|
Wird FDIV für Single zu beschleunigt, oder intern noch immer mit Extended gerechnet egal welches Zielformat gewünscht ist?Da wird schon optimiert. Ich hab's für single precision angegeben. Bei double oder ep wird's noch langsamer (K8: 16/20/24 Takte; NB: 23/38/43 Takte).

Btw, ich habe jetzt mal die 3DNow!-Lösung nachgesehen, und da geht's tatsächlich etwas besser.;mm0:= 0 | w
PFRCP MM1, MM0 ;1/w | 1/w (approx.)
PUNPCKLDQ MM0, MM0 ;w | w (MMX instruction)
PFRCPIT1 MM0, MM1 ;1/w | 1/w (intermed.)
MOVQ MM2, [mem] ;y | x
PFRCPIT2 MM0, MM1 ;1/w | 1/w (full prec.)
PFMUL MM2, MM0 ;y/w | x/wDie Gesamtlatenz für diese Division ist 15 Takte. Wenn man viele Divisionen braucht, und den Code perfekt anordnet, müsste man alle vier Takte so eine Division starten können.

[aths]

Ja, quasi. Division ist auch ein ganz klitzekleines Quäntchen komplizierter :|RCP-Lookup und dann MUL? Der NV40 kann alleine im Pixelshader pro Takt 16 Divisionen ausführen, immerhin mit FP32 (ohne Denorms allerdings.)

[Coda]

RCP-Lookup und dann MUL?Zu ungenau. IEEE754 erfordert mehr Präzision.
Außerdem hat die Grafikkarte wohl eine deutlich tiefere Pipeline.

[zeckensack]

RCP-Lookup und dann MUL? Der NV40 kann alleine im Pixelshader pro Takt 16 Divisionen ausführen, immerhin mit FP32 (ohne Denorms allerdings.)Grobe Näherung ...
Wenn du mit 14 signifikanten Mantissenbits zufrieden bist, kann ein Athlon alle zwei Takte eine "Division" starten (bzw ein PFRCP/PFMUL-Paar), und ist nach sieben Takten fertig.

[aths]

Grobe Näherung ...
Wenn du mit 14 signifikanten Mantissenbits zufrieden bist, kann ein Athlon alle zwei Takte eine "Division" starten (bzw ein PFRCP/PFMUL-Paar), und ist nach sieben Takten fertig.Das klingt doch schon ganz anders :) Zur Umrechnung von Byte 0..255 nach FP 0..1 wäre das wahrscheinlich genau genug. Aber diese Befehle werden wohl kaum über Delphi ansprechbar sein, ohne ASM zu nutzen.

Kann man in Functions, wenn man ASM nutzt, einfach auf die übergebenen Parameter zugreifen oder muss man die umständlich mit irgendeiner Adressrechnung holen? Gibts PFRCP und PFMUL auch auf dem Pentium?

[zeckensack]

Das klingt doch schon ganz anders :) Zur Umrechnung von Byte 0..255 nach FP 0..1 wäre das wahrscheinlich genau genug. Aber diese Befehle werden wohl kaum über Delphi ansprechbar sein, ohne ASM zu nutzen.Sag' das doch gleich :|
Division durch eine Konstante ist ganz einfach durch Multiplikation mit dem Kehrwert ersetzbar. IMO macht das jeder ernsthafte Compiler automatisch. Das brauchst du nichtmal explizit zu machen, aber in C ginge es so:float rumms=bumms/255.0f;
<=>
static const float fixed_to_float8=1.0f/255;
float rumms=bumms*fixed_to_float8;
Kann man in Functions, wenn man ASM nutzt, einfach auf die übergebenen Parameter zugreifen oder muss man die umständlich mit irgendeiner Adressrechnung holen?Sowohl als auch, obwohl unterschiedliche Compiler unterschiedlich guten Support von Inline-ASM haben. Im Zweifelsfall sollte man sich zumindest ansatzweise mit "calling conventions" auskennen. Klack (http://www.cs.cornell.edu/courses/cs412/2001sp/resources/microsoft-calling-conventions.html).
Gibts PFRCP und PFMUL auch auf dem Pentium?Nein. Die beiden sind Bestandteile des 3DNow!-Pakets.

edit: SSE enthält RCPSS, was quasi das gleiche ist wie PFRCP (~14 signifikante Bits).
Es gibt bei SSE leider keine speziellen Instruktionen für Newton-Rhapson-Iterationen, da muss man selbst Hand anlegen (den Trick habe ich noch nicht durchschaut).

[Asmodeus]

Hmm, wenn es vorallem um Geschwindigkeit geht und wirklich nur 0...255 nach 0.0 ... 1.0 umgerechnet werden sollen, was spricht da gegen ne simple LookUp-Table? Oder soll der Zahlenbereich doch größer sein?

Gruss, Carsten

[Coda]

Division durch eine Konstante ist ganz einfach durch Multiplikation mit dem Kehrwert ersetzbar. IMO macht das jeder ernsthafte Compiler automatisch.Nein. Das darf er nicht, weil das Ergebnis ungenauer wäre, deshalb ist dass immer noch etwas wo man mitdenken sollte.

[aths]

Hmm, wenn es vorallem um Geschwindigkeit geht und wirklich nur 0...255 nach 0.0 ... 1.0 umgerechnet werden sollen, was spricht da gegen ne simple LookUp-Table?Die Kosten eines Speicherzugriffes.

[Asmodeus]

Die Kosten eines Speicherzugriffes.

Naja, wie viel Takte kostet z.B. der Zugriff auf ein Element, das im Cache liegt?

Gruss, Carsten.

[aths]

Naja, wie viel Takte kostet z.B. der Zugriff auf ein Element, das im Cache liegt?Weniger als ein FMUL? Nur dann würde es ja lohnen.

[micki]

Nein. Das darf er nicht, weil das Ergebnis ungenauer wäre, deshalb ist dass immer noch etwas wo man mitdenken sollte.
das hängt wie so oft von den compilerflags ab, aber an sich hast du recht, es wäre zu ungenau um defaultmässig gemacht zu werden.

MfG
micki

[micki]

Weniger als ein FMUL? Nur dann würde es ja lohnen.
wieviele werte mußt du denn umrechnen, dass es dir so sehr um das letzte Hz geht? :D

MfG
micki

btw. es kann schneller sein als ein FMUL wenn du noch zwischen int/byte udn float konvertieren müßtest.

[aths]

wieviele werte mußt du denn umrechnen, dass es dir so sehr um das letzte Hz geht? :DIst jetzt unwichtig, da ich den Vortrag für die Verteidigung des Großen Beleges eh erheblich (um 60%) kürzen muss. Darf maximal 20 Minuten lang sein :(.

[Jesus]

Nein. Das darf er nicht, weil das Ergebnis ungenauer wäre, deshalb ist dass immer noch etwas wo man mitdenken sollte.

Wieso?

[Coda]

Wieso er es nicht darf oder wieso die Berechnung ungenauer wird?

[Jesus]

Wieso er es nicht darf oder wieso die Berechnung ungenauer wird?

Wieso ers nicht darf, so häufig wirds nicht ungenauer und er verliert maximal 1 bit in der Mantisse.

[Coda]

Hmm ich hab nochmal nachgeschaut. Der Standard stellt anscheinend keine Anforderungen an das.
Aber irgendwo hab ich mal gelesen dass zumindest MSVC es trotzdem bleiben lässt, weil es bei mehreren Divisionen dann schon zu stärkeren Abweichungen kommen könnte.

[micki]

das kann der standard auch nicht wirklich festlegen (jedenfalls nicht iso-c++), weil es ja von der cpu/fpu abhäng und es gibt wohl einige die keine division haben.

mfg
micki