App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
News AMD in Zukunft mit 256-Bit-FPU-Pipelines
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
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.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?
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.
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:Waren die aktuellen BDs einfach zu früh dran und haben "Pech gehabt"?
Bulldozer: 256-bit AVX, 1 Takt
Jaguar: 256-bit AVX, >1 Takt
Das ist nicht die Logik hinter dem Bit. Die Logik beim FP128 Bit war:Einmal 128bit = 0 und einmal = 1 ist ne Änderung der Logik.
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.
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.
Opteron
Redaktion
☆☆☆☆☆☆
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.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.
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.
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?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.
Ja aber beide haben das FP256bit auf 0. Das macht keinen Sinn. Eben weil BD = 1 Takt und Jaguar 2 Takte.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
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.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
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.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".
Logisch und sinnvoll ist es nur für den Fall, wenn BDv4 / v5 ne 256Bit FPU bekommen.
Edit: Gipsel war schneller.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Erst werden Befehle nicht aufgeteilt und jetzt doch? Ja wie denn nun?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.
Wo sind deine Neuigkeiten? Du kommst reichlich spät. Die ganze Diskussion hatten wir schon.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.
Was bei SSE natürlich nicht der Fall wäre.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.
TLYSRF:
Gipsel liegt falsch.
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.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.
Die schalten dort doch auch nur zwei 128-bit Einheiten zusammen.Wieso man das macht? Frag am besten Intel, die machen das seit SandyB eben genau so.
Schon klar. Die Logik hinter diesen Bits ändert sich deshalb ja nicht. Ich wollte nur nochmal klarstellen, wie sie ursprünglich entstanden sind.Mißverständnis, ich meinte damit das FP256 bit, nicht das 128er.
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.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.
Zuletzt bearbeitet:
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.Erst werden Befehle nicht aufgeteilt und jetzt doch? Ja wie denn nun?
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.
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.Wo sind deine Neuigkeiten? Du kommst reichlich spät. Die ganze Diskussion hatten wir schon.
Da wäre das natürlich auch der Fall.Was bei SSE natürlich nicht der Fall wäre.
Gerade ausgedacht?TLYSRF
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.
Opteron
Redaktion
☆☆☆☆☆☆
Nö, wie kommst Du darauf?Die schalten dort doch auch nur zwei 128-bit Einheiten zusammen.
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:
http://www.realworldtech.com/sandy-bridge/6/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 uop – in contrast to AMD’s more cautious embrace of AVX, which will crack 256-bit instructions into two 128-bit operations on Bulldozer.
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.
Verantwortlich oder nicht, Du hast selbst gesagt, dass man versucht "Konsistent" zu bleiben und nun verwässerst Du Deine eigene Argumentation von gestern.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.
Inkonsistent ist inkonsistent, "halb inkonsistent" oder ein "bisschen konsistent" gibts nicht.
Oho-Oho ... na da lehnst Du Dich aber gewaltig aus dem Fenster.Diese "Inkonsistenz" ist mMn an der Stelle einfach vernachlässigbar.
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.
Lol, ja der Durchsatz ist bei Dir der gleiche und das Bit ist trotzdem verschieden, sehr sinnvoll das Ganze.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.
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:
.. die Wahrscheinlichere.Man versucht konsistent zu bleiben.
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.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
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.Wohlgemerkt nur die Datenleitungen nicht die Exec-Units
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.Verantwortlich oder nicht, Du hast selbst gesagt, dass man versucht "Konsistent" zu bleiben
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.Wenn Dus ignorieren willst, dann musst Du den Fall mit ner Extra-Abfrage der CPU Family/Model abfangen.
Wenn der theoretische Durchsatz gleich ist, spielt das Bit keine Rolle. Ob Sinn oder Unsinn ist dann irrelevant.ja der Durchsatz ist bei Dir der gleiche und das Bit ist trotzdem verschieden
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.Kurz: Du lieferst keine Erklärung des FP256 Bits.
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.Nichts für ungut, aber da halte ich mein Argumentation für deutlich schlüssiger, denn die ist im Gegensatz zu Deiner konsistent
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.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.
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.Zukünftige BD-Derivate (also z.B. Excavator oder wann das auch kommt) werden 256bit breite SIMD-Einheiten verbaut haben
Scheinbar verstehst du nicht mal Sarkasmus.Da wäre das natürlich auch der Fall.
Wenn du trollst, darf ich das auch.Gerade ausgedacht?
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.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 dann schauen wir doch mal in Deinen ersten Beitrag hier:Doch, das habe ich bereits im ersten Beitrag getan. Wenn du es nicht verstehst oder verstehen willst, kann ich dir leider auch nicht weiterhelfen.
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).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.
Da steht auch nichts von 256-bit Operationen. Wie gesagt, am Ende wird eh alles auf FP32 und FP64 Operationen heruntergebrochen.
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?Scheinbar verstehst du nicht mal Sarkasmus.
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.Wenn du trollst, darf ich das auch.
Na mal sehen, ob das jetzt ankommt. Das nächste Mal darf Opteron dann wieder antworten.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
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:Na dann schauen wir doch mal in Deinen ersten Beitrag hier:
Das ist schlicht falsch.
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.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.
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.Das ist nämlich genauso Blödsinn wie die SSE-Bemerkung.
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.Google mal, wann, wie und warum man TLDR benutzt. Mein Gebrauch war vollkommen korrekt.
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:
Opteron
Redaktion
☆☆☆☆☆☆
Ne, ich bin doch rausNa mal sehen, ob das jetzt ankommt. Das nächste Mal darf Opteron dann wieder antworten.
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.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
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.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.
Insofern ist deine sture Haltung ziemlich intolerant und völlig überflüssig. Naja, zumindest hast du deine Nullaussagen eingesehen. Wenigstens etwas.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.
Es ist vielleicht für Dich nicht relevant, aber es ist entscheidend für das Flag, um welches sich dieser Thread dreht.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:
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.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.
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.
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.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.
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
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.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
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.
Markus Everson
Grand Admiral Special
Das muß man nicht unbedingt ausprobieren, falls man den Optimierungs-Guides von AMD vertraut .
Schön zu sehen, das Du Deinen Humor noch nicht verloren hast.
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!
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:
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
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.Es ist vielleicht für Dich nicht relevant, aber es ist entscheidend für das Flag, um welches sich dieser Thread dreht.
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?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).
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 na klar ändert sich mit 256Bit Pipelines gleicher Anzahl was am Durchsatz, der verdoppelt sich dann nämlich mit AVX256-Instruktionen
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.
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.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.
Übrigens, die Bits ab 80000000h sind sowieso herstellerspezifisch. Ich würde da keine Konsistenz erwarten.
sompe
Grand Admiral Special
- Mitglied seit
- 09.02.2009
- Beiträge
- 14.279
- Renomée
- 1.961
- Mein Laptop
- Dell G5 15 SE 5505 Eclipse Black
- Prozessor
- AMD Ryzen 9 3950X
- Mainboard
- MSI MPG X570 GAMING PRO CARBON WIFI
- Kühlung
- Wasserkühlung
- Speicher
- 4x 16 GB G.Skill Trident Z RGB, DDR4-3200, CL14
- Grafikprozessor
- AMD Radeon RX 6900 XT
- Display
- 1x 32" LG 32UD89-W + 1x 24" Dell Ultrasharp 2405FPW
- SSD
- Samsung SSD 980 PRO 1TB, Crucial MX500 500GB, Intel 600p 512GB, Intel 600p 1TB
- HDD
- Western Digital WD Red 2 & 3TB
- Optisches Laufwerk
- LG GGC-H20L
- Soundkarte
- onboard
- Gehäuse
- Thermaltake Armor
- Netzteil
- be quiet! Dark Power Pro 11 1000W
- Betriebssystem
- Windows 10 Professional, Windows 7 Professional 64 Bit, Ubuntu 20.04 LTS
- Webbrowser
- Firefox
Und hier ist die Antwort ganz einfach.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.
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.
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
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.
sompe
Grand Admiral Special
- Mitglied seit
- 09.02.2009
- Beiträge
- 14.279
- Renomée
- 1.961
- Mein Laptop
- Dell G5 15 SE 5505 Eclipse Black
- Prozessor
- AMD Ryzen 9 3950X
- Mainboard
- MSI MPG X570 GAMING PRO CARBON WIFI
- Kühlung
- Wasserkühlung
- Speicher
- 4x 16 GB G.Skill Trident Z RGB, DDR4-3200, CL14
- Grafikprozessor
- AMD Radeon RX 6900 XT
- Display
- 1x 32" LG 32UD89-W + 1x 24" Dell Ultrasharp 2405FPW
- SSD
- Samsung SSD 980 PRO 1TB, Crucial MX500 500GB, Intel 600p 512GB, Intel 600p 1TB
- HDD
- Western Digital WD Red 2 & 3TB
- Optisches Laufwerk
- LG GGC-H20L
- Soundkarte
- onboard
- Gehäuse
- Thermaltake Armor
- Netzteil
- be quiet! Dark Power Pro 11 1000W
- Betriebssystem
- Windows 10 Professional, Windows 7 Professional 64 Bit, Ubuntu 20.04 LTS
- Webbrowser
- Firefox
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.Und kann die Pipeline pro Kern (der FX8 wird schließlich als 8 Kerner verkauft) 256 Bit verarbeiten?
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:
gruffi
Grand Admiral Special
- Mitglied seit
- 08.03.2008
- Beiträge
- 5.393
- Renomée
- 65
- Standort
- vorhanden
- Prozessor
- AMD Ryzen 5 1600
- Mainboard
- MSI B350M PRO-VDH
- Kühlung
- Wraith Spire
- Speicher
- 2x 8 GB DDR4-2400 CL16
- Grafikprozessor
- XFX Radeon R7 260X
- Display
- LG W2361
- SSD
- Crucial CT250BX100SSD1
- HDD
- Toshiba DT01ACA200
- Optisches Laufwerk
- LG Blu-Ray-Brenner BH16NS40
- Soundkarte
- Realtek HD Audio
- Gehäuse
- Sharkoon MA-I1000
- Netzteil
- be quiet! Pure Power 9 350W
- Betriebssystem
- Windows 10 Professional 64-bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- https://valid.x86.fr/mb4f0j
Ich kann nur nochmal wiederholen, was ich oben schon sagte.Und kann die Pipeline pro Kern (der FX8 wird schließlich als 8 Kerner verkauft) 256 Bit verarbeiten?
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).Das Bit beschreibt, was die Pipeline kann. Und das ist erst mal unabhängig davon, was AMD nun als "Kern" bezeichnet oder nicht.
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.
Dr@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
[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]
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]
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 2K
- Antworten
- 0
- Aufrufe
- 916
- Antworten
- 0
- Aufrufe
- 1K
- Antworten
- 1
- Aufrufe
- 1K