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

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?
Habe ich das nun nicht mehr als ausführlich erläutert? Die eine Pipeline kann 256-bit AVX in einem Takt, die andere nicht. Du hängst dich mMn viel zu sehr an den 128-bit FMACs auf. Nochmal, die interne Verwaltung ist erst mal nebensächlich. Der Durchsatz pro Takt ist ausschlaggebend.

Es sollte die Aufgabe der Hardwareingenieure sein, 1x 256-bit genauso effizient zu designen wie 2x 128-bit. Vielleicht gibt es da im aktuellen Design noch Schwachstellen, so dass eben in einigen Benchmarks 2-3% Unterschied entstehen. Who knows? Ich sehe das nicht als Aufgabe der Softies.

Um mal deinen Gedanken aufzugreifen, der würde mMn nur Sinn machen, wenn man in Zukunft die FMACs auf 256-bit aufbohrt, der 128-bit Durchsatz aber gleich bleibt. Also entweder können zwei 128-bit oder zwei 256-bit Instruktionen pro Takt ausgeführt werden. Dann ändert sich das 128:256-bit Verhältnis von 2:1 auf 1:1. Und dann hätte das CPUID Bit auch hier einen Sinn. Beim Verhältnis von 1:1 wären natürlich 256-bit Instruktionen zu bevorzugen. Nur, warum sollte man das machen? Ich hatte es ja zuvor schon erwähnt, dann würde die FPU oft nur halb ausgelastet werden, weil entweder SSE Code ausgeführt wird oder die Programmlogik gar nicht so viele 256-bit Instruktionen beinhaltet.

Effizienter wäre, die FMACs auf 256-bit aufzubohren, diese aber auch bei Bedarf in zwei 128-bit Teile aufzusplitten, oder eben einfach zwei weitere 128-bit FMACs hinzuzufügen. Am 128:256-bit Verhältnis gegenüber dem aktuellen Design ändert sich dadurch nichts. Wir hätten dann lediglich die doppelte Breite auf beiden Seiten. Sozusagen statt 256-bit pro Modul 256-bit pro Thread. Die Preisfrage ist nun, welchen Sinn hat das CPUID Bit hier? Ich sehe keinen wirklichen. Ob du aktuell 2x 128-bit oder 1x 256-bit bzw in Zukunft 4x 128-bit oder 2x 256-bit ausführst, der theoretische Durchsatz bleibt der gleiche.

Waren die aktuellen BDs einfach zu früh dran und haben "Pech gehabt"?
Zu früh nicht. Aber wenn du nur eine Architektur hast, die AVX beherrscht, brauchst du auch kein Bit zur Differenzierung. Die optimale Verarbeitung der Instruktionen ist dort ja immer gleich. Erst mit Jaguar kommt jetzt eine zweite Architektur hinzu, die AVX beherrscht, hardwareseitig aber eben nur mit der halben Breite der AVX Pipeline. Ob man mit dem CPUID Bit in Zukunft auch bei Bulldozer sinnvoll differenzieren kann, bleibt abzuwarten. Du darfst natürlich gerne auf reine 256-bit FMACs spekulieren. Aber für mich ist es einfach noch zu früh für konkrete Spekulationen. Das lässt sich mMn anhand des CPUID Bits nicht zweifelsfrei herleiten. Der aktuelle Sinn dieses Bits ist für mich aufgrund folgender zwei Fälle hingegen klar nachvollziehbar:

Bulldozer: 256-bit AVX, 1 Takt
Jaguar: 256-bit AVX, >1 Takt

Einmal 128bit = 0 und einmal = 1 ist ne Änderung der Logik.
Das ist nicht die Logik hinter dem Bit. Die Logik beim FP128 Bit war:

Fall 1: teilweise bzw halbe Breite der ISA Pipeline auf Hardwareebene
Fall 2: volle Breite der ISA Pipeline auf Hardwareebene

Welcher Fall dann mit Wert 0 und Wert 1 im Bit belegt wird, ist erst mal nebensächlich. Die Zuordnung sollte nur immer gleich sein, auch beim FP256 Bit. Das meinte ich mit "man ändert nicht einfach die Logik solcher Bits".
 
@gruffi:
AVX, FMA, whatever bezeichnen SIMD-Befehlssatzerweiterungen. D.h. ein Satz von z.B. 64Bit breiten DP-Werten in einem breiteren Vektorregister wird von einem einzigen SIMD-Befehl als Operand konsumiert. Da wird intern gar nichts an den Befehlen aufgeteilt, nur die eigentlichen (Vektor-)ALUs müssen die entsprechenden Datenformate unterstützen.

Bei Bulldozer/Piledriver mit den beiden 128Bit FMACs werden 128Bit SIMD-Befehle vom Decoder in interne 128Bit SIMD-µOps übersetzt (im Optimierungsmanual als fastpath singles gekennzeichnet), die dann die 128Bit breiten SIMD-Einheiten befeuern. Im Fall von 256Bit SIMD-Anweisungen (also AVX256) spucken die Decoder für jeden einzelne 256Bit AVX-Instruktion zwei 128Bit µOps aus. Dies ist im Optimierungsmanual dadurch gekennzeichnet, daß der Dekodierungstyp als fastpath doubles angegeben wird. Diese 128Bit µOps werden dann genau so ausgeführt, wie das auch bei 128Bit AVX-Instruktionen der Fall wäre, nämlich in 128Bit-Häppchen. Dies kann je nach Instruktion und Auslastung der Einheiten nacheinander auf der gleichen Einheit oder parallel auf beiden Einheiten stattfinden. Aber immer passiert die Ausführung in 128Bit-Häppchen.
Kommt jetzt Excavator (oder irgendeine andere CPU) mit 256Bit FMAC-Einheiten, ergibt die Aufteilung in 128Bit-Häppchen natürlich keinen Sinn mehr, da damit die breiteren Einheiten schlicht brachliegen würden. Es werden demzufolge zwingend 256Bit µOps für den internen Gebrauch eingeführt werden und die 256Bit AVX-Instruktionen vom Dekoder in einzelne 256Bit µOps übersetzt werden, die dann den kompletten 256Bit breiten Vektor in einem Rutsch ohne Aufteilung bearbeiten werden. In einem zukünftigen Optimierungsmanual werden dann diese 256Bit SIMD-Instruktionen als Fastpath singles gekennzeichnet werden.
Lies Dir einfach die Optimierungsmanuals durch und schaue Dir an, wie die Nomenklatur da aussieht und wie sich das bei einer Verbreiterung der SIMD-Einheiten in der Vergangenheit entwickelt hat! Das ist wirklich ziemlich straightforward, man muß sich nur die Mühe machen, es mal zu lesen und zu durchdenken.

TLDR:
Opteron liegt richtig.
 
Um mal deinen Gedanken aufzugreifen, der würde mMn nur Sinn machen, wenn man in Zukunft die FMACs auf 256-bit aufbohrt, der 128-bit Durchsatz aber gleich bleibt. Also entweder können zwei 128-bit oder zwei 256-bit Instruktionen pro Takt ausgeführt werden. Dann ändert sich das 128:256-bit Verhältnis von 2:1 auf 1:1. Und dann hätte das CPUID Bit auch hier einen Sinn. Beim Verhältnis von 1:1 wären natürlich 256-bit Instruktionen zu bevorzugen. Nur, warum sollte man das machen? Ich hatte es ja zuvor schon erwähnt, dann würde die FPU oft nur halb ausgelastet werden, weil entweder SSE Code ausgeführt wird oder die Programmlogik gar nicht so viele 256-bit Instruktionen beinhaltet.
Wir sind uns einig? Ja genau in dem Fall wäre das FP256 Bit nötig und das ist genau der Fall, den ich erwarte, deshalb auch die News.

Wieso man das macht? Frag am besten Intel, die machen das seit SandyB eben genau so. Hier im Thread gabs glaub ich schon Hinweise wieso sich mehrere 128bit Pipes nicht rechnen. Erstens muss pro Pipe auch ne Instruktion dekodiert werden (wäre jetzt mit dem Steamroller Decodern wohl nicht das Problem), zweitens scheinen zusätzliche Ports am FP-Scheduler ziemlich teuer in Hinsicht auf Die-Fläche und Stromverbrauch zu sein. Intel hat bei Ihrem Design ja fast immer 3 Ex-Units an einem Port und AMD streicht jetzt beim Steamroller (oder dem nächsten Design) auch nen Port und flanscht die betroffene Ex-Unis an nen anderen Port. Wahrscheinlich rentiert es sich aber auch schlicht gar nicht. Alter Legacycode hat im Schnitt wohl nicht mehr als 2 128bit SSE-Instruktionen, da es damals nicht mehr Pipes gab. Da wären 4 128er Pipes wohl zu viel. Da müsste man die Sourcen erst wieder durch den Compiler jagen, aber wenn man das macht, dann kann man auch gleich 256bit Code erzeugen lassen.

Aber was auch immer der Grund ist, im Endeffekt sind diese tiefen Gründe für AMD nebensächlich. Intel machts so, Intel propagiert AVX256, ergo wird sich das mittel- und langfristig durchsetzen. Intel ist nunmal der x86-ISA-King.

Effizienter wäre, die FMACs auf 256-bit aufzubohren, diese aber auch bei Bedarf in zwei 128-bit Teile aufzusplitten, oder eben einfach zwei weitere 128-bit FMACs hinzuzufügen. Am 128:256-bit Verhältnis gegenüber dem aktuellen Design ändert sich dadurch nichts. Wir hätten dann lediglich die doppelte Breite auf beiden Seiten. Sozusagen statt 256-bit pro Modul 256-bit pro Thread. Die Preisfrage ist nun, welchen Sinn hat das CPUID Bit hier? Ich sehe keinen wirklichen. Ob du aktuell 2x 128-bit oder 1x 256-bit bzw in Zukunft 4x 128-bit oder 2x 256-bit ausführst, der theoretische Durchsatz bleibt der gleiche.
Siehe oben, ob das effizienter wäre kommt auf dem Code an. Dass im Schnitt mehr als 2 SSE Instruktionen pro Takt anfallen glaub ich nicht. Gut - jetzt könnte man einwerfen, dass die BD-FPU ja 2 Threads verwalten. Ja da wären dann 4x128er Pipes eventuell noch sinnvoll. Aber da kommt dann wieder das Zeitargument. Wie wichtig ist SSE128bit Code in 2-3 Jahren oder in 5 Jahren?

Der aktuelle Sinn dieses Bits ist für mich aufgrund folgender zwei Fälle hingegen klar nachvollziehbar:

Bulldozer: 256-bit AVX, 1 Takt
Jaguar: 256-bit AVX, >1 Takt
Ja aber beide haben das FP256bit auf 0. Das macht keinen Sinn. Eben weil BD = 1 Takt und Jaguar 2 Takte.

Das ist nicht die Logik hinter dem Bit. Die Logik beim FP128 Bit war:

Fall 1: teilweise bzw halbe Breite der ISA Pipeline auf Hardwareebene
Fall 2: volle Breite der ISA Pipeline auf Hardwareebene
Mißverständnis, ich meinte damit das FP256 bit, nicht das 128er. Von 128 bit sprach ich, da Du je meintest, dass ein eventueller, zukünftiger BD - der immer noch eine 128bit FPU hat - das FP256 Bit auf 1 setzen könnte.

Welcher Fall dann mit Wert 0 und Wert 1 im Bit belegt wird, ist erst mal nebensächlich. Die Zuordnung sollte nur immer gleich sein, auch beim FP256 Bit. Das meinte ich mit "man ändert nicht einfach die Logik solcher Bits".
Jo das meinte ich auch, die Zuordnung sollte die gleich sein. Eben deshalb macht es keinen Sinn, das Bit bei den aktuellen BDs auf 0 zu haben und es irgendwann später bei BDv4 oder v5 auf 1 zu setzen, obwohl das Teil immer noch ne 128bit FPU hätte. Das wäre unlogisch und inkonsistent.

Logisch und sinnvoll ist es nur für den Fall, wenn BDv4 / v5 ne 256Bit FPU bekommen.

Edit: Gipsel war schneller.
 
AVX, FMA, whatever bezeichnen SIMD-Befehlssatzerweiterungen. D.h. ein Satz von z.B. 64Bit breiten DP-Werten in einem breiteren Vektorregister wird von einem einzigen SIMD-Befehl als Operand konsumiert. Da wird intern gar nichts an den Befehlen aufgeteilt, nur die eigentlichen (Vektor-)ALUs müssen die entsprechenden Datenformate unterstützen.

Bei Bulldozer/Piledriver mit den beiden 128Bit FMACs werden 128Bit SIMD-Befehle vom Decoder in interne 128Bit SIMD-µOps übersetzt (im Optimierungsmanual als fastpath singles gekennzeichnet), die dann die 128Bit breiten SIMD-Einheiten befeuern. Im Fall von 256Bit SIMD-Anweisungen (also AVX256) spucken die Decoder für jeden einzelne 256Bit AVX-Instruktion zwei 128Bit µOps aus.
Erst werden Befehle nicht aufgeteilt und jetzt doch? Ja wie denn nun? :]

Dies ist im Optimierungsmanual dadurch gekennzeichnet, daß der Dekodierungstyp als fastpath doubles angegeben wird. Diese 128Bit µOps werden dann genau so ausgeführt, wie das auch bei 128Bit AVX-Instruktionen der Fall wäre, nämlich in 128Bit-Häppchen. Dies kann je nach Instruktion und Auslastung der Einheiten nacheinander auf der gleichen Einheit oder parallel auf beiden Einheiten stattfinden. Aber immer passiert die Ausführung in 128Bit-Häppchen.
Wo sind deine Neuigkeiten? Du kommst reichlich spät. Die ganze Diskussion hatten wir schon.

Kommt jetzt Excavator (oder irgendeine andere CPU) mit 256Bit FMAC-Einheiten, ergibt die Aufteilung in 128Bit-Häppchen natürlich keinen Sinn mehr, da damit die breiteren Einheiten schlicht brachliegen würden.
Was bei SSE natürlich nicht der Fall wäre.

TLYSRF:
Gipsel liegt falsch.


Ja genau in dem Fall wäre das FP256 Bit nötig und das ist genau der Fall, den ich erwarte, deshalb auch die News.
Wir sind uns hoffentlich aber auch einig, dass das nicht der einzige Fall ist? Insofern bleibt dein Artikel für mich mehr als spekulativ. Eindeutig daran ist für mich nichts. Der Ursprung des FP128 Bit ist jedenfalls ein anderer.

Wieso man das macht? Frag am besten Intel, die machen das seit SandyB eben genau so.
Die schalten dort doch auch nur zwei 128-bit Einheiten zusammen.

Mißverständnis, ich meinte damit das FP256 bit, nicht das 128er.
Schon klar. Die Logik hinter diesen Bits ändert sich deshalb ja nicht. Ich wollte nur nochmal klarstellen, wie sie ursprünglich entstanden sind.

Jo das meinte ich auch, die Zuordnung sollte die gleich sein. Eben deshalb macht es keinen Sinn, das Bit bei den aktuellen BDs auf 0 zu haben und es irgendwann später bei BDv4 oder v5 auf 1 zu setzen, obwohl das Teil immer noch ne 128bit FPU hätte. Das wäre unlogisch und inkonsistent.
Inkonsistent wäre es nicht per se. Das FP256 Bit gab es noch nicht als Bulldozer entwickelt wurde. Dafür kann man die CPUID Implementierung im aktuellen Bulldozer ja schlecht verantwortlich machen. Diese "Inkonsistenz" ist mMn an der Stelle einfach vernachlässigbar. Egal ob du das Bit für den aktuellen Bulldozer auf 0 oder 1 setzt bzw zwei 128-bit oder eine 256-bit AVX Instruktion generierst, in beiden Fällen ist der theoretische Durchsatz der gleiche.
 
Zuletzt bearbeitet:
Erst werden Befehle nicht aufgeteilt und jetzt doch? Ja wie denn nun? :]
Das bezog sich offensichtlich auf die von Dir postulierte Aufteilung von SIMD-Instruktionen auf das 32bit oder 64bit Level der einzelnen Werte im Vektor. Die findet nicht statt. Ein (interne µOp-) Instruktion kann die komplette, physisch implementierte Vektorbreite abarbeiten. Das ist der Kernpunkt von SIMD-Instruktionen und Quell ihrer Effizienz.
Daß man auch Instruktionen, die breitere Vektoren nutzen als physisch implementiert, unterstützen kann (nämlich recht einfach über Aufteilung z.B. der breiteren AVX-Ops in zwei schmalere interne µOps), bleibt davon ja unbenommen. Die internen µOps bearbeiten trotzdem die komplette Breite der physisch vorhandenen Einheiten und werden nicht nochmal in der Granularität einzelner Singles oder Doubles gesplittet, wie Du das zu behaupten schienst. Der einzige Vorteil davon (also dem Support von 256bit Instruktionen mit 128Bit-Einheiten) ist üblicherweise Kompatibilität.
Wo sind deine Neuigkeiten? Du kommst reichlich spät. Die ganze Diskussion hatten wir schon.
Ich weiß. Du hast sie sehr offensichtlich nur nicht verstanden und ich habe mal gehört, daß Wiederholung manchmal dem Lernerfolg zuträglich sein kann. ;)
Was bei SSE natürlich nicht der Fall wäre.
Da wäre das natürlich auch der Fall. :]
Gerade ausgedacht? *lol*

Zusammenfassung:
Zukünftige BD-Derivate (also z.B. Excavator oder wann das auch kommt) werden 256bit breite SIMD-Einheiten verbaut haben statt heute 128bit breite (das im Manual erwähnte Bit signalisiert genau deren Vorhandensein) und dann die 256Bit SIMD-Instruktionen in einzelne µOps dekodieren (fastpath singles) statt heute in zwei. Du kannst mich gerne damit in Zukunft zitieren.
 
Die schalten dort doch auch nur zwei 128-bit Einheiten zusammen.
Nö, wie kommst Du darauf?
Da verwechselst DU vermutlich etwas mit Intels-Recycling der 128bit Datenleitungen der INT-Units. Wohlgemerkt nur die Datenleitungen nicht die Exec-Units, die INT-Exec-Units könnten mit den FP-Zahlen von AVX auch recht wenig anfangen ;-) Die FP-Exec-Units sind volle 256bit breit.

Nachzulesen bei RWT:
The execution units in Sandy Bridge were reworked to double the FP performance for vectorizable workloads by efficiently executing 256-bit AVX instructions. Almost all 256-bit AVX instructions are decoded into and execute as a single uopin contrast to AMD’s more cautious embrace of AVX, which will crack 256-bit instructions into two 128-bit operations on Bulldozer.
http://www.realworldtech.com/sandy-bridge/6/

Weiter unten wird das dann auch mit den Datapaths erklärt. Ist halt Intels Vorteil des integrierten INT+FP-Designs, bei AMDs Design mit der Trennung zw. INT und FP geht das nicht, aber dafür läuft die FPU auch mit 2 Threads.

Inkonsistent wäre es nicht per se. Das FP256 Bit gab es noch nicht als Bulldozer entwickelt wurde. Dafür kann man die CPUID Implementierung im aktuellen Bulldozer ja schlecht verantwortlich machen.
Verantwortlich oder nicht, Du hast selbst gesagt, dass man versucht "Konsistent" zu bleiben und nun verwässerst Du Deine eigene Argumentation von gestern.
Inkonsistent ist inkonsistent, "halb inkonsistent" oder ein "bisschen konsistent" gibts nicht.

Diese "Inkonsistenz" ist mMn an der Stelle einfach vernachlässigbar.
Oho-Oho ... na da lehnst Du Dich aber gewaltig aus dem Fenster.
Dazu hatte ich schon früher was geschrieben. Wenn Dus ignorieren willst, dann musst Du den Fall mit ner Extra-Abfrage der CPU Family/Model abfangen. In dem Fall könntest Du Dir das FP256-Bit aber auch gleich ganz sparen, da dann nicht viel gewonnen wäre.

Egal ob du das Bit für den aktuellen Bulldozer auf 0 oder 1 setzt bzw zwei 128-bit oder eine 256-bit AVX Instruktion generierst, in beiden Fällen ist der theoretische Durchsatz der gleiche.
Lol, ja der Durchsatz ist bei Dir der gleiche und das Bit ist trotzdem verschieden, sehr sinnvoll das Ganze. *lol*

Kurz: Du lieferst keine Erklärung des FP256 Bits.

Nichts für ungut, aber da halte ich mein Argumentation für deutlich schlüssiger, denn die ist im Gegensatz zu Deiner konsistent und damit laut Deiner eigenen Aussage:
Man versucht konsistent zu bleiben.
.. die Wahrscheinlichere.

Ich bin dann aber wieder raus, wenn jemand plötzlich seine eigene Argumentation von vor 1-2 Tagen "vernachlässigt", ist die Diskussion darüber ebenfalls vernachlässigbar.
 
Wohlgemerkt nur die Datenleitungen nicht die Exec-Units
Natürlich waren die Datenpfade mit den dazugehörenden Einheiten gemeint. Du sprachst doch die ganze Zeit von Fastpath Single und Fastpath Double Ops. Das sind bei SB eben auch nur 128-bit Datenpfade. Wie die ALUs dann intern aufgebaut sind, interessiert mich an der Stelle gar nicht. Ich wäre aber vorsichtig, zu behaupten, man würde hier vorhandene Logik nicht recyceln. Ich denke nicht, dass es nur Zufall ist, dass man VI MUL auf der Folie überschreibt.

Verantwortlich oder nicht, Du hast selbst gesagt, dass man versucht "Konsistent" zu bleiben
Und genau das ist die Begründung dafür. Du scheinst nicht zu verstehen, was Konsistenz in dem Zusammenhang bedeutet. Nochmal, es geht nicht darum, ob ein Bit nun auf 0 oder 1 gesetzt wird. Es geht darum, wie ein Bit definiert wird. Ob die Chronologie der Entwicklung dann dazu passt, ist ein anderes Thema. Und das kann man Bulldozer nicht vorwerfen.

Wenn Dus ignorieren willst, dann musst Du den Fall mit ner Extra-Abfrage der CPU Family/Model abfangen.
Nein. Wenn man's ignoriert, fragt man gar nichts ab. Man fragt maximal die Unterstützung von AVX ab, fertig. Für den Rest nimmt man dann einfach die AVX Instruktionen, die am geeignetsten für die Umsetzung der Programmlogik sind.

ja der Durchsatz ist bei Dir der gleiche und das Bit ist trotzdem verschieden
Wenn der theoretische Durchsatz gleich ist, spielt das Bit keine Rolle. Ob Sinn oder Unsinn ist dann irrelevant.

Kurz: Du lieferst keine Erklärung des FP256 Bits.
Doch, das habe ich bereits im ersten Beitrag getan. Wenn du es nicht verstehst oder verstehen willst, kann ich dir leider auch nicht weiterhelfen. Aber du solltest zumindest akzeptieren, dass es auch andere Meinungen und Sichtweisen gibt. Kurz: ich sehe aktuell keine Beweise für deine Behauptung. Insofern bleibt das für mich Spekulation.

Nichts für ungut, aber da halte ich mein Argumentation für deutlich schlüssiger, denn die ist im Gegensatz zu Deiner konsistent
Welche Konsistenz? Ich sehe keine Konsistenz bei dir. Ich sehe nur die Spekulation einer möglichen zukünftigen Option für 256-bit FMACs, mehr nicht. Die ich übrigens teile, nur als Info. Ich teile aber nicht das Herleiten dieser Option anhand des CPUID Bits. Und erklärt hast du das auch nicht. Du gehst ja nicht mal auf den Unterschied zwischen Bulldozer und Jaguar diesbezüglich ein. Meine Erklärung für das FP256 Bit ist hingegen konsistent zum FP128 Bit.


Das bezog sich offensichtlich auf die von Dir postulierte Aufteilung von SIMD-Instruktionen auf das 32bit oder 64bit Level der einzelnen Werte im Vektor.
...
Die internen µOps bearbeiten trotzdem die komplette Breite der physisch vorhandenen Einheiten und werden nicht nochmal in der Granularität einzelner Singles oder Doubles gesplittet, wie Du das zu behaupten schienst.
Das habe ich weder so geschrieben noch behauptet. Du solltest erst mal den Thread richtig lesen, bevor du solch überflüssige und falsch dargestellte Beiträge verfasst.

Zukünftige BD-Derivate (also z.B. Excavator oder wann das auch kommt) werden 256bit breite SIMD-Einheiten verbaut haben
Schön, diese Option habe ich auch gar nicht in Frage gestellt und darum ging's in der Diskussion auch gar nicht. Rest, siehe oben.

Da wäre das natürlich auch der Fall.
Scheinbar verstehst du nicht mal Sarkasmus.

Gerade ausgedacht?
Wenn du trollst, darf ich das auch. *lol*

Ich weiß. Du hast sie sehr offensichtlich nur nicht verstanden und ich habe mal gehört, daß Wiederholung manchmal dem Lernerfolg zuträglich sein kann.
Na du musst es ja wissen. Das eigene Verhalten auf andere projizieren zu wollen, ist nicht nur stillos und kindisch, sondern macht die eigenen Aussagen übrigens auch nicht besser. Auch das solltest du wissen. Und nur zur Info, den SOG kenne ich vermutlich sogar besser als du. Also kannst du dir den Oberlehrer sparen. ;)
 
Doch, das habe ich bereits im ersten Beitrag getan. Wenn du es nicht verstehst oder verstehen willst, kann ich dir leider auch nicht weiterhelfen.
Na dann schauen wir doch mal in Deinen ersten Beitrag hier:
Ich interpretiere das Bit ehrlich gesagt anders. In Bulldozer werden 256-bit Instruktionen nicht in 128-bit aufgeteilt. Die Instruktionen können mit voller Breite in einem Takt verarbeitet werden.
Das ist schlicht falsch. BD kann 256Bit Instruktionen eben nicht direkt in voller Breite abarbeiten. Er besitzt keine 256Bit Pipeline(s), sondern multiple 128Bit-Pipelines (weswegen die 256Bit Instruktionen ja auch in zwei 128bittige interne µOps aufgeteilt werden). Wenn das mal zu Dir durchdringen sollte, dann wird auch Dir einleuchten, daß das fragliche Bit zur Kennzeichnung von Pipelines mit 256Bit Breite gedacht ist (was zur Auswahl von entsprechend optimiertem Code zur Laufzeit recht hilfreich sein kann).
Da steht auch nichts von 256-bit Operationen. Wie gesagt, am Ende wird eh alles auf FP32 und FP64 Operationen heruntergebrochen.
Scheinbar verstehst du nicht mal Sarkasmus.
Okay, dann verstehe ich mit der gleichen Berechtigung Deine Theorie zur Bedeutung des Flags mit der Beschreibung "256-bit instructions are executed with full width internal operations and pipelines rather than decomposing them into internal 128-bit suboperations" ebenfalls als Sarkasmus. Das ist nämlich genauso Blödsinn wie die SSE-Bemerkung. Ich meine, wieviel klarer willst Du es noch buchstabiert haben, was der Unterschied an der FPU im Vergleich zu BD/PD/SR mit ihren 128Bit-Pipelines und demzufolge ungesetztem FP256-Flag sein wird? *noahnung*
Wenn du trollst, darf ich das auch. *lol*
Google mal, wann, wie und warum man TLDR benutzt. Mein Gebrauch war vollkommen korrekt. Du mußt die Unkenntnis dieser Abkürzung nicht mit dem Vorwurf eines Trollversuchs kaschieren. ;)

Na mal sehen, ob das jetzt ankommt. Das nächste Mal darf Opteron dann wieder antworten. :]
 
Na dann schauen wir doch mal in Deinen ersten Beitrag hier:
Das ist schlicht falsch.
Nein, ist es nicht. Wie ich schon sagte, du solltest erst mal den gesamten Thread lesen und hier nicht einzelne Sätze rauspicken. Ich schrieb ausführlicher, was ich unter Aufteilung gemeint habe:
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.
Es ging um die Aufteilung pro Takt und nicht um die Aufteilung im selben Takt. Ob Bulldozer nun eine oder zwei MacroOps im selben Takt generiert, ist für mich nicht relevant und war gar nicht mein Thema. Wenn du es zum Thema machen willst, bitteschön. Dann solltest du aber aufhören, auf meine Beiträge zu antworten. Am Durchsatz der AVX Instruktionen ändert das jedenfalls nichts.

Das ist nämlich genauso Blödsinn wie die SSE-Bemerkung.
Nein, ist es natürlich nicht. Bei der SSE Bemerkung ging es um das hypothetische reine 256-bit FMAC Design, wo die Hälfte der Rechenkapazitäten bei SSE Code oft brach liegt und was für mich nicht gerade eine effizientes Design wäre. Aber das bekommt man eben nur mit, wenn man die Diskussion verfolgt und die Beiträge sorgfältig liest.

Google mal, wann, wie und warum man TLDR benutzt. Mein Gebrauch war vollkommen korrekt.
Der Rest war trotzdem nichts weiter als Trollerei, was dein TLDR eindeutig belegt. Man sollte eben doch erst alles sorgfältig lesen und nicht glauben, weil man ein oder zwei Aussagen gelesen hat, wüsste man, worum es geht. Und im Gegensatz zu dir scheine ich auch zu wissen, was Abkürzungen bedeuten. *lol*

Ich glaube, du könntest den Reality Check wesentlich besser gebrauchen. Sich einfach einzuklinken, einzelne Sätze rauszupicken, ohne die Diskussion verfolgt zu haben, ist wie gesagt stillos und kindisch. Ganz abgesehen davon, dass deine Einwände unbegründet sind und damit keinem geholfen ist. Du hast mir jedenfalls nichts erzählt, was ich nicht eh schon wusste. Und für alle, die die Diskussion mitverfolgt haben, im Gegensatz zu dir ;) , gilt das gleiche.
 
Zuletzt bearbeitet:
Na mal sehen, ob das jetzt ankommt. Das nächste Mal darf Opteron dann wieder antworten. :]
Ne, ich bin doch raus :)

Die Argumente liegen glasklar auf dem Tisch. Die werden hier nur wiederholt, worauf wieder Nullaussagen kommen oder aber die Mär von der plötzlichen "Vernachlässigbarkeit" erzählt wird. Ja, steter Tropfen höhlt den Stein, aber ich verstehe mich nicht als Stalaktit ;)

Wers aus irgendwelchen Gründen nicht glauben will, erlebt halt bei einer zukünftigen AMD-Architekturpräsentation in 2-3 Jahren eine dicke Riesenüberraschung in Form der total unerwarteten 256bit FPUs. Da will ich mal kein böser Spielverderber sein und die gespannte Vorfreunde auf das unbekannte Etwas nicht schmälern.
 
Wers aus irgendwelchen Gründen nicht glauben will, erlebt halt bei einer zukünftigen AMD-Architekturpräsentation in 2-3 Jahren eine dicke Riesenüberraschung in Form der total unerwarteten 256bit FPUs.
Das zeigt mir eigentlich glasklar, dass du, und auch Gipsel, gar nicht verstehst oder verstehen willst, was ich sage. Mehr als wiederholen kann ich mich nicht.
Ich sehe nur die Spekulation einer möglichen zukünftigen Option für 256-bit FMACs, mehr nicht. Die ich übrigens teile, nur als Info. Ich teile aber nicht das Herleiten dieser Option anhand des CPUID Bits.
Insofern ist deine sture Haltung ziemlich intolerant und völlig überflüssig. Naja, zumindest hast du deine Nullaussagen eingesehen. Wenigstens etwas.
 
Nein, ist es nicht. Wie ich schon sagte, du solltest erst mal den gesamten Thread lesen und hier nicht einzelne Sätze rauspicken. Ich schrieb ausführlicher, was ich unter Aufteilung gemeint habe:
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.
Es ging um die Aufteilung pro Takt und nicht um die Aufteilung im selben Takt. Ob Bulldozer nun eine oder zwei MacroOps im selben Takt generiert, ist für mich nicht relevant und war gar nicht mein Thema.
Es ist vielleicht für Dich nicht relevant, aber es ist entscheidend für das Flag, um welches sich dieser Thread dreht. *buck*
Im Übrigen solltest Du vielleicht nochmal die Argumentation mit dem K8 überdenken. Eine ganze Latte von double decode Instruktionen kann der nämlich auch mit Durchsatz 1 durchschleusen (gibt sogar ein paar Vectordecode-Instruktionen mit Durchsatz 1). Nämlich immer, wenn die internen µOps sowohl in der ADD-, als auch der MUL-Pipe ausgeführt werden können (trifft z.B. bei SSE2 auf die ganzen PADDx-, PANDx-, PAVGx-, PCMPxxx-, PMINxx-, PMAXxx-, POR-, ein paar Shuffles usw. Instruktionen zu, falls Du nachschauen willst [ich zähle hier bestimmt nicht über 2 Seiten alle im Detail auf]). Auch bei diesen auf 128Bit operierenden Instruktionen können also trotz Aufteilung in interne 64Bit-Ops, die beiden internen Ops parallel in einem einzigen Takt zum Issue kommen. Das FP128-Flag ist allerdings trotzdem erst bei CPUs gesetzt, die wirklich 128Bit Pipelines haben. Dies ist auch bei Bulldozer der Fall (die einzelnen Pipelines wurden durch die FMAC-Einheiten bloß etwas flexibler, aber alles können die auch nicht!), wo ebenfalls und tatsächlich AVX256-Instruktionen in (meistens) zwei 128Bit µOps aufgeteilt werden, die dann so zum Issue kommen, wie es nach den Umständen möglich ist (das muss nicht parallel erfolgen, was bei einigen Befehlen auch schlicht gar nicht möglich ist, z.B. bei VBLENDVPD, Permutations/Shuffle- oder Rundungs-Befehle, die nur eine Pipeline kann; gar nicht so wenige sind sogar microcoded, weil die Aufteilung auf zwei 128Bit-Hälften bei einigen Befehlen nicht so einfach klappt).
Das FP256-Flag wird gesetzt werden, wenn die Pipelines 256Bit breit sind, exakt so, wie es die Beschreibung des Flags auch aussagt. Da gibt es schlicht nicht das Geringste zu diskutieren. Außer einer gewissen Ignoranz gegenüber Fakten vielleicht.
Wenn du es zum Thema machen willst, bitteschön. Dann solltest du aber aufhören, auf meine Beiträge zu antworten. Am Durchsatz der AVX Instruktionen ändert das jedenfalls nichts.
Vielleicht solltest Du mal in der Realität ankommen, in der die im Eingangspost zitierte Dokumentation verfaßt wurde. Aber wenn Du lieber im Imaginären bleiben willst, dann erhebe nicht den Anspruch, daß sich Deine Posts auf die Wirklichkeit beziehen. Dann bist Du hier im Thread nämlich OT. ;)
Und na klar ändert sich mit 256Bit Pipelines gleicher Anzahl was am Durchsatz, der verdoppelt sich dann nämlich mit AVX256-Instruktionen :]. Das ist für die Auswahl der benutzten Instruktionen durchaus wichtig zu wissen, weswegen das fragliche Flag dem laufenden Programm helfen kann zu entscheiden, welche Codeversion es denn nun verwendet, um die optimale Performance zu erreichen. Nur dafür gibt es doch das Flag überhaupt.

PS:
Was die Verwendung von TLDR zur Ankündigung einer Kurzzusammenfassung am Ende eines Posts mit Trollerei zu tun haben soll, kannst Du mir gerne per PN mitteilen. Aber bei Dir ist ja offenbar alles ein Troll, was nicht in Deiner Phantasiewelt lebt. Ich bitte höflichst um Entschuldigung, daß Du von Einigen hier mit der Realität belästigt wirst.
 
Habe eben mal einen FX-8120 betr. Ermittlung der µOps getestet (PMCx0C1 Retired µops; BKDG for AMD Family 15h Models 00h-0Fh Processors, S.598 ).
Als Beispiel habe ich Double Precision Multiplikation verwendet (irgendwas muss man ja nehmen :)). XMM sind 128-Bit-Register; YMM sind 256-Bit-Register.
Ergebnis für "VMULPD xmm0,xmm1,xmm2" : 1 µOp
Ergebnis für "VMULPD ymm0,ymm1,ymm2" : 2 µOps.
Damit hier auch mal was Fachliches steht.
Helle
 
Habe eben mal einen FX-8120 betr. Ermittlung der µOps getestet (PMCx0C1 Retired µops; BKDG for AMD Family 15h Models 00h-0Fh Processors, S.598 ).
Als Beispiel habe ich Double Precision Multiplikation verwendet (irgendwas muss man ja nehmen :)). XMM sind 128-Bit-Register; YMM sind 256-Bit-Register.
Ergebnis für "VMULPD xmm0,xmm1,xmm2" : 1 µOp
Ergebnis für "VMULPD ymm0,ymm1,ymm2" : 2 µOps.
Damit hier auch mal was Fachliches steht.
Helle
Das muß man nicht unbedingt ausprobieren, falls man den Optimierungs-Guides von AMD vertraut ;). Da steht das genau so drin.
Es ist ja keine Frage, daß AVX-Instruktionen, die mit den 256Bit breiten YMM-Registern operieren, meist in zwei µOps zerlegt werden (bei ein paar werden es mehr als zwei). Und wenn in einer zukünftigen CPU mal dieses FP256-Flag gesetzt ist, dann wird das in nur noch eine µOp übersetzt und auch direkt auf 256Bit breiten Einheiten abgearbeitet werden.
 
Vertrauen ist gut, aber Kontrolle ist besser :)! Aber klar, bei einem anderen Ergebnis wäre ich ins grübeln gekommen.
Apropos grübeln: Lt. Intels CPUID (May 2012) kennen Intel CPUs die Funktion 8000001Ah nicht (max.80000008h) und mein Ivy Bridge meldet auch max.80000008h, aber nun ratet mal, was CPUID/8000001Ah/EAX bei IB meldet: Bit 0-2 gesetzt! Mein i7-920 meldet Bit 0 gesetzt. Zufall oder "geheime" CPUID-Funktionen von Intel? Nicht dokumentierte MSRs gibt es ja zur Genüge, aber sowas? Wäre etwas zu simpel.
Meine persönliche Meinung zu diesen Bits (0-2): Würde ich als Programmierer in einem Anwendungs-Programm nie auswerten. Sollen ja auch der Optimierung dienen, wären also etwas für Benchmarks.
In diesem Sinne
Helle

Edit: Das mit Intel bitte ganz schnell vergessen. Es ist zwar reproduzierbar, aber blanker Zufall. Sorry!
 
Zuletzt bearbeitet:
@Helle:
Also Intel unterstützt die Bits? *kopfkratz
Hoffentlich bedeutet es nicht irgendwas anderes ^^

Wenn Bit 2 (also das FP256 Flag) aber jetzt schon bei Intel gesetzt ist, wirds merkwürdig ... das käme dann ja von Intel? *noahnung*
 
Es ist vielleicht für Dich nicht relevant, aber es ist entscheidend für das Flag, um welches sich dieser Thread dreht.
Das ist lediglich deine Interpretation bzw Spekulation. Und genauso wie ich diese respektiere, solltest du meine respektieren. Ich habe meine Meinung geschrieben und mehr nicht. Und da hier sowieso nur spekuliert wird, gibt es kein richtig oder falsch. Um nochmal deinen unsinnigen ersten Beitrag aufzugreifen. Deine respektlosen, aggressiven und oberlehrerhaften Einwände kannst du dir hier jedenfalls sparen. Erst recht, wenn sie so unnütz sind.

Im Übrigen solltest Du vielleicht nochmal die Argumentation mit dem K8 überdenken. Eine ganze Latte von double decode Instruktionen kann der nämlich auch mit Durchsatz 1 durchschleusen (gibt sogar ein paar Vectordecode-Instruktionen mit Durchsatz 1).
Vielleicht solltest du deine Argumentation nochmal überdenken. K8 kann jedenfalls keine 128-bit (packed) FP Instruktionen in einem Takt. Was K8 mit Integer oder scalar Instruktionen kann, ist hier überhaupt nicht von Belang. Du weisst schon, was das "FP" in FP256 bedeutet? :]

Und na klar ändert sich mit 256Bit Pipelines gleicher Anzahl was am Durchsatz, der verdoppelt sich dann nämlich mit AVX256-Instruktionen
Danke, aber du musst nicht ständig dein mangelhaftes Textverständnis zum besten geben. Das ist schon längst angekommen. Nein, am AVX Durchsatz ändert es überhaupt nichts, ob du beim aktuellen Bulldozer zwei 128-bit oder eine 256-bit AVX Instruktion ausführst.

Und deine Trollerei und deine permanenten persönlichen Angriffe bestätigen leider nur das traurige Bild, das du hier abgibst. Aber gut, ich will dir deine Traumwelt gar nicht kaputtmachen. Ich weiss, wo ich lebe. Du anscheinend nicht.


Habe eben mal einen FX-8120 betr. Ermittlung der µOps getestet (PMCx0C1 Retired µops; BKDG for AMD Family 15h Models 00h-0Fh Processors, S.598 ).
Als Beispiel habe ich Double Precision Multiplikation verwendet (irgendwas muss man ja nehmen :)). XMM sind 128-Bit-Register; YMM sind 256-Bit-Register.
Ergebnis für "VMULPD xmm0,xmm1,xmm2" : 1 µOp
Ergebnis für "VMULPD ymm0,ymm1,ymm2" : 2 µOps.
Ja, aber das war doch sowieso klar und gar nicht das Thema. Das Thema war, ob beides in einem Takt ausgeführt werden kann oder nicht. Bitte nicht von Gipsel verunsichern lassen. Der redet völlig am Thema vorbei.

Übrigens, die Bits ab 80000000h sind sowieso herstellerspezifisch. Ich würde da keine Konsistenz erwarten.
 
Ja, aber das war doch sowieso klar und gar nicht das Thema. Das Thema war, ob beides in einem Takt ausgeführt werden kann oder nicht. Bitte nicht von Gipsel verunsichern lassen. Der redet völlig am Thema vorbei.
Und hier ist die Antwort ganz einfach.
Bei der Nutzung von einem Kern des Modul ja, bei der Nutzung von beiden Kernen, nein.
Kann er dadurch generell die 256 Bit in einem Takt abarbeiten? Nö, da es mit deutlichen Einschränkungen verbunden ist.
 
Das Bit beschreibt, was die Pipeline kann. Und das ist erst mal unabhängig davon, was AMD nun als "Kern" bezeichnet oder nicht. Ob auch das Bit in diesem Kontext betrachtet werden kann/soll/muss, ist ein weiterer spekulativer Aspekt. Auch das habe ich weiter vorne schon angesprochen.
 
Und kann die Pipeline pro Kern (der FX8 wird schließlich als 8 Kerner verkauft) 256 Bit verarbeiten?
 
Und kann die Pipeline pro Kern (der FX8 wird schließlich als 8 Kerner verkauft) 256 Bit verarbeiten?
Pro Kern ist es egal, die FPU und sein eigener Scheduler kümmern die Integer-Kerne nicht wirklich. Und nein, die Pipelines bei BD/PD/SR sind 128Bit breit, die haben nur 3 (Steamroller) bis 4 (BD/PD) davon, die jeweils etwas unterschiedlich mit Einheiten bestückt sind, die sind also nicht symmetrisch. Bei BD/PD gibt es zwei FMAC-Pipelines und zwei (größtenteils) Integer-Pipelines, aber selbst hier sind weder die FMAC-Pipelines noch die Integer-Pipelines identisch. Einige Befehle können nur in einer davon ausgeführt werden. SR mixt das ganze dann ein wenig durch (habe auch schon mal gepostet, wie genau), um mit nur 3 Pipelines zumeist den gleichen Durchsatz zu erreichen. In den Diagrammen bzw. Tabellen sieht man auch, warum bei einigen 256Bit-AVX-Befehlen die resultierenden zwei internen 128Bit µOps nicht parallel ausgeführt werden können. Einige Einheiten gibt es halt nicht doppelt.

Also egal wie man es dreht und wendet, BD/PD/SR haben 128Bit Pipelines und demzufolge wird das FP256-Flag nicht gesetzt. Und daß gruffi versucht, ein Argument daraus zu machen, daß die Namen des Flags FP128 bzw. FP256 lauten und es sich deswegen nur auf Fließkomma-SSE/AVX-Instruktionen beziehen soll und nicht auf Integer- bzw. datentyp-agnostische Instruktionen aus diesen Befehlssätzen, ist einfach nur lächerlich. Die Beschreibung nennt explizit "SSE (multimedia)" bzw. AVX-Instruktionen, was natürlich alle Instruktionsklassen umfaßt. Zudem werden alle SIMD-Instruktionen bei AMD vom FP-Scheduler gehandhabt. Diese Bezeichnung (die von AMD kommt und ja auch im Start- bzw. in dem gerade verlinkten Post in den Blockdiagrammen zu sehen ist) ist ja eine mehr oder weniger traditionelle aus den Tagen bevor die ganzen Befehlssatzerweiterungen überhand genommen haben. "Scheduler for FP and SIMD extensions instructions" ist nunmal etwas sperriger und wird deswegen auch nicht benutzt, auch wenn es vielleicht die genauere Beschreibung wäre. Aber außer gruffi weiß ja jeder, dass der FP-Scheduler und die nachgeschalteten Ausführungspipelines nicht nur für reine FP-Instruktionen sondern auch für alle SIMD-Erweiterungen zuständig sind, die deswegen auch hierunter subsummiert werden. Und es ist ja schon irgendwie auffällig, daß AMD auch die Integer-Ausführungseinheiten der Pipelines in der offiziellen Dokumentation mit dem Präfix "FP" bezeichnet, wie z.B. bei "FPMAL" oder "FPMMA" (MAL="multimedia ALU", MMA="multimedia multiplier ALU"). ;)
 
Zuletzt bearbeitet:
Und kann die Pipeline pro Kern (der FX8 wird schließlich als 8 Kerner verkauft) 256 Bit verarbeiten?
Ich kann nur nochmal wiederholen, was ich oben schon sagte.
Das Bit beschreibt, was die Pipeline kann. Und das ist erst mal unabhängig davon, was AMD nun als "Kern" bezeichnet oder nicht.
Was AMD als "Kern" bezeichnet, ist eher eine logische und weniger eine physische Geschichte aus Sicht der FPU. Die FPU kann in jedem Takt jedenfalls nur Ops von ein und demselben Thread erhalten, kann aber Ops unabhängig vom Thread gleichzeitig ausführen. Die FPU ist sozusagen ein Mix aus Round-Robin (Frontend) und SMT (Execution).


Es hilft Gipsel auch nicht, sich immer lächerlicher zu machen, indem er ständig persönlich werden musst. Das sagt eigentlich alles über den Inhalt seiner Beiträge, substanzlos und unnütz. Er sagst uns jedenfalls nichts, was wir nicht eh schon wussten. Bulldozer kann 256-bit in einem Takt. Wie das intern organisiert wird, und wie viele Ops dafür notwendig sind, kann, muss aber nicht interessieren. Jaguar kann 256-bit jedenfalls nicht in einem Takt. Das ist Fakt. Der Rest ist und bleibt Spekulation.

Und alles so zurechtbiegen, wie man es gerne hätte, ändert daran auch nichts. FP ist und bleibt FP. Und jeder ausser Gipsel weiss auch, was FP heisst. Integer und scalar Ops sind deshalb erst mal belanglos. Scalar zB braucht nun mal überhaupt nicht die volle Breite der Pipeline. Also ist es auch unsinnig, diesbezüglich über die CPUID Bits zu diskutieren. Ähnliches gilt für Integer, die andere Ausführungseinheiten nutzen als FP Ops. Ausserdem würde ein solches CPUID Bit unnütz sein, wenn man eh alles mit Durchsatz 1 kann. Es muss also für andere Fälle gedacht sein, eben für FP. Deshalb auch FP128 bzw FP256. Also auch logisch machen Gipsels Einwände nicht viel Sinn.
 
[Moderatormodus an]

Meint Ihr nicht, dass es langsam reicht? Ich denke, hier wurden alle Argumente ausgetauscht.

Zudem bitte ich Euch von weiteren persönlichen Sticheleien abzusehen.


Vielen Dank

[Moderatormodus aus]
 
Zurück
Oben Unten