News AMD in Zukunft mit 256-Bit-FPU-Pipelines

[Opteron]

Na dann braucht man ja auch kein FP256 Bit, wenn eh alles mit 128-bit Instruktionen besser ist. Richtig?

Ja absolut richtig. Für aktuelle CPUs braucht man kein FP256bit Flag, da sie intern kein 256bit können. Das hast Du echt messerscharf erkannt.

Klingelts?

Wenn nicht mal weiter ..

Was irrelevant ist. Der entscheidende Punkt ist, dass K8 die Instruktionen tatsächlich aufteilen musste, da nicht alles im selben Takt verarbeitet werden konnte. Für Bulldozer ist das nicht notwendig. Der kann die volle Breite in einem Takt verarbeiten. Das Aufteilen im K8 war also ein anderes als das was du als Aufteilen in Bulldozer verstehst

Nein, das ist beidemale das gleiche. Beidemal wird eine x86-Instruktion intern in halb so große Teile zerlegt. Das sieht man schön an der Double-Dekodierung, mit der Du anscheinend nichts anzufangen weisst. Anders kann ich mir Dein igonrantes "irrelevant" nicht erklären.

Das es da jetzt 2 FMACs gibt ist nett --- es erspart Dir aber nicht das Aufsplitten. Eine 256bit Instruktion muss trotzdem in 128bit aufgesplittet werden. In zwei 0,5l Gläser passen je 0,5l was zusammen 1L ergibt, ja, aber um den Liter unterbringen zu können musst Du ihn aufteilen. Das ist bei den CPUs genauso, deswegen hatte ich die Double-Angaben angegeben. Doubles heißt 2 MOps = 2x128bit. Eben zwei 0,5er Gläser, kein 1L Glas.

Dass es jetzt dank der zwei 128bit Pipes in einem Rutsch geht, ist schön für den Durchsatz, Du schaffst Deinen 1L in einem Zug weg, da Du die zwei 0,5er Gläser gleichzeitig / in einem Takt befüllen kannst, das ist wunderbar und spart Zeit, aber das erspart Dir eben nicht die Aufsplittung bzw. die Double-Decodierung.

Das ist der Punkt den Du nicht kapierst, dabei sollte es anhand der Double-Decodierung nun wirklich glasklar sein.

Ist das jetzt verstanden, dass CPU-technisch 2x128bit nicht das gleich wie 1x256 sind?

Ach vorsichtshalber noch ne kleine Übersicht:

Bulldozer:
AVX256-x86 Instruktion -------> Dekoder ------> zwei 128bit MOps -----> Ausführung in den 2 128b FMACs (parallel möglich).

Jaguar:
AVX256-x86 Instruktion -------> Dekoder ------> zwei 128bit MOps -----> Ausführung seriell in den 128 bit ADD/MUL Pipes.

Excavator (oder was auch immer):
AVX256-x86 Instruktion -------> Dekoder ------> 1 256bit MOps -----> Ausführung in einer der 2 256b FMACs

Da sieht man auch, dass Dein Einwurf mit Jaguar nichts bringt. Wenn das so wäre, wie Du es Dir vorstellst, dann hätte man das Flag schon mit BDv1 einführen müssen. Die Dekodierung ist schließlich nachweislich das gleiche (Double) und die AVX128bit Ausführung ist ebenfalls schneller (siehe Zitat im letzten Posting).

Man könnte sich das Flag nun sicher auch sparen und den Compiler Leuten sagen, dass die 15h Chips ab Model xy 256bit Pipes haben, das hätte man früher beim K10 auch machen können. If K8 = 64bit SSE erzeugen, if K10 = 128bit SSE nutzen. Aber vermutlich wollten sies sauber trennen. Wer weiss wie das bei den APUs ausgeht, oder was zukünftige Jaguars machen werden, also bevor man in ~5 Jahren ne ziemlich komplizierte Abfrage basteln muss (If Fam 15h and Model xy or Fam 16h and model z or ....), gibt man die Info eben gleich über ein kleines CPUID Bit mit.

 

[gruffi]

Ja absolut richtig. Für aktuelle CPUs braucht man kein FP256bit Flag, da sie intern kein 256bit können.

Tolle Kausalschleife. Substanzlos für mich.

Nein, das ist beidemale das gleiche.

Nein, eben nicht. Eine Instruktion im gleichen Takt oder eine Instruktion in mehreren Takten verarbeiten zu können, ist für mich immer noch ein klarer Unterschied. Offenbar verstehst du diese Thematik nicht. Anders kann ich mir deine sture Haltung nicht erklären. Über das Thema der Aufspaltung der Datenworte in 32-, 64-, 128-bit oder was auch immer, und den daraus resultierenden MicroOps, sind wir doch schon längst hinaus. Dein Rumreiten auf Fastpath Single und Fastpath Double hilft da auch nicht weiter. Das ist doch nur Mittel zum Zweck. Es gibt übrigens auch 128-bit Instruktionen, die FastPath Double sind. Nur so als Denkanstoss.

Das es da jetzt 2 FMACs gibt ist nett --- es erspart Dir aber nicht das Aufsplitten. Eine 256bit Instruktion muss trotzdem in 128bit aufgesplittet werden.

Und eine 128-bit Instruktion muss nicht aufgesplittet werden oder wie? Seit wann unterstützt x86 IEEE 754-2008? Sry, aber du hast einfach keinen Blick für das Gesamtkonstrukt. Die Datenworte werden so oder so aufgesplittet. An welcher Stelle dies in der Pipeline passiert, Decoder, Scheduler oder ALUs, ist letztendlich implementationsspezifisch und hier nicht ausschlaggebend. Ausschlaggebend ist der Durchsatz pro Takt. Das musst du dir anschauen. Alles andere wird dich nicht aus deiner Kausalschleife befreien.

Dass es jetzt dank der zwei 128bit Pipes in einem Rutsch geht, ist schön für den Durchsatz, Du schaffst Deinen 1L in einem Zug weg, da Du die zwei 0,5er Gläser gleichzeitig / in einem Takt befüllen kannst, das ist wunderbar und spart Zeit, aber das erspart Dir eben nicht die Aufsplittung bzw. die Double-Decodierung.

Das ist der Punkt den Du nicht kapierst, dabei sollte es anhand der Double-Decodierung nun wirklich glasklar sein.

Deine Romane hättest du dir auch sparen können. Dass es hardwareseitig Unterschiede gibt, stand doch gar nicht zur Debatte. Das ist für die Hardwareingenieure natürlich wichtig. Du erzählst uns da keine Neuigkeiten. CPUID hingegen richtet sich an Softwareentwickler. Und aus softwareseitiger Sicht ist diese interne Verarbeitung belanglos. Ich sehe zumindest keinen konkreten Nutzen von deren Kenntnis. Und du hast auch noch keine Argumente gebracht, die das ändern würden. Das ist der Punkt, den du anscheinend nicht kapierst oder nicht kapieren willst.

Wenn das so wäre, wie Du es Dir vorstellst, dann hätte man das Flag schon mit BDv1 einführen müssen.

Nein. Auch bdver1 konnte 256-bit schon in einem Takt. Es gab keine Notwendigkeit, zu differenzieren. Erst Jaguar ändert das.

 

[Opteron]

Vergiss es .. schönen Abend.

 

[sompe]

@gruffi
Es ist aber ein Unterschied ob sie als ganzes innerhalb des Taktes verarbeitet wird oder ob sie dafür zerhackt und die beiden Teile parallel verarbeitet werden. Beim ersten werden 256 Bit verarbeitet und beim anderen 2x 128Bit im selben Takt.

 

[gruffi]

Es ist aber ein Unterschied ob sie als ganzes innerhalb des Taktes verarbeitet wird oder ob sie dafür zerhackt und die beiden Teile parallel verarbeitet werden. Beim ersten werden 256 Bit verarbeitet und beim anderen 2x 128Bit im selben Takt.

Nochmal, darum geht es doch überhaupt nicht. Der Durchsatz pro Takt ist der gleiche. Verrate mir doch mal, welchen Unterschied das auf Softwareseite macht?

 

[CPU-Klaus]

Der Durchsatz pro Takt ist der gleiche. Verrate mir doch mal, welchen Unterschied das auf Softwareseite macht?

Der Durchsatz pro Takt ist nicht der Gleiche, laut Benchmarks, die in diesem Thread erwähnt wurden.

Der Durchsatz in den FPU-Pipelines ist der Gleiche aber der Gesamtdurchsatz ist nicht der Gleiche, weil durch die Aufsplittung in den Decodern offenbar ca. 3 Prozent performanceverlust entsteht, wie die Benchmarks zeigen.

 

[tex_]

BDv1: avx 256 (Durchsatz 1/Takt pro Modul - 0.5/Takt pro Kern)
BDv1: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 256 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
(X durch neue Architektur mit 256Bit Pipelines ersetzen)

Macht für mich also einen großen Unterschied im Durchsatz bei den neuen breiteren Pipelines wenn man mit 256Bit SIMD Instruktionen rechnet.

Die Latenz ist da auch erst mal zweitrangig, vor allem da durch die Teilung der FPU zwischen 2 Kernen sowieso ein zusätzlicher Wartezyklus entstehen kann.

Gerade für die Software ist das eben auch ein riesiger Unterschied ob nun AVX 256 doppelt so schnell ist wie AVX 128 oder eben nicht, bzw. sogar ein paar Prozent langsamer.

Warum du hier auf den Floating Point Standard hinweist verstehe ich auch nicht ganz. Bei 128Bit Recheneinheiten werden eben z.b. 2 64Bit Berechnungen durchgeführt und bei 256 Bit SIMD eben z.B. 4 mal 64 Bit. Heißt also bei letzterem gibt es einen höheren Durchsatz, den du hier nicht sehen willst?

 

[gruffi]

Der Durchsatz pro Takt ist nicht der Gleiche

Doch, theoretisch ist er erst mal gleich. Ausserdem ist es für mich ziemlich spekulativ, woher einige wenige Prozent Unterschied kommen. Das kann auch einfach nur eine Softwaregeschichte sein oder ist auf andere Limitierungen des Designs zurückzuführen. Wie gesagt, das interne Design wurde einst für SSE5 entwickelt. Vielleicht hat man irgendwo noch Defizite beim Balancing. Und ob man nun wegen 2-3% in irgendwelchen synthetischen Tests extra ein solches Bit einführt, ist doch sehr fraglich. Und warum erst jetzt, wenn das schon über 2 Jahre oder vielleicht noch länger bekannt ist? Wie gesagt, aufgrund von Jaguar wäre das Bit deutlich plausibler. Zum einen, weil die Auswirkungen da deutlich gravierender sein können. Und zum anderen, weil es eben die gleiche Geschichte wie mit K8 ist. Für die volle Datenbreite der SIMD Pipeline braucht man mehr als einen Takt.

BDv1: avx 256 (Durchsatz 1/Takt pro Modul - 0.5/Takt pro Kern)
BDv1: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 256 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
BDvX: avx 128 (Durchsatz 2/Takt pro Modul - 1/Takt pro Kern)
(X durch neue Architektur mit 256Bit Pipelines ersetzen)

Keine Ahnung, was uns diese Übersicht sagen soll. Natürlich hätte eine breitere FPU mehr Durchsatz. Liegt nun mal in der Sache der Natur. Das ändert aber nichts am aktuellen Durchsatz, um den es ging. Egal wie die interne Verarbeitung konkret ausschaut. Wenn's um Compiler geht, die haben eh für jeden Kern bzw jede Architektur spezifische Infos zur Codeoptimierung. Wie viele ALUs, welche Datenbreite, Latenzen usw. Das wird auch in Zukunft so sein und daran ändert auch das FP256 Bit nichts.

Warum du hier auf den Floating Point Standard hinweist verstehe ich auch nicht ganz.

Weil es sowieso keine 128-bit oder 256-bit FP Operationen gibt. Bzw unterstützt erst IEEE 754-2008 128-bit FP Operationen. x86 Prozessoren unterstützen bisher aber maximal 64-bit FP Operationen (x87 mal aussen vor gelassen). Dh, intern wird irgendwann sowieso alles auf 32-bit (SP) bzw 64-bit (DP) zerstückelt. Egal ob die Eingabepuffer als 1x 256-bit oder 2x 128-bit behandelt werden.

 

[sompe]

Nochmal, darum geht es doch überhaupt nicht. Der Durchsatz pro Takt ist der gleiche. Verrate mir doch mal, welchen Unterschied das auf Softwareseite macht?

So wie ich es mitbekommen hatte ging es die ganze Zeit darum ob der 256 Bit Code in einem Stück schlucken kann oder in Häpchen verarbeitet. Die Relevanz für die Software dürfte recht einfach sein. Schnappt sich der 256 Bit Code beide FPU Teile des Moduls ist für den zweiten Kern des Moduls erstmal Feierabend mit FPU Zugriffen. Des weiteren dürfte die Aufspaltung der Befehle letztendlich auch Zeit und einen gewissen Rechenaufwand kosten. Daher kommt vermutlich u.A. auch der Leistungsverlußt bei 256 Bit Code.
Der Unterschied für die Software ist also mindestens ein gewisser Performanceverlußt.

 

[tex_]

Deine Aussage zu den FP-Formaten ist mir hier immer noch nicht schlüssig, da meiner Meinung nach hier niemand davon ausging das mit 256 Bit breiten FP Zahlen gerechnet wird.

Das Bit sagt laut Tabelle aus: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Bulldozer hat keine 256 Bit Pipeline. Jaguar erst recht nicht.
"... rather than decomposing them into internal 128 Bit suboperations."
Also genau dem was Bulldozer im Moment machen muss. Problem ist dabei im Moment ja auch noch das der Dispatch auf 4 Makro Ops beschränkt ist, also mit einer double Dekodierung der x86-Durchsatz des ganzen Modules negativ beeinflusst wird.

Damit ist das neue Bit auch weder für Bulldozer noch für Jaguar geeignet, ich weiß ehrlich gesagt nicht wie man das hier rauslesen kann.

Und die Frage ist doch woher die Compiler ihre Infos bekommen. Vlt. aus den CPUID Bits? Ansonsten könnte man diese Register ja auch gleich sein lassen, braucht ja keiner.
Dazu gibt es neben den Instruktionsbits auch diese Performance Bits wie man an deren Namen schon sehen kann. Ob die genutzt werden ist natürlich Sache der jeweiligen Compiler Entwickler.

 

[ELKINATOR]

wäre es nicht auch möglich das man in zukunft 3 128bit FPUs hat?
jeder kern hat seine eigene und die in der mitte wird geteilt.

 

[Crashtest]

Pro Modul 2x256 Bit wär schon ok, besser wäre mit Möglichkeit:
- 1x512Bit + warten
- 1x255Bit + 1x256Bit
- 3x128Bit + 1x128Bit
sodass dynamisch die 2 256Bit Einheiten auf/zugeteilt werden könnten

 

[gruffi]

So wie ich es mitbekommen hatte ging es die ganze Zeit darum ob der 256 Bit Code in einem Stück schlucken kann oder in Häpchen verarbeitet.

Nein. Es ging darum, worauf das CPUID Bit zurückzuführen ist. Opteron sagt in seinem Artikel, dass das die quasi Bestätigung für zukünftige 256-bit FMACs ist. Ich sage, dass das noch lange nicht so sein muss bzw nicht in einem solchen Zusammenhang stehen muss. Es kann auch lediglich für Fälle wie Jaguar eingeführt worden sein. Was natürlich trotzdem nicht ausschliesst, dass die FMACs in zukünftigen Designs aufgebohrt werden.

Daher kommt vermutlich u.A. auch der Leistungsverlußt bei 256 Bit Code.

Das sehe ich aber nicht als Problem, welches man mit einem CPUID Bit umgehen müsste. Das ist nun mal die Konsequenz eines solchen flexiblen FPU Designs. Was wäre denn die Alternative? Zwei 256-bit FMACs, damit bei einer 256-bit Instruktion nicht gleich sämtliche FPU Ressourcen blockiert sind, die FPU dafür aber die meiste Zeit nur halb ausgelastet wird? Ist das besser? Ich denke nicht. Die paar wenigen Prozent Unterschied, die in den synthetischen Tests gemessen wurden, sind mMn zu vernachlässigen. Das erfordert mehr Balancing auf Hardwareebene und generell angepasste Codegenerierung und nicht irgendwelche spezifischen Softwarepfade entsprechend einem CPUID Bit.

Das Bit sagt laut Tabelle aus: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Bulldozer hat keine 256 Bit Pipeline. Jaguar erst recht nicht.
"... rather than decomposing them into internal 128 Bit suboperations."
Also genau dem was Bulldozer im Moment machen muss.

Da steht auch nichts von 256-bit Pipeline. Auf Deutsch steht da, dass die internen Operationen und Pipelines die Ausführung von Instruktionen mit voller AVX Breite unterstützen, also 256-bit. Wie diese 256-bit erreicht werden, ist doch erst mal nebensächlich. Und der zweite Teil ist eben genau das, was K8 schon gemacht hat und auch Jaguar jetzt macht. Die Instruktionen in zwei Datenpakete zu zerstückeln, die dann in verschiedenen Takten verarbeitet werden. Ich kann aber auch dir nur nochmal sagen, in diese Formulierungen nicht zu viel hinein zu interpretieren. Es ist lediglich C&P und als das FP128 Bit formuliert wurde, gab es noch keinen Bulldozer. Was die Grundlage für das FP256 Bit ist, kann im Moment nur AMD beantworten. Jaguar erscheint mir im Moment aber wie gesagt plausibler als hypothetische 256-bit FMACs.

wäre es nicht auch möglich das man in zukunft 3 128bit FPUs hat?

Wäre gar keine so schlechte Idee. Eigentlich ist 128-bit Verarbeitung ja auch zu bevorzugen. Eben weil uns SSE wohl noch einige Zeit erhalten bleibt und weil mit reinen 256-bit FMACs die Hälfte der Rechenkapazitäten oft brach liegt. 4-fach FP32 Vektoren sind gängige Konstrukte, zB für Koordinaten und Farbinformationen in Grafikanwendungen wie Spielen. Also auch 256-bit FMACs müssten flexibel für 128-bit Verarbeitung gestaltet werden, damit die Effizienz nicht leidet.

 

[ELKINATOR]

hier ein bild, falls es jemand nicht verstanden hat.

http://f.666kb.com/i/ce00nxded03eocnof.jpg

 

[tex_]

1x512Bit gibts bei AVX leider noch nicht und bei 4x128Bit steigt eben wieder der Hardwareaufwand durch die 2 zusätzlichen Ports. Da man jetzt allerdings auch schon 4 SIMD Operationen alleine für FP dekodieren müsste, stellt sich dabei die Frage ob die Dekoder überhaupt noch genug Durchsatz bringen. Es gibt ja schließlich auch noch andere Operationen die neben dem FP-Instruktionen ausgeführt werden wollen.

Bei Steamroller wechselt man ja nun auch von ursprünglich 4 auf nur noch 3 Ports für die SIMD Pipelines. Der Sinn von den Shared Pipelines ist ja, das jeder Kern bei Bedarf auf die gesamten Ressourcen des Moduls zurückgreifen kann. Da dürfte in der Tat bei 2-3 Ports Schluss sein selbst bei 2 seperaten Decodern. (Wenn man von 2-fach Dekodern ausgeht ist alles über 2 Ports sowieso ziemlicher humbug.)
Wenn man es für den maximalen Durchsatz beider Kerne auslegt könnte man in der Tat auch wieder zum klassischen Kerndesign mit 2 seperaten FPUs zurück wechseln. Aber wie Tests zeigen erreicht man ja auch so Skalierungswerte von annähernd 80% von daher scheinen 2 shared FP-Ports durchaus ausreichend um ein Modul auszulasten.
Der nächste Schritt um mehr Performance herauszuholen ist dann eben von 128 auf 256 Bit Breite.
(Abgesehen davon ist die 2fach Dekodierung sowieso mehr als unwahrscheinlich da der Int-Zweig auf eine maximale 4fach Ausführung ausgelegt ist, also würde man sich hier wieder langsamer machen als man vorher war.)

Und noch mal: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Die Breite der internen Pipeline ist bei BD nicht 256 Bit also können die Instruktionen auch nicht so ausgeführt werden. Das "Operations" bezieht sich übrigens auch auf makro-Op Ebene, eben weil von intern gesprochen wird. Das zeigt sich dann auch noch mal im 2. Satz.
Wenn das Bit für BDv1 hätte gelten sollen, wären sie damit jetzt eh reichlich spät dran.

 

[gruffi]

hier ein bild, falls es jemand nicht verstanden hat.

http://f.666kb.com/i/ce00nxded03eocnof.jpg

Ich denke nicht, dass man aus einem 4-fach Decoder zwei 2-fach Decoder macht. Damit hat man ja nichts gewonnen. Ich gehe von mindestens zwei 3-fach Decodern aus. Eventuell werden es auch zwei 4-fach Decoder.

Da man jetzt allerdings auch schon 4 SIMD Operationen alleine für FP dekodieren müsste, stellt sich dabei die Frage ob die Dekoder überhaupt noch genug Durchsatz bringen.

Mit Steamroller wird doch die Decoderbandbreite erhöht und zusätzlich fällt eine Pipe in der FPU weg. Ein dritter 128-bit FMAC sollte also kein Problem sein. Selbst ein vierter ist machbar.

Und noch mal: "256 Bit-AVX instructions are executed with full-width internal operations and pipelines...."
Die Breite der internen Pipeline ist bei BD nicht 256 Bit also können die Instruktionen auch nicht so ausgeführt werden.

Da steht auch nichts von 256-bit Operationen. Wie gesagt, am Ende wird eh alles auf FP32 und FP64 Operationen heruntergebrochen. Der springende Punkt bei der Formulierung ist "full-width". Und das ist der Fall. Ob nun als 1x 256-bit oder 2x 128-bit, spielt am Ende keine Rolle. Und "operations" ist Operation, also eine ganz allgemeine Umschreibung für ADD, MUL, etc.

Ich sage es nochmal:

Ich kann aber auch dir nur nochmal sagen, in diese Formulierungen nicht zu viel hinein zu interpretieren. Es ist lediglich C&P und als das FP128 Bit formuliert wurde, gab es noch keinen Bulldozer.

 

[ONH]

Ich sage es nochmal:

Dennoch stellt sich die Frage, wieso braucht es in zukünftigen Prozessoren ein FP256 bit in der CPUID. Wenn sich da "nichts" gegenüber von Bulldozer oder Jaguar ändern wird, also wieso soll es 2x 126 bit sein.

 

[gruffi]

Dennoch stellt sich die Frage, wieso braucht es in zukünftigen Prozessoren ein FP256 bit in der CPUID.

Es ist eben die gleiche Geschichte wie mit K8 -> K10. Maximal die chronologische Reihenfolge ist eine andere. K8 und K10 haben jedenfalls die 128-bit SSE Pipeline unterstützt. K8 konnte 128-bit Instruktionen aber nicht in einem Takt verarbeiten, weil die FPU lediglich 64-bit breit war. Erst mit K10 wurde die FPU auf 128-bit verbreitert. Vergleichbares sehen wir nun bei Jaguar und Bulldozer mit AVX. Beide Architekturen unterstützen die 256-bit AVX Pipeline. Aber nur Bulldozer ist in der Lage, entsprechende Instruktionen in einem Takt zu verarbeiten. Ob intern 1x 256-bit oder 2x 128-bit ist wie gesagt erst mal nebensächlich. Da Jaguar aber lediglich eine 128-bit FPU besitzt, braucht der genauso wie K8 mehrere Takte.

Also ich bin mir zu 99,9% sicher, dass das FP256 Bit für Fälle wie Jaguar geschaffen wurde. Das ist relativ eindeutig. Wie ich zuvor schon sagte, ob es eventuell auch zusätzlich für andere Fälle gilt, wie Bulldozer, hängt von weiteren Faktoren ab. Durch die Modulbauweise und die geteilten Ressourcen für zwei Threads ergeben sich weitere Betrachtungsweisen. ZB nicht nur pro Takt pro Pipeline, sondern auch pro Takt pro Thread. Das kann uns letztendlich nur AMD beantworten.

 

[Opteron]

Ach ich langweile Dich mal wieder mit ein paar nutzlosen Kommentaren, bin gerade gut aufgelegt

am Ende wird eh alles auf FP32 und FP64 Operationen heruntergebrochen.

Ja, aber es macht nen "kleine" Unterschied, ob Du ein 256er-Paket in 4 Teile zerlegst, oder 2x128 in 2.
Oder anders gesagt, Du übersiehst da den Begriff "internal". Internal mein MOps (anders macht es keinen Sinn, max. gibts 64bit DP-Werte und die wurden schon beim K8 in "full-width" übertragen) und davon brauchst Du beim BD, wie beim Jaguar nunmal 2. Eine einzige AVX256 Anweisung musst Du in je 2 128er aufsplitten, wobei Du die Rechen-Opteration sinnloserweise durch das Aufsplitten kopieren musst.

Der springende Punkt bei der Formulierung ist "full-width".

Jo full-width internal.
Das ist bei BD leider nicht der Fall... die volle Bandbreite hast Du nur aus externer Sicht und das auch nur bei nem einzigen Tasks auf dem Modul.

Das ganze Bit für Jaguar macht keinen Sinn.

Für Jaguar müsste es auf Null gesetzt werden - wir sind uns ja einig, dass Jaguar keine full-width hat - allerdings steht es aktuell bei allen K10 und BD-Varianten auch schon auf 0. Man kann BD und Jaguar also nicht anhand des Bits unterscheiden, obwohl BD laut Deiner Auslegung ja full-width hätte. Natürlich könnte man zur Unterscheidung noch die restlichen CPUID-Bits abfragen, aber wenn man die auch noch benützen müsste, könnte man sich das FP256 Bit gleich ganz sparen.

Oder meinst Du, dass Jaguar das Bit auf 1 setzen wird? Dann wäre der Beschreibungsname im PDF arg irreführend. Dafür hätten sie es dann AVX128, No256 oder sonstwas nennen müssen.

Also ich bin mir zu 99,9% sicher, dass das FP256 Bit für Fälle wie Jaguar geschaffen wurde.

Und ich bin mir 100% sicher, dass Du zu 99,9% falsch liegst

Warten wirs mal ab. Neue Argumente gibts keine mehr, bzw. sie werden ignoriert, aber CPUID-Dumps der Kabinis sind nicht mehr weit entfernt.

 

[gruffi]

Ja, aber es macht nen "kleine" Unterschied, ob Du ein 256er-Paket in 4 Teile zerlegst, oder 2x128 in 2.

Aus Softwaresicht nicht wirklich. Das nennt sich Hardwareparallelität.

Oder anders gesagt, Du übersiehst da den Begriff "internal".

Auch für dich nochmal:

Ich kann aber auch dir nur nochmal sagen, in diese Formulierungen nicht zu viel hinein zu interpretieren. Es ist lediglich C&P und als das FP128 Bit formuliert wurde, gab es noch keinen Bulldozer.

Mal schauen, wie oft ich das wiederholen muss, bis es jeder versteht.

Jo full-width internal.
Das ist bei BD leider nicht der Fall...

Doch. Es sind intern insgesamt 256-bit, also die volle Breite der AVX Pipeline. Wie dies organisiert wird, ist wie gesagt erst mal nebensächlich.

Das ganze Bit für Jaguar macht keinen Sinn.

Natürlich, gerade dafür. Bisher unterstützt nur Bulldozer AVX. Und der kann AVX Instruktionen in einem Takt. Mit Jaguar ändert sich das nun. Der kann AVX Instruktionen nicht in einem Takt und muss diese zerstückeln, um sie in mehreren Takten zu verarbeiten. Also wird ein Bit zur Differenzierung sinnvoll. Nach deiner Argumentation wäre ein solches Bit aktuell nicht notwendig, da es immer nur einen Zustand hätte. Und sich dann auf irgendwelche hypothetischen 256-bit FMACs in Zukunft zu beziehen, ist äusserst spekulativ.

allerdings steht es aktuell bei allen K10 und BD-Varianten auch schon auf 0.

Das liegt an zwei Sachen. Erstens, bisher nicht genutzte Bits stehen natürlich immer erst mal auf 0 per default. Und zweitens, man ändert nicht einfach die Logik solcher Bits. Man versucht konsistent zu bleiben. Wie ich schon sagte, die chronologische Reihenfolge ist eine andere. Bei K8 -> K10 kam zuerst die halbe Hardwarebreite und dann die volle. Mit Bulldozer -> Jaguar ist es nun umgekehrt. Zuerst kam die volle Hardwarebreite und dann die halbe.

 

[Opteron]

Mit Bulldozer -> Jaguar ist es nun umgekehrt. Zuerst kam die volle Hardwarebreite und dann die halbe. Bisher nicht genutzte Bits stehen natürlich immer erst mal auf 0 per default.

Ja und? Das ändert nichts am Problem der 0en bei den BDs. Wie willst Du das denn beheben, dass Jaguar und BDv1v2 gleich behandelt werden? Willst DU ein µCode-Update verschicken, dass bei den BDs das Bit nachträglich auf 1 ändert?

Erstens, man ändert nicht einfach die Logik solcher Bits. Man versucht konsistent zu bleiben.

Eben, das Bit wird aus Konsistenzgründen nicht geändert, ergo bleiben die aktuellen BDs bei FP256=0 und irgendwann demnächst wirds ne CPU mit FP256=1 geben.

Und das wird kein Jaguar sein

 

[gruffi]

Ja und? Das ändert nichts am Problem der 0en bei den BDs. Wie willst Du das denn beheben, dass Jaguar und BDv1v2 gleich behandelt werden? Willst DU ein µCode-Update verschicken, dass bei den BDs das Bit nachträglich auf 1 ändert?

Nein. Ist es denn ein Problem, wenn der aktuelle Bulldozer und Jaguar gleich behandelt werden? Ich denke nicht. Bulldozer erleidet mit 128-bit Instruktionen keinen Leistungsverlust. Umgekehrt kann man das für Jaguar und 256-bit Instruktionen nicht einfach so sagen. Für Bulldozer dürfte es im Moment ziemlich egal sein, auf welchem Wert das Bit steht. Egel ob man softwareseitig für 128-bit oder 256-bit AVX Instruktionen optimiert, Bulldozer sollte in beiden Fällen ähnlich performen.

Eben, das Bit wird aus Konsistenzgründen nicht geändert, ergo bleiben die aktuellen BDs bei FP256=0 und irgendwann demnächst wirds ne CPU mit FP256=1 geben.

Und das wird kein Jaguar sein

Das hat auch keiner behauptet. Du scheinst den Sinn und die Logik solcher Bits immer noch nicht verstanden zu haben. Man macht solche Bits nicht, damit man sie auf 1 setzen kann. Man macht solche Bits, um zwischen zwei Zuständen bzw Optionen unterscheiden zu können. Und genau das ist bei Jaguar der Fall, da der hardwareseitig nicht die volle Breite der AVX Pipeline unterstützt. Bulldozer hingegen tut das schon. Welcher Zustand dann mit 0 und 1 definiert wird, ist nebensächlich. Eine alte Faustregel der Programmierung lautet, Default-Zustände sollten mit 0 definiert werden.

Vielleicht glaubst du wenigstens einmal jemandem etwas, der sich mit dieser Thematik etwas besser auskennt als du.

 

[Opteron]

Nein. Ist es denn ein Problem, wenn der aktuelle Bulldozer und Jaguar gleich behandelt werden? Ich denke nicht.

Na wenn Du zw. BD und Jaguar nicht unterscheidest, wozu brauchst Du das Bit dann überhaupt?

Vielleicht glaubst du wenigstens einmal jemandem etwas, der sich mit dieser Thematik etwas besser auskennt als du.

Ich glaub Dir immer gerne -- solange es nen Sinn ergibt

 

[gruffi]

Na wenn Du zw. BD und Jaguar nicht unterscheidest, wozu brauchst Du das Bit dann überhaupt?

Du sprachst davon, wenn das Bit auf 0 gesetzt ist. Darauf bezog sich auch meine Antwort. Ich habe nicht gesagt, dass man beide grundsätzlich gleich behandeln soll. Bei zukünftigen Bulldozern könnte das Bit auf 1 gesetzt sein, trotz 128-bit FMACs. Jaguar hingegen bleibt auf 0. Dann sind beide natürlich zu unterscheiden.

 

[Opteron]

Ich habe nicht gesagt, dass man beide grundsätzlich gleich behandeln soll. Bei zukünftigen Bulldozern könnte das Bit auf 1 gesetzt sein, trotz 128-bit FMACs. Jaguar hingegen bleibt auf 0. Dann sind beide natürlich zu unterscheiden.

Und wieviel Sinn macht es dann, bei der einen 128er FMAC FPU das FP256 Flag zu setzen, und bei der andern nicht? Wo soll dann Deiner Meinung nach der Unterschied sein, der das unterschiedliche Setzen rechtfertigt?

Waren die aktuellen BDs einfach zu früh dran und haben "Pech gehabt"?

Da widersprichst Du doch Dir selbst, wenn Du früher schriebst:

man ändert nicht einfach die Logik solcher Bits. Man versucht konsistent zu bleiben.

Einmal 128bit = 0 und einmal = 1 ist ne Änderung der Logik.