SSE3 = 4x FP32-MAD pro Takt?

[aths]

Kann eine SSE3-Singlecore-CPU 4x FP32-MADs pro Takt berechnen?

[Demirug]

Der Befehlssatz schreibt nicht vor wie schnell es ausgeführt werden muss.

[zeckensack]

Nein.
Das dauert mindestens zwei Takte. Wenn du nur einen 4er-Vektor produzierst, dauert es mindestens acht Takte.

[aths]

Also ich will die G70-MAD-Leistung mit SSE3 vergleichen. Bei (kaufbaren) SSE3-CPUs kann ich also gerade mal zwei FP32-MADs pro Takt ansetzen?? (Eine einzelne G70-Pixelquadpipe kommt ja auf 32 MADs pro Takt.)

[micki]

soweit ich weiß: ein P4 kann pro takt 2mul und 2add durchfühern, für ein MAD auf ein float4 müßte der P4 also zwei takte verschwenden.
soweit ich weiß können die bestehenden altivec ein float4-MAD pro takt.

MfG
micki

[aths]

soweit ich weiß: ein P4 kann pro takt 2mul und 2add durchfühern, für ein MAD auf ein float4 müßte der P4 also zwei takte verschwenden.Float4 = Float mit 4 Byte, also FP32? Sprichst du von einem P4 der (mindestens) SSE2 nutzt?

[BlackBirdSR]

Also ich will die G70-MAD-Leistung mit SSE3 vergleichen. Bei (kaufbaren) SSE3-CPUs kann ich also gerade mal zwei FP32-MADs pro Takt ansetzen?? (Eine einzelne G70-Pixelquadpipe kommt ja auf 32 MADs pro Takt.)

Ich weiss nicht ob man den Vergleich so gut ansetzen kann.
Verglichen mit einem Chip wie dem G70 sind CPUs wirklich sehr schwachbrüstig. Aber das hat eben auch seine Gründe.

Selbst Monster wie ein IA64 kommen da nicht annähernd auf diese Durchsatzwerte.

[micki]

Float4 = Float mit 4 Byte, also FP32? Sprichst du von einem P4 der (mindestens) SSE2 nutzt?

mit float4 meinte ich den datentyp von hlsl bzw glsl, weil du ja auch mit der gpu vergleichen möchtest, und die schaft ja auch nur soviel MAD weil sie mit float4 arbeitet... wenn man nur float(1) nehmen würde, würde der p4 ja theoretisch 0.5hz pro instruction brauchen, weil er out of order arbeiten kann und mehr als nur einen befehl pro takt fetched bzw dispatched. wogegen die gpu soweit ich weiß trotzdem nur 1befehl pro takt macht (pro pipe).

und ich spreche von jedem p4, da hat sich eigentlich nichts an der anzahl der verarbeitenden einheiten geändert soweit ich weiß. am dispatcher und prefetch usw. öfter mal, aber das ist bei SSE eigentlich nie so ausschalggebend, da die befehle die mul und add einheiten gut auslasten (wenn die daten schnell genug kommen).

wenn du fpu/sse/gpu vergleichen möchtest, frag scottmandeath, der schreibt darüber ne dipl arbeit und hat in letzter zeit wohl schon MAD-dreams :)

aber wie gesagt, schau dir mal AltiVec an, das sollte bei MAD ein sehr viel fixerer papiertiger sein.

MfG
micki

[Ganon]

aber wie gesagt, schau dir mal AltiVec an, das sollte bei MAD ein sehr viel fixerer papiertiger sein.

Naja. Dazu braucht er ja auch ne PowerPC-CPU dafür. ;)

Altivec-mäßig (wobei a, b und c beliebige Vector-Floats z.B. {1.0, 2.0, 3.0, 4.0} sind) :

Also aus C-Code:

a = vec_madd(a,b,c)

macht der Compiler folgenden Assembler-Code:

vmaddfp v0,v13,v1,v0

Ob das nun intern irgendwie über 20 Takte verarbeitet wird, weiß ich jetzt nicht. ;) Sooo tief stecke ich in der CPU-Geschichte nicht drinnen. Wollte nur ein Beispiel liefern. :)

Will jetzt auch keinen Altivec vs. SSE Thread anfangen. ;) Das hatten wir schon ein paar mal. ;)

edit: JUHU. Mein 2000ster Beitrag. *freu* ;)

[micki]

gratuliere ;)




streiten muss man sich da wirklich nicht, man findet ja massenweise gute informationen zu Altivec:

http://developer.apple.com/hardware/ve/instruction_crossref.html
http://developer.apple.com/hardware/ve/throughput_vs_latency.html <--*selberstaun*

MfG
micki

[aths]

Also jedes Posting hier verwirrt mich nur immer weiter.

- Ich denke, weil MAD so häufig ist, bieten handelsübliche CPUs MAD in einem Takt. Ist das richtig oder irre ich?

- Mit SIMD-Mechanismen á la SSE (ob nun 1, 2 oder 3) kann man ganze Vektoren berechnen. SSE ist soweit ich weiß 128 Bit breit und müsste dann einen 4D-Vektor aus 4x Single als Datentyp kennen. Stimmt das?

- Außerdem hoffe ich doch, dass MAD auch bei SSE nur ein Takt braucht. Ist das korrekt, oder braucht man wirklich 2 Takte (nämlich einen für MUL, einen für ADD?)

[Coda]

- Ich denke, weil MAD so häufig ist, bieten handelsübliche CPUs MAD in einem Takt. Ist das richtig oder irre ich?Du irrst. x86 hat keine MAD Instruction, nichtmal SSE.

- Mit SIMD-Mechanismen á la SSE (ob nun 1, 2 oder 3) kann man ganze Vektoren berechnen. SSE ist soweit ich weiß 128 Bit breit und müsste dann einen 4D-Vektor aus 4x Single als Datentyp kennen. Stimmt das?Korrekt.

- Außerdem hoffe ich doch, dass MAD auch bei SSE nur ein Takt braucht. Ist das korrekt, oder braucht man wirklich 2 Takte (nämlich einen für MUL, einen für ADD?)Siehe Punkt 1. Es gibt auch kein Dot Product.

Ach übrigens würde ich bei den Latenzen vorsichtig sein. Bei 3Ghz ist 1 Cycle/Op deutlich schwerer zu erreichen als bei "nur" 400-500Mhz.

[aths]

Also braucht man für 2x MAD in FP32 (im best-case) im Schnitt 1 Takt. Ok.

[zeckensack]

- Mit SIMD-Mechanismen á la SSE (ob nun 1, 2 oder 3) kann man ganze Vektoren berechnen. SSE ist soweit ich weiß 128 Bit breit und müsste dann einen 4D-Vektor aus 4x Single als Datentyp kennen. Stimmt das?Ja. Aber:
Sowohl Netburst wie auch der K8 (und der K7, und der P6) splitten SSE-Operationen horizontal auf. Deswegen kriegt man ein MUL über Vierer-Vektoren bestenfalls alle zwei Takte fertig.
(man kann natürlich parallel dazu noch andere SSE-taugliche ALUs beschäftigen, falls die Hardware solche hat)

Oder mal ganz konkret:
K8/SSE: maximal 4 FP32-FLOPs/Takt (2xMUL+2xADD, FSTORE zählt nicht)
P4/SSE: das selbe
K8/3DNow!: das selbe
K7/SSE: das selbe
K7/3DNow!: das selbe
P6/SSE: weiß ich nicht

[aths]

Ich habs jetzt so geschrieben:

"Eine übliche Single-Core CPU berechnet je nach Typ pro Takt bis zu zwei MAD-Operationen in FP32-Genauigkeit. Da schafft eine einzelne Pixelpipeline schon doppelt so viel, da es ja vier Kanäle (R, G, B und A) gibt. Eine G70-Pipe bringt nun 2x MAD pro Pixelpipe und hat 24 davon – das sind 192 MADs pro Takt im Pixelshader. Der Vertexshader kann weitere 32 MADs beisteuern, so dass der G70 224 MADs pro Takt ermöglicht. Das ist 112x mal mehr als eine gängige CPU. Eine Dualcore-CPU müsste demnach mit über 24 GHz laufen, um die gleiche maximale MAD-Leistung zu bringen. Allerdings ist die CPU eben auf das Ausführen von "richtigen" Programmen optimiert, während die GPU auf das Bearbeiten von Datenströmen ausgelegt wurde, das heißt, die volle Rechenkraft zur Entfaltung zu bringen wird bei einer GPU schwieriger als auf einer CPU."

[BlackBirdSR]

das heißt, die volle Rechenkraft zur Entfaltung zu bringen wird bei einer GPU schwieriger als auf einer CPU


Ich finde eher das Gegenteil ist der Fall. Oder hast du das nur verdreht?
Gerade CPUs laufen durch das ganze Dekodieren, Branchen und all die Abhängigkeiten ständig mit ungenutzen Resourcen.
Das ist der Grund, warum SMT beim Power5 z.B so viel bringt.

Von den theoretischen 3µops/takt kommt der P4 in SpecFP so ca auf 0.65µops/takt.

Ich weiss nicht, wie es bei GPUs genau läuft, aber kommen die durch die ganze Parallelität und festgelegten Datenströme nicht näher an ihr Maximum?

[RLZ]

Ich habs jetzt so geschrieben:

"Eine übliche Single-Core CPU berechnet je nach Typ pro Takt bis zu zwei MAD-Operationen in FP32-Genauigkeit. Da schafft eine einzelne Pixelpipeline schon doppelt so viel, da es ja vier Kanäle (R, G, B und A) gibt. Eine G70-Pipe bringt nun 2x MAD pro Pixelpipe und hat 24 davon – das sind 192 MADs pro Takt im Pixelshader. Der Vertexshader kann weitere 32 MADs beisteuern, so dass der G70 224 MADs pro Takt ermöglicht. Das ist 112x mal mehr als eine gängige CPU. Eine Dualcore-CPU müsste demnach mit über 24 GHz laufen, um die gleiche maximale MAD-Leistung zu bringen. Allerdings ist die CPU eben auf das Ausführen von "richtigen" Programmen optimiert, während die GPU auf das Bearbeiten von Datenströmen ausgelegt wurde, das heißt, die volle Rechenkraft zur Entfaltung zu bringen wird bei einer GPU schwieriger als auf einer CPU."
1. Bring lieber einen Vergleich pro Sekunde, da die Desktop-Prozessoren halt Parallelität gegen Taktfrequenz eintauschen. Deswegen ist nur interessant was hinten als Gesamtleistung rauskommt.
2. Allerdings ist die CPU eben auf das Ausführen von "richtigen" Programmen optimiert, während die GPU auf das Bearbeiten von Datenströmen ausgelegt wurde, das heißt, die volle Rechenkraft zur Entfaltung zu bringen wird bei einer GPU schwieriger als auf einer CPU.
Bei Streams haben es GPU´s leichter ihre Rechenkraft zu entfalten wie CPU´s.
Bei "normalen" Programmen, wie du sie nennst, können dafür die CPU´s mehr Rechenleistung halten. GPU´s gehen dagegen total unter.
Im Prinzip hat man 2 Extreme: GPU und (Desktop-)CPU.
Dazwischen kann man dann den Cell einordnen, der versucht aus beiden Welten zu profitieren.

[micki]

Oder mal ganz konkret:
K8/SSE: maximal 4 FP32-FLOPs/Takt (2xMUL+2xADD, FSTORE zählt nicht)
P4/SSE: das selbe
K8/3DNow!: das selbe
K7/SSE: das selbe
K7/3DNow!: das selbe
P6/SSE: weiß ich nicht
bist du dir da sicher beim K7? ich dachte der hätte 3xMUL.

Allerdings ist die CPU eben auf das Ausführen von "richtigen" Programmen optimiert, während die GPU auf das Bearbeiten von Datenströmen ausgelegt wurde, das heißt, die volle Rechenkraft zur Entfaltung zu bringen wird bei einer GPU schwieriger als auf einer CPU."
das kommte immer auf den algorithmus an.

es gibt ja zum einen algorithmen die aufgrund von "smarter logic" zum ziel gelangen und auf der anderen seite gibt es algorithmen die bruteforce ans ziel kommen.
ein beispiel wäre (da ich es gerade eh im kopf habe, weil scottmandeath ja seine dipl darüber schreibt), vector quantitisierung.
man muss mehrere iterationen durchgehen, weil es eine nährung ist. die vectoren haben ne dimension von 1024 und es gibt ein paar tausend zu quantitisierende vectoren und dann die quantitisierten, auch "Codebook" genannt.
damit es auf der gpu optimal läuft, berechnet man zwischen jedem Source-vector und Codebook-vector die entfernung, laufzeit O(n^2). dabei muss man natürlich viele GB an daten durch die gegend schieben und dotproducts (quasi dp1024) durchführen. dabei ist die gpu um einiges schneller, weil die cpu garnicht ausgelastet wird (maximal 40%). dann sucht man sich zu jedem source-vector den passenden eintrag aus dem Codeboko, was wieder ne menge transferleistung verlang und auf der gpu gut abläuft, laufzeit ebenfalls O(n^2).
optimiert man das für die CPU, dann benutzt man KDTrees, diese haben zwar auch ne menge berechnungen, aber dank binärbaum architektur eine laufzeit für VQ von O(n log n) (wenn ich mich nicht versehe). das wäre auf der gpu entweder garnicht möglich und wenn, würde es jegliche optimierung aushebeln.

deswegen hängt es sehr vom algorithmus den man für eine problemlösung anwendet ab, wie gut man die cpu oder gpu auslasten kann. ist eben das trecker <-> ferrari problem (beide mit gleich viel ps ;D )

am optimalsten läuft es, wenn beide zusammenarbeiten, wie es auch in jeder engine gemacht wird, cpu determiniert auf smarte weise was zu sehen ist, und gpu zeichnet mit bruteforce power. die cpu alleine wäre nicht smart genug um das anzuzeigen und die gpu alleine hätte auch nicht genug bruteforce power um wirklich alles zu zeichnen.

MfG
micki

[BlackBirdSR]

bist du dir da sicher beim K7? ich dachte der hätte 3xMUL.




Nein.
Eine 64Bit FMUL Einheit, die folglich einen 2x32Bit Vektor bearbeiten kann.
Die anderen beiden übernimmt die ADD Einheit.
Also 2xMUL + 2xADD

[aths]

Ich finde eher das Gegenteil ist der Fall. Oder hast du das nur verdreht?
Gerade CPUs laufen durch das ganze Dekodieren, Branchen und all die Abhängigkeiten ständig mit ungenutzen Resourcen.
Das ist der Grund, warum SMT beim Power5 z.B so viel bringt.

Von den theoretischen 3µops/takt kommt der P4 in SpecFP so ca auf 0.65µops/takt.

Ich weiss nicht, wie es bei GPUs genau läuft, aber kommen die durch die ganze Parallelität und festgelegten Datenströme nicht näher an ihr Maximum?Das meinte ich zwar so, wie ich es schrieb, aber du hast mit deiner Betrachtungsweise auch Recht. Die Stelle werde ich noch umformulieren.

1. Bring lieber einen Vergleich pro Sekunde, da die Desktop-Prozessoren halt Parallelität gegen Taktfrequenz eintauschen. Deswegen ist nur interessant was hinten als Gesamtleistung rauskommt.
2.
Bei Streams haben es GPU´s leichter ihre Rechenkraft zu entfalten wie CPU´s.
Bei "normalen" Programmen, wie du sie nennst, können dafür die CPU´s mehr Rechenleistung halten. GPU´s gehen dagegen total unter.
Im Prinzip hat man 2 Extreme: GPU und (Desktop-)CPU.
Dazwischen kann man dann den Cell einordnen, der versucht aus beiden Welten zu profitieren.Darf man fragen, wieso du "GPUs" und CPUs" mit Apostroph schreibst (sogar mit einem falschen Apostroph, denn ´ ist ein Akut, der Apostroph wäre ')?

Ich ging in der zitierten Betrachtung von normalen Programmen aus, aber es ist wohl sinnvoll, die beiden Fälle (Programm mit vielen Sprüngen vs. Stream-Verarbeitung) zu unterscheiden.

[aths]

bist du dir da sicher beim K7? ich dachte der hätte 3xMUL.


das kommte immer auf den algorithmus an.

es gibt ja zum einen algorithmen die aufgrund von "smarter logic" zum ziel gelangen und auf der anderen seite gibt es algorithmen die bruteforce ans ziel kommen.
ein beispiel wäre (da ich es gerade eh im kopf habe, weil scottmandeath ja seine dipl darüber schreibt), vector quantitisierung.
man muss mehrere iterationen durchgehen, weil es eine nährung ist. die vectoren haben ne dimension von 1024 und es gibt ein paar tausend zu quantitisierende vectoren und dann die quantitisierten, auch "Codebook" genannt.
damit es auf der gpu optimal läuft, berechnet man zwischen jedem Source-vector und Codebook-vector die entfernung, laufzeit O(n^2). dabei muss man natürlich viele GB an daten durch die gegend schieben und dotproducts (quasi dp1024) durchführen. dabei ist die gpu um einiges schneller, weil die cpu garnicht ausgelastet wird (maximal 40%). dann sucht man sich zu jedem source-vector den passenden eintrag aus dem Codeboko, was wieder ne menge transferleistung verlang und auf der gpu gut abläuft, laufzeit ebenfalls O(n^2).
optimiert man das für die CPU, dann benutzt man KDTrees, diese haben zwar auch ne menge berechnungen, aber dank binärbaum architektur eine laufzeit für VQ von O(n log n) (wenn ich mich nicht versehe). das wäre auf der gpu entweder garnicht möglich und wenn, würde es jegliche optimierung aushebeln.

deswegen hängt es sehr vom algorithmus den man für eine problemlösung anwendet ab, wie gut man die cpu oder gpu auslasten kann. ist eben das trecker <-> ferrari problem (beide mit gleich viel ps ;D )

am optimalsten läuft es, wenn beide zusammenarbeiten, wie es auch in jeder engine gemacht wird, cpu determiniert auf smarte weise was zu sehen ist, und gpu zeichnet mit bruteforce power. die cpu alleine wäre nicht smart genug um das anzuzeigen und die gpu alleine hätte auch nicht genug bruteforce power um wirklich alles zu zeichnen.Ich möchte nicht nerven, mir aber die Bemerkung erlauben, dass es optimaler als optimal nicht geht.

Mir gehts es bei dem Vergleich darum zu zeigen, welche extreme Rechenleistung die heutigen Grafikkarten zur Verfügung stellen können. Dass CPU und GPU für ihre jeweiligen Einsatzgebiete optimiert sind, ist klar (sollte aber im Artikel noch explizit gesagt werden, das Release verzögert sich ja nun auf morgen.) Bei der Rechnung lasse ich Filter-Leistung, Blending-Leistung, Z-Berechnungen, Interpolatoren, das Triangle Setup und alles mögliche weg und zähle nur MAD vom Pixel- und Vertexshader zusammen. Richtig sinnvoll ist der Vergleich nicht, aber er zeigt, dass GPUs auf absehbare Zeit nicht von neuen CPU-Generationen ersetzt werden können.

CPUs können bestimmte Problemstellungen, darunter viele interessante und oft gebrauchte, trotzdem schneller lösen als eine GPU (welche in einigen Fällen gänzlich versagen dürfte.) Überlegungen, wie sich GPUs sinnvoll als Rechenmaschine einsetzen lassen sind natürlich ein interessantes Feld, was auch im Buch "GPU Gems" angeschnitten wird. Leider verstehe ich da nur wenige Kapitel.

[Gast]

Vielleicht hilft diese Seite weiter?

http://www.gpgpu.org/

[ScottManDeath]

CPUs können bestimmte Problemstellungen, darunter viele interessante und oft gebrauchte, trotzdem schneller lösen als eine GPU (welche in einigen Fällen gänzlich versagen dürfte.) Überlegungen, wie sich GPUs sinnvoll als Rechenmaschine einsetzen lassen sind natürlich ein interessantes Feld, was auch im Buch "GPU Gems" angeschnitten wird. Leider verstehe ich da nur wenige Kapitel.

Jups, traurigerweise hab ich so ein Problem erwischt ( LVQ auf der GPU).

Liegt wohl daran dass ich nicht ganz dem Stream Modell folge und mehrere Tausendmal pro Pixel aus Texturen lese und MAD mache. Dadurch bin ich anscheinend bandbreitenlimitiert :(


Ist bei Matrizenmultplikation ähnlich, dort werden Eingabewerte auch mehrfachverwendet.
http://graphics.stanford.edu/papers/gpumatrixmult/

[micki]

Ich möchte nicht nerven, mir aber die Bemerkung erlauben, dass es optimaler als optimal nicht geht.
emm... ja... emmm...
bringt es was, den leuten die dir helfen möchten deinen artikel zu perfektionieren indem sie ihr wissen zu teilen versuchen, ihnen ihre nichtigen fehler voraugenzuführen? ;)


Mir gehts es bei dem Vergleich darum zu zeigen, welche extreme Rechenleistung die heutigen Grafikkarten zur Verfügung stellen können. Dass CPU und GPU für ihre jeweiligen Einsatzgebiete optimiert sind, ist klar (sollte aber im Artikel noch explizit gesagt werden, das Release verzögert sich ja nun auf morgen.) Bei der Rechnung lasse ich Filter-Leistung, Blending-Leistung, Z-Berechnungen, Interpolatoren, das Triangle Setup und alles mögliche weg und zähle nur MAD vom Pixel- und Vertexshader zusammen. Richtig sinnvoll ist der Vergleich nicht, aber er zeigt, dass GPUs auf absehbare Zeit nicht von neuen CPU-Generationen ersetzt werden können.
wieso ist dir MAD so wichtig und welcher grund besteht, das man wissen sollte, dass für ein einsatzgebiet optimierte rechenwerke ihre daseinsberechtigung haben? dass mad wichtig ist, weiß man, ist ja der grund dafür dass es diesen befehl als merge von mul+add überhaupt gibt.
du könntest ebenso einen streaming chip von TI nehmen, der <1GHz hat und wohl 1/10 des stromverbrauchst von cpus besitzt und trotzdem in echtzeit mpeg encoden kann wie es keine cpu schafft.


CPUs können bestimmte Problemstellungen, darunter viele interessante und oft gebrauchte, trotzdem schneller lösen als eine GPU (welche in einigen Fällen gänzlich versagen dürfte.) Überlegungen, wie sich GPUs sinnvoll als Rechenmaschine einsetzen lassen sind natürlich ein interessantes Feld, was auch im Buch "GPU Gems" angeschnitten wird. Leider verstehe ich da nur wenige Kapitel.
das gibt es ja schon lange, die eine seite die tagelang overclocked damit sie ne leistungsfähigere hardware hat und dann mit ihren 30% mehr leistung endlich 33 statt 30fps hat, und es gibt die, die tagelang ihr hirn anstrengen um mit einem verbessertem algorithmus die laufzeit von O(n^3) auf O(n^2) bringen.
so ist es mit gpus und cpus, und den darauf ablaufenden algorithmen. die gpus haben irsinnig viel power um das zu berechnen, was die cpu durch einen branch als unsinnig ausschliesst.

was mich als artikel eher interresieren würde, wäre ob fp16 in wirklichkeit nicht nur ein fix1.15.16 ist ;)

MfG
micki

[aths]

emm... ja... emmm...
bringt es was, den leuten die dir helfen möchten deinen artikel zu perfektionieren indem sie ihr wissen zu teilen versuchen, ihnen ihre nichtigen fehler voraugenzuführen? ;)So lernen alle was – auch die Schreibweise mit ß nachzuschlagen würde ich dir ans Herz legen. Guter Inhalt kommt doch erst dann richtig gut rüber, wenn auch die Form stimmt. Damit möchte ich ja nicht zeigen, wie dumm du wärst – das würde im Gegenteil mich als den Dummen entlarven. Falls ich systematische Schreibfehler begehe, wäre ich jedenfalls über einen Hinweis dankbar.

was mich als artikel eher interresieren würde, wäre ob fp16 in wirklichkeit nicht nur ein fix1.15.16 ist ;)Wie meinst du das?

[BlackBirdSR]

So lernen alle was –

wo wir schon dabei sind.
Bist du dir sicher, dass "MAD" die korrekte Abkürzung für ein Multiply - ADD ist?

Nicht MADD?

[Demirug]

wo wir schon dabei sind.
Bist du dir sicher, dass "MAD" die korrekte Abkürzung für ein Multiply - ADD ist?

Nicht MADD?

Bei GPUs ist MAD schon richtig. Der entsprechenden Shaderbefehl heisst nun mal so.

[aths]

wo wir schon dabei sind.
Bist du dir sicher, dass "MAD" die korrekte Abkürzung für ein Multiply - ADD ist?

Nicht MADD?Nvidia schreibt im neuen Pressematerial "MADD", aber ich nehme die (mir) geläufigere Variante "MAD".