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

Opteron

Redaktion
☆☆☆☆☆☆
Mitglied seit
13.08.2002
Beiträge
23.645
Renomée
2.254
  • SIMAP Race
  • Spinhenge ESL
  • BOINC Pentathlon 2012
<div class="newsfloatleft"><a href="http://www.planet3dnow.de/vbulletin/link"><img src="http://www.planet3dnow.de/photoplog/images/54308/1_AMD-Logo.png" border="0"></a></div>AMD hat einen neuen CPUID-Programmierleitfaden auf Ihrer Webseite hochgeladen. Im Vergleich zu der alten Version mit der Nummer <a href="http://support.amd.com/us/Embedded_TechDocs/25481.pdf" target="b">25481</a> sind die CPUID-Informationen, die über die Fähigkeiten eines Prozessors Auskunft geben, ab sofort im Anhang E des 3. Bandes des AMD64-Architektur-Programmierleitfadens mit der <a href="http://support.amd.com/us/Processor_TechDocs/24594_APM_v3.pdf" target="b">Nummer 24954</a> zu finden.<p style="clear:left;"></p>

Dort gibt es nun eine kleine Änderung. Im Vergleich zur alten Version:

<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=24315&w=o">
Alter CPUID-Eintrag</center>

Ist in der neuen Version auch die Rede von "FP256":

<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=24314&w=o">
Neuer CPUID-Eintrag</center>

Dabei würden AVX-Instruktionen mit 256-Bit-Breite intern mit voller Breite verarbeitet und nicht in zwei Portionen zu je 128 Bit aufgeteilt, wie es aktuell der Fall ist.

Bereits 2011 tauchte eine 256-Bit-FPU-Einheit in einer Präsentation von AMDs damaligen Chef-Technologen (CTO) Chuck Moore auf, jedoch war dies nur in eine Studie für eine hypothetische APU-Architektur im Jahre 2018:

<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=24313&w=o">
CPU-Teil einer APU-Studie aus dem Jahr 2011</center>

Mit der Erwähnung im CPUID-Register wird dieses FPU-Design konkreter. Aus Erfahrungswerten kann man Befehle, die in den CPUID-Spezifikationen erwähnt werden, frühestens 2 Jahren später erwarten.

<b>Spekulationen</b>

Vermutlich ist das für die Excavator-Architektur, welche vor längerem für 2014 angekündigt war, zu spät. Allerdings gab es seit dieser Zeitangabe einige Verspätungen bei AMDs Produkteinführung, sodass sich Excavator mit einer gewissen Wahrscheinlichkeit auch auf 2015 verschoben haben könnte.

Genaueres muss man wie immer abwarten.

<b>Quellen:</b><ul><li><a href="http://support.amd.com/us/Embedded_TechDocs/25481.pdf" target="b">CPUID Specification (veraltet)</a></li><li><a href="http://support.amd.com/us/Processor_TechDocs/24594_APM_v3.pdf" target="b">AMD64 Architecture Programmer’s Manual Volume 3: General-Purpose and System Instructions (v3.20/May 2013)</a></li><li><a href="http://www.lanl.gov/orgs/hpc/salishan/salishan2011/3moore.pdf" target="b">DATA PROCESSING IN EXASCALE-CLASS COMPUTER SYSTEMS</a></li></ul>
 
Man müßte daraus doch ableiten können, daß die FPU auch doppelt so breit wird wie jetzt, und damit (bei entsprechender Auslastung) auch doppelte Performance erreicht, oder?
 
Man müßte daraus doch ableiten können, daß die FPU auch doppelt so breit wird wie jetzt, und damit (bei entsprechender Auslastung) auch doppelte Performance erreicht, oder?
Si, claro.
Verdopplung der theoretischen Flops.

Was davon praktisch übrig bleibt ... *noahnung*
Da sollten eigentlich dann auch die L1D-Caches angepasst und auf 2x256bit verbreitert werden, damit pro Takt zwei 256er-Werte für nen FMA-Befehl durchpassen. Haswell macht das z.B. auch.

Aber müssen tut mans natürlich nicht ...
 
Bulldozer hat doch gerade 2x 128-Bit FMACs.
Bedeutet es, dass eine 256- Bit AVX-Operation in 4x 128-Bit Pakete geteilt wird, bzw. 2x 128-Bit je FMAC?
 
Bulldozer hat doch gerade 2x 128-Bit FMACs.
Ja.
Bedeutet es, dass eine 256- Bit AVX-Operation in 2x 128-Bit Pakete geteilt wird, bzw. 1x 128-Bit je FMAC?
Ja das stimmt mit Korrektur dann auch. Wie kommst Du auf 4? Das wäre bei zwei 256AVX-Befehlen der Fall. Bei 3 sind dann 6 und bei 4 dann 8 etc. pp. Nicht so wichtig.
 
Vielleicht sind dann ja mal mehr als lausige 7 Prozent FPU-Leistungsgewinn gegenüber dem Vorgänger drin...
Wie stehts bei AMD nun mit DDR4?
 
Ja.
Ja das stimmt mit Korrektur dann auch. Wie kommst Du auf 4? Das wäre bei zwei 256AVX-Befehlen der Fall. Bei 3 sind dann 6 und bei 4 dann 8 etc. pp. Nicht so wichtig.
Das war als effektiver Durchsatz zu verstehen.

Bulldozer hat ja 2x128-Bit FP-Pipelines.

Was wird also bei 2x 256-Bit AVX-Instruktionen gemacht?

Wird die erste AVX-Instruktion in 2x 128-Bit geteilt und jede 128-Bit FP-Pipeline berechnet eine Hälfte und am Ende kommt das Ergebnis und dann kommt die nächste AVX-Instruktion oder wird die AVX-Instruktion einer FP-Pipeline zugewiesen, welche dann 2 Takte für so eine braucht?
Beim ersten "Takt" wären das auf beiden FP-Pipelines nur ein 128-Bit Stück, und anschließend die andere Hälfte und 2 AVX-Instruktionen rausgespuckt.
So würde man ja das Ergebnis erst später bekommen.

War nur so eine Frage, wie ein Bulldozer das genau löst.

Sandy-Bridge hat nur eine 256-Bit FP-Pipe pro Core?
Wäre im Falle von Bulldozer doch ein Design-Vorteil für "Legacy-Code" mit 128-Bit SSE Instruktionen oder nicht?
 
Das war als effektiver Durchsatz zu verstehen.

Bulldozer hat ja 2x128-Bit FP-Pipelines.

Was wird also bei 2x 256-Bit AVX-Instruktionen gemacht?

Wird die erste AVX-Instruktion in 2x 128-Bit geteilt und jede 128-Bit FP-Pipeline berechnet eine Hälfte und am Ende kommt das Ergebnis und dann kommt die nächste AVX-Instruktion oder wird die AVX-Instruktion einer FP-Pipeline zugewiesen, welche dann 2 Takte für so eine braucht?
Beim ersten "Takt" wären das auf beiden FP-Pipelines nur ein 128-Bit Stück, und anschließend die andere Hälfte und 2 AVX-Instruktionen rausgespuckt.
So würde man ja das Ergebnis erst später bekommen.
Wenn ich mich recht erinnere, dann geht das parallel, aber nagle mich nicht fest ^^

Sandy-Bridge hat nur eine 256-Bit FP-Pipe pro Core?
Wäre im Falle von Bulldozer doch ein Design-Vorteil für "Legacy-Code" mit 128-Bit SSE Instruktionen oder nicht?
Ja, aber Intel wirbt die Werbetrommeln für AVX256 ... in Zukunft wird man das schon brauchen können. Noch gibts die CPU ja noch nicht und irgendwas muss man mit dem zusätzlichen Transistorbudget in 20 und 14nm ja machen ;-)

Die Alternative wären 4 128bit Pipes, wäre wohl komplizierter.
 
Dabei würden AVX-Instruktionen mit 256-Bit-Breite intern mit voller Breite verarbeitet und nicht in zwei Portionen zu je 128 Bit aufgeteilt, wie es aktuell der Fall ist.
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. Entweder 1x ADD, 1x MUL oder 1x FMA. Dass die Flex-FPU auch mit 128-bit arbeiten kann (SSE), ändert daran ja nichts. Das geschieht in den Rechenwerken selbst und ist transparent für Software.

Ich denke hier geht es eher um die pro Takt Verarbeitung. Vermutlich wurde dieses Bit jetzt im Zuge mit Jaguar eingeführt. Dieser hat nicht wie Bulldozer eine 256-bit fähige FPU-Pipeline, sondern ist auf 128-bit beschränkt. Hier muss dann eine 256-bit Instruktion in 128-bit aufgeteilt und in mehreren Takten verarbeitet werden. Ähnliches gab es ja schon beim Athlon-64, der lediglich eine 64-bit FPU-Pipeline hatte und 128-bit Instruktionen auch in mehreren Takten verarbeiten musste. Daher auch das Bit 0. Der Athlon-64 hatte jedenfalls keine Flex-FPU wie Bulldozer.

Diese Änderung an den CPUID Infos muss also kein Anzeichen für zukünftige 256-bit FMACs sein. Wie gesagt, vermutlich eher zurückzuführen auf Jaguar. Auch wenn die Möglichkeit für 256-bit FMACs in Excavator natürlich besteht.
 
bulldozer-fp-unit_1.jpg


Aha, also geht im Grunde beides?
 
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. Entweder 1x ADD, 1x MUL oder 1x FMA.
Intern werden die 256bit Instruktionen sehr wohl in 2 128er Stückchen zerlegt, wie sonst willst Du 256bit mittels 128bit Rechenwerken abarbeiten? Ja eine 256er Instruktion geht in einem Takt durch die zwei vorhandenen 128bit FMAC-Pipes. Aber dazu muss man sie eben in 2 Teile à 128bit zerlegen. Das passiert im Decoder. Als Beweis schaust Du einfach in das entsprechende AMD PDF, da werden alle 256er Befehle als "Doubles" gekennzeichnet, kleiner Auszug:
VADDPD_128_reg FMA[P0 | P1] FastPath Single 6
VADDPD_256_reg FMA[P0 | P1] FastPath Double 6

VADDPS_128_reg FMA[P0 | P1] FastPath Single 6
VADDPS_256_reg FMA[P0 | P1] FastPath Double 6

VADDSUBPD_128_reg FMA[P0| P1] FastPath Single 6
VADDSUBPD_256_reg FMA[P0 | P1] FastPath Double 6

VADDSUBPS_128_reg FMA[P0 | P1] FastPath Single 6
VADDSUBPS_256_reg FMA[P0 | P1] FastPath Double 6

"Doubles" bedeutet, dass pro x86-Op zwei interne MOps erzeugt werden. Da gibts also nichts zu zweifeln, das ist eindeutig.

Wenns jetzt unter FP256 heißt, dass 256bit AVX-Instruktionen mit "full-width internal operations" ausgeführt werden, dann kann das nur heißen, das die 256bit Instr. in Zukunft als Singles dekodiert werden, da sie in einem Takt in *einer* Pipeline verarbeitet werden können, eben weil selbige auf 256bit verbreitert wird.

Oder anders gesagt, pro Takt können mit einer FP256-CPU zwei 256bit MOps verarbeitet werden, nicht nur mehr eine.

@Locuza:
Ja im Moment gehen 2x128 oder 1x256. In Zukunft gehen 2x128 oder 2x256 (Edit: 1x256 natürlich auch ^^). Bei 2x128 liegt halt die Hälfte brach, aber das ist bei Intels Implementierung im Moment auch schon so. Bei Verwendung von AVX256 steigt dann auch der Stromverbrauch der Sandy/Ivys an - eben weil doppelt soviel Berechnungen laufen. So mancher übertakteter Sandy ist nicht AVX256 "stable", interessiert aber halt auch keinen, da so gut wie keine Software davon Gebrauch macht.
Nachdem AMDs CPU im SMT Betrieb mit 2 Threads läuft, sollte sich das mittelfristig schon rentieren.
 
Noch zwei Artikel:
http://www.realworldtech.com/sandy-bridge/6/

http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed/3

Was ich bisher verstanden habe, Sandy-Bridge hat auch "nur" 128-Bit FP-Pipelines die intern sich auch irgendwie zusammenfassen können und eine 256-Bit AVX-Instruktion in einem Takt durchschleusen können, ohne die Instruktion in zwei Hälften zu teilen?
Und SBs Durchsatz ist doppelt so hoch pro Core, als bei Bulldozer pro Modul, bei AVX-Code?
Und bei Bulldozer umgekehrt pro Modul doppelt so hoher 128-Bit Durchsatz im Vergleich zu einem SB-Core?

Sorry, dass ich mich da selber nicht so sehr hinein steigere, aber mein Kopf hätte gerne leichteres Futter. *buck*
 
Was ich bisher verstanden habe, Sandy-Bridge hat auch "nur" 128-Bit FP-Pipelines die intern sich auch irgendwie zusammenfassen können und eine 256-Bit AVX-Instruktion in einem Takt durchschleusen können, ohne die Instruktion in zwei Hälften zu teilen?
Jein ... die Pipelines/Rechenwerke sind 256bit. Problematisch waren nun beim Inteldesign die Leitungen zu den Rechenwerken. Die müssen auch 256bit breit sein. Da ein Intel Kern aber im Gegensatz zu AMD nicht strikt zw. INT und FP trennt (alle Einheiten hängen an einen gemeinsamen Scheduler), borgen sie sich bei 256 FP-Befehlen 128 Leitungen der INT-Rechenwerke. Die Ports der Rechenwerke, am Scheduler sind sowieso überbelegt, da hängen INT und FP gemeinsam dran. Wenn also eine FP-µOp kommt, dann kann im gleichen Takt garantiert keine INT-µOp kommen. Das nützen sie dann aus, und "misbrauchen", die INT Datenleitungen für die FP-Rechenwerke. Auch clever.

Bei AVX2 in Haswell wird das ganze dann auch im umgekehrten Fall funktionieren, dann können sich die INT-Rechenwerke die FP-Leitungen "borgen". (AVX2 ist quasi nur 256bit auch für INT-Instruktionen, AVX betraf eigentlichn nur FP-Instruktionen, deshalb brauchte man das bisher nicht).

Und SBs Durchsatz ist doppelt so hoch pro Core, als bei Bulldozer pro Modul, bei AVX-Code?
Kommt drauf an, was man da genau betrachtet. Gröbste Einheit sind da FLOPS, also alle FPU-Instruktionen, egal ob MUltiplikation, Division, Addition oder sonstwas.

Wenn Du da bei AMD FMA miteinbeziehst, ist der Durchsatz genauso hoch wie bei Intel

Eine FMA -Pipe kann 2 128bit Ops verarbeiten, also die beiden FMACs zusammen 4x128.
Ein Sandy hat eine Mul und eine Add Pipe, die aber 256bit Breit sind, also 2x256.

Unterm Strich in ner Grobbetrachtung die gleiche maximale Rechenleistung.
Die praktische hängt dann halt davon ab, welchen Code Du hast. Ohne AVX ist Intel im Nachteil, da die Pipes im 128bit-Betrieb keinen doppelten Durchsatz liefern können. Aber das ist das gleiche für AMD ohne FMA-Code ... also ist wieder Gleichstand ^^

Und bei Bulldozer umgekehrt pro Modul doppelt so hoher 128-Bit Durchsatz im Vergleich zu einem SB-Core?
Jein ... AMDs 2 Pipes können halt alles, MUL und ADD. Intel hat auch 2 Pipes, aber nur eine MUL und eine ADD. Was da schneller ist, hängt wieder vom Code ab. Wenn Du Code hast, der immer 1xMUL und 1xADD hast, dann gibts da keinen Unterschied.
Sorry, dass ich mich da selber nicht so sehr hinein steigere, aber mein Kopf hätte gerne leichteres Futter. *buck*
Passt schon ist ein interessantes Thema ^^
 
Vielen Dank Opteron, da wird einem schon einiges klarer. *greater*

FMA-Code ist aber ein spezielles Konstrukt, um MUL + ADD zusammen zu fassen richtig?
Also eine AVX-Instruktion könnte auch Teil davon sein?

Bulldozer hat keine FMA3 Unterstützung, nur Piledriver offiziell.
Also erst ab Haswell kann man ja davon ausgehen, dass FMA(3) sich langsam bewegt.

Bisher ist aber noch nicht klar, ob Steamroller AVX2 unterstützen wird oder ist das schon ausgeschlossen?
 
Ja eine 256er Instruktion geht in einem Takt durch die zwei vorhandenen 128bit FMAC-Pipes. Aber dazu muss man sie eben in 2 Teile à 128bit zerlegen.
Das macht aber nicht die Software. Das geschieht wie gesagt transparent für die Software. Wozu sollte man das also explizit in der CPUID Spezifikation erwähnen? Für die Software macht es keinen Unterschied, ob eine 256-bit Instruktion intern als 2x 128-bit oder 1x 256-bit behandelt wird. Der Durchsatz pro Takt ist der gleiche. Auf unterster Ebene ist sowieso alles 32-bit (einfache Genauigkeit) oder 64-bit (doppelte Genauigkeit). Es macht aber sehr wohl einen Unterschied, ob du eine 256-bit Instruktion in einem Takt verarbeiten kannst oder dafür mehrere Takte brauchst. Dann sind eventuell Codeanpassungen für maximale Performance notwendig.

Ich will dir deinen Artikel nicht schlecht machen. Du solltest aber vielleicht die Möglichkeit in Betracht ziehen, dass auch andere Interpretationen möglich sind. Eindeutig ist da erst mal gar nichts. ;)

Als Beweis schaust Du einfach in das entsprechende AMD PDF, da werden alle 256er Befehle als "Doubles" gekennzeichnet
Klar, ist ja auch logisch, wenn intern alles auf 128-bit abgestimmt ist. Nur, wofür soll das ein Beweis sein? Ich sehe da keinen konkreten Zusammenhang. Siehe Erklärung zuvor.


Übrigens, ich würde auch nicht zu viel in die Formulierung der CPUID Spezifikation hineininterpretieren. Man sieht ja, dass es einfach nur C&P von FP128 ist. Und damals gab es nie eine solche FPU Verarbeitung wie aktuell in Bulldozer. Warum soll also die Bedeutung des Bits plötzlich eine andere sein? Ein weiteres Indiz für mich, was gegen deine Darstellung spricht.
 
Zuletzt bearbeitet:
FMA-Code ist aber ein spezielles Konstrukt, um MUL + ADD zusammen zu fassen richtig?
Also eine AVX-Instruktion könnte auch Teil davon sein?
Jein, so würde ich es nicht sehen. Sagen wir so, ne AVX Instr. kann entweder eine Mul oder Add-Operation entahlten (oder sonstwas, z.B: AES), und ne FMA Instruktion besteht aus je einem ADD- und einer MUL-Operation.
FMA hat mit AVX nicht sooviel zu tun.

Bulldozer hat keine FMA3 Unterstützung, nur Piledriver offiziell.
Ja aber BD hat FMA4.
Also erst ab Haswell kann man ja davon ausgehen, dass FMA(3) sich langsam bewegt.
Jupp, Intel wird da groß die Werbetrommel rühren.
Bisher ist aber noch nicht klar, ob Steamroller AVX2 unterstützen wird oder ist das schon ausgeschlossen?
Ich persönlich schließe es jetzt aus, das müsste ansonsten auch schon in der aktuellen CPUID-Info stehen.
 
Ach AMD einfach nur im APM#3 gefuscht !

Da fehlt einiges, zB TCE, NodeID, BMi1 .... daher ist dies noch kein Argument - immerhin stehen TCE & Co doch in den BKDGs der AMD Family 15h Models 00h-0Fh & 10h-1Fh ;)
 
Jein, so würde ich es nicht sehen. Sagen wir so, ne AVX Instr. kann entweder eine Mul oder Add-Operation entahlten (oder sonstwas, z.B: AES), und ne FMA Instruktion besteht aus je einem ADD- und einer MUL-Operation.
FMA hat mit AVX nicht sooviel zu tun.
Dann hat AES mit AVX aber auch nicht "sooviel" zu tun. ;)

Machen wir es präziser. FMA als grundlegendes Konzept hat mit AVX natürlich erst mal nichts zu tun. FMA ist einfach das Fusionieren einer Multiplikations- und Additionsoperation. In der digitalen Datenverarbeitung bedeutet das auch, dass die Rundung dazwischen wegfällt. Also auf Gleitkommabasis sind die Ergebnisse genauer.

Die x86 FMA Instruktionen haben hingegen sehr wohl was mit AVX zu tun. Genauer gesagt sind sie Teil der ursprünglichen AVX Spezifikation von Intel (319433).
 
Das macht aber nicht die Software. Das geschieht wie gesagt transparent für die Software. Wozu sollte man das also explizit in der CPUID Spezifikation erwähnen? Für die Software macht es keinen Unterschied, ob eine 256-bit Instruktion intern als 2x 128-bit oder 1x 256-bit behandelt wird. Der Durchsatz pro Takt ist der gleiche.
Na Du bist lustig ... Software musst Du compilieren, und der Compiler braucht so etwas natürlich. Wozu brauchst Du denn ein SSE oder ein AVX Flag, die Software liefe doch auch wunderbar mit x87? Total überflüssig das Ganze *lol*

Hast Du die Story nicht mitbekommen, dass AMD empfiehlt AVX nur mit 128bit zu verwenden, wenn man jedes bisschen Performance haben will, da es ein paar Prozentchen schneller als AVX256 ist?
Edit: Das Thema hatten wir schon mal diskutiert:
Attached is the patch to force gcc to generate 128-bit avx instructions for bdver1. We found that for the current Bulldozer processors, AVX128 performs better than AVX256. For example, AVX128 is 3% faster than AVX256 on CFP2006, and 2~3% faster than AVX256 on polyhedron.
http://www.planet3dnow.de/vbulletin/showthread.php?p=4501281#post4501281

Das ist glasklar die gleiche Geschichte wie mit dem anderen Flag für SSE128. Die hatte man für den K10 eingeführt, der K8 hatte nur ne 64bit SSE-Einheiten.

Der Intelcompiler scherte sich darum natürlich nicht, der verwendete von Anfang an nur 128bit Instruktionen. Gut für den K10, schlecht für den K8.
Die Flags von AMD sind nun für AMD-Compiler-Programmierer, die das dann für Architekturoptimierungen nützen können und für sonstige Hacker die Assembler schreiben, z.B. den Freaks bei x264 ^^


Ich will dir deinen Artikel nicht schlecht machen. Du solltest aber vielleicht die Möglichkeit in Betracht ziehen, dass auch andere Interpretationen möglich sind. Eindeutig ist da erst mal gar nichts. ;)
Das ist eindeutig, Du verwechselst da nur ein paar Sachen, bzw. kannst sie nicht einordnen :)
Klar, ist ja auch logisch, wenn intern alles auf 128-bit abgestimmt ist. Nur, wofür soll das ein Beweis sein? Ich sehe da keinen konkreten Zusammenhang.
Lol, jetzt ist es logisch und ein Posting früher hattest Du noch behauptet alles wäre in 256bit. Schön, dass wir uns da so schnell einig wurden ;-)
Der Zusammenhang ist der, dass SSE128-Instruktionen früher beim K8 auch als Double decodiert wurde. Eben 2 µOps à 64bit. Rate mal, wozu das alte FP128-Bit-Flag gut war ;-)


Übrigens, ich würde auch nicht zu viel in die Formulierung der CPUID Spezifikation hineininterpretieren. Man sieht ja, dass es einfach nur C&P von FP128 ist. Und damals gab es nie eine solche FPU Verarbeitung wie aktuell in Bulldozer. Warum soll also die Bedeutung des Bits plötzlich eine andere sein? Ein weiteres Indiz für mich, was gegen deine Darstellung spricht.
Na dann warst Du damals entweder noch nicht dabei oder bist schlicht falsch informiert. Habs ja schon oben erwähnt, das war beim K8 <> K10 genau die gleiche Geschichte wie jetzt, nur mit 64 und 128 anstatt 128 und 256. Das Indiz spricht also für meine Interpretation, nicht für Deine.

Fühle mich auch nicht angegriffen wg. Schlechtreden o.ä., Du hast nur ein Verständnisproblem aufgrund falscher oder fehlinterpretierter Infos.

Edit:
Die x86 FMA Instruktionen haben hingegen sehr wohl was mit AVX zu tun. Genauer gesagt sind sie Teil der ursprünglichen AVX Spezifikation von Intel (319433).
Ja sie stand im gleichen PDF, hat aber eigene CPUID-Flags. Ist für mich kein technischer-wichtiger Zusammenhang. Wenn Du Äpfel und Birnen in nen Topf wirfst machts das auch nicht einheitlich zu ner Äpfirne.
 
Software musst Du compilieren, und der Compiler braucht so etwas natürlich. Wozu brauchst Du denn ein SSE oder ein AVX Flag
Nochmal, wozu braucht der Compiler das? x86 Instruktion ist x86 Instruktion. Und mehr generiert der Compiler nicht. Wie diese Instruktion dann intern verarbeitet wird, interessiert an der Stelle nicht. Irgendwie habe ich das Gefühl, du stehst völlig auf dem Schlauch. Grundsätzliche ISA Erweiterungen sind auch ein ganz anderes Thema. Wir sprechen hier von denselben AVX Instruktionen. Ein "VADDPD ymm1, ymm2, ymm3/m256", um mal eines deiner Beispiele aufzugreifen, ist für den Compiler immer gleich. Er generiert dafür immer denselben Maschinencode (mit Abweichungen für Register und Speicheradressen natürlich). Wie die Instruktion dann intern verarbeitet wird, ob 1x 256-bit, 2x 128-bit, 4x 64-bit oder was auch immer, kann ihm erst mal ziemlich egal sein, sofern eben alles in einem Rutsch passiert und sich nicht über mehrere Takte hinzieht.

Hast Du die Story nicht mitbekommen, dass AMD empfiehlt AVX nur mit 128bit zu verwenden, wenn man jedes bisschen Performance haben will, da es ein paar Prozentchen schneller als AVX256 ist?
Na dann braucht man ja auch kein FP256 Bit, wenn eh alles mit 128-bit Instruktionen besser ist. Richtig? Wie kommst du darauf, dass das eine was mit dem anderen zu tun hat?

Das ist glasklar die gleiche Geschichte wie mit dem anderen Flag für SSE128. Die hatte man für den K10 eingeführt, der K8 hatte nur ne 64bit SSE-Einheiten.
Sag ich ja, dass es sehr wahrscheinlich darauf zurückzuführen ist. Nur ist das eben nicht aus dem Grunde geschehen, wie du es hier mit Bulldozer hinstellst. Der K10 hatte intern keine 2x 64-bit Verarbeitung. Um mal die Analogie zur Flex-FPU von Bulldozer zu bemühen. Du vermischst hier 2 Sachverhalte.

Lol, jetzt ist es logisch und ein Posting früher hattest Du noch behauptet alles wäre in 256bit.
Um es nochmal deutlich zu machen, ich sagte, dass die Instruktionen mit voller 256-bit Breite in einem Takt verarbeitet werden können und nicht in 128-bit aufgeteilt werden müssen, um sie in mehreren Takten zu verarbeiten. Das widerspricht doch nicht den internen Strukturen, die unverkennbar noch SSE5 entstammen.

Der Zusammenhang ist der, dass SSE128-Instruktionen früher beim K8 auch als Double decodiert wurde.
Was irrelevant ist. Der entscheidende Punkt ist, dass K8 die Instruktionen tatsächlich aufteilen musste, da nicht alles im selben Takt verarbeitet werden konnte. Für Bulldozer ist das nicht notwendig. Der kann die volle Breite in einem Takt verarbeiten. Das Aufteilen im K8 war also ein anderes als das was du als Aufteilen in Bulldozer verstehst. K8 und Jaguar sind an der Stelle deutlich ähnlicher. Insofern wäre es nur logisch, dass das FP256 Bit in CPUID für Fälle wie Jaguar geschaffen wurde, nicht für Bulldozer. Natürlich kann man auch nicht ausschliessen, dass es für beide Fälle geschaffen wurde. Auch wenn für mich nicht ersichtlich ist, welchen softwareseitigen Nutzen das im Fall von Bulldozer haben soll. An den relevanten Informationen für die Codegenerierung, wie zB Latenz oder Anzahl der Recheneinheiten, ändert auch das FP256 Bit nichts.

Habs ja schon oben erwähnt, das war beim K8 <> K10 genau die gleiche Geschichte wie jetzt
Es ist aber eben nicht die gleiche Geschichte bezogen auf Bulldozer. Es ist lediglich die gleiche Geschichte aus Sicht von CPUID. Und für mich schaut das FP256 Bit vielmehr nach Jaguar aus, so wie das auch beim K8 mit dem FP128 Bit war.


Vielleicht solltest du erst mal runterkommen und dir die Zeit nehmen, kräftig durchzuatmen. Im Moment bist du leider ziemlich aggressiv und erkenntnisresistent für andere Meinungen. Eine vernünftige Diskussion ist so jedenfalls nicht möglich. Scheinbar fühlst du dich eben doch angegriffen. Was definitiv nicht meine Absicht war. Ich wollte lediglich einen anderen Aspekt aufzeigen und dass dieses Bit noch lange keine Bestätigung für zwei 256-bit FMACs sein muss. Es kann wie gesagt auch zB zur Differenzierung der 256-bit Verarbeitung zwischen Bulldozer und Jaguar dienen.


Du verwechselst da nur ein paar Sachen, bzw. kannst sie nicht einordnen
Wollen wir nochmal rekapitulieren, wer sich mit Softwareentwicklung auskennt und wer nicht? ;) *scnr*

Ja sie stand im gleichen PDF, hat aber eigene CPUID-Flags.
Ist doch völlig belanglos für das, was ich zu FMA sagte. FMA ist Teil der AVX Spezifikation. Und nur darum ging es mir. Dass es ein extra CPUID Bit dafür gibt, liegt wohl einfach daran, dass Sandy Bridge zwar AVX unterstützt, aber nicht den vollständigen Befehlssatz. Hätte der den vollständigen AVX Befehlssatz unterstützt, also inklusive FMA, hätte man sich das FMA Bit auch sparen können. Dann reicht auch das AVX Bit völlig aus.
 
Zuletzt bearbeitet:
Der K8 hat auch kein Modul Design bei dem 2 Threads parallel verarbeitet werden könnten, wodurch der K8 für die 128 Bit Code 2 Takte benötigt wärend das Bulli Modul beide 128 Bit Teile parallel verarbeiten kann, wodurch der 256 Bit Code in einem Takt durch rutscht.
 
Zurück
Oben Unten