Kaveri - der Trinity Nachfolger

[FredD]

Weiß jemand zufällig, was es mit Design-Team von Kaveri auf sich hat?

Wird das ein Wurf aus dem AMD Engineering Centre Bangalore?

 

[Opteron]

Weiß jemand zufällig, was es mit Design-Team von Kaveri auf sich hat?

Wird das ein Wurf aus dem AMD Engineering Centre Bangalore?

Die Kaveri (Kannada: xxxxxx, Tamil: xxxxx; früher auch anglisiert Cauvery, seltener Kavery) ist ein Fluss im Süden Indiens.

Noch Fragen?

 

[FredD]

Konkrete info bitte, soweit vorhanden. Lexikon Auszug hab ich schon in Post 1.

 

[Opteron]

Konkrete info bitte, soweit vorhanden. Lexikon Auszug hab ich schon in Post 1.

Achso, DU willst 100% sichere Info? Na die gibts doch nie, AMD legt offiziell nicht mal offen, wieviel Entwicklerteams sie wo haben.

 

[Opteron]

Antwort aus der Diskussion im TrinityThread über Kaveris eventuell abgeschwächten CMT-Ansatz:

Das mit dem loop buffer würde aber auh ohne aufgetrennte decoder gehen und den Druck vom Frontend nehmen.

Da gehts schon los, wie hättest Du es gerne, einen loop buffer für 2 Kerne oder nur einen loop buffer für beide?
Wohl klar, dass das 2 getrennte sein müßten, aber wie gut die dann laufen, wenn sie nur jeden 2ten Takt was von nem gemeinsamen Decoder bekämen ...

spMT würde den singlethread-Fall ordentlich beschleunigen, was trotz aufgetrennten decodern mit der aktuellen Fassung nicht geht.

Tja, solange wir nicht wissen was "ordentlich" ist ...
Wie der Name schon sagt ist das Ganze "spekulativ", wenn schief läuft war die Ganze Sache für den A****. viel Stromverbrauch für nix, dazu noch der Logikaufwand/Flächenverbrauch. Dann lieber 2 getrennte Threads mit 2er Durchsatz, als einer mit 1,5 und höherem Stromverbrauch. Zumindest aus Serversicht, als Desktopuser würde man sicherlich über den zweiten Fall froh sein, aber das interessiert AMD augenscheinlich ja nicht mehr, siehe BD-Design

Intel mag nah an die 2 rankommen, muss dafür aber auch einigen Aufwand betreiben.

Ja, aber SpMT wär dagegen deutlich aufwändiger. Über den Stromverbrauch beschwert sich bei Intel ja auch keiner.

CMT mit scout-threads würde ermöglichen dass man im Singlethread-Fall immerhin 4 ALUs zur verfügung hat anstatt nur 2 und bei Vollauslastung mit einigen Tricks (wie der loop-buffer z.b.) immerhin 1 dedizierte ALUs pro thread.

Also wenn Du jetzt speziell von Scouts redest, dann steigt der Durchsatz nicht auf 4. Scouts kundschaften den Code nur aus, und "wärmen" den Cache auf. Rechnen tuen sie nix. Dafür brauchts dann SpMT, das rechnet noch spekulativ, aber wie gut das halt ist, ist die Frage, im Zweifelsfall siehe oben.

Das Auftrennen des decoders separiert das Design wieder zu einem herkömmlichen Multicore der sich "nur" die FPU mit seinem bruder teilt.

Ist doch wurst, Hauptsache schneller ...

Wenn ich mir die Dieshots angucke ist die FPU immernoch vergleichssweise klein wenn man das Frontend danebenlegt. Und die getrennte FPU in dem Fall ja eher hinderlich weil man sonst genauso wie Intel verfahren könnte. Also irgendwie nix halbes und nix ganzes.

HMm reden wir jetzt vom Front-End oder über den Decoder, als Teil des Front-Ends. c't hat nur gesagt, dass die Decoder gesplittet werden, vom Rest haben die nichts gesagt. Aus dem Flächenverbrauch, den Du auch richtig einschätzt, hoffe ich, dass die Vorhersagelogik, die den Hauptteil des Front-Ends ausmachen weiterhin gemeinsam benutzt werden kann. Notfalls per DDR, das muss sich doch irgendwie hintrixen lassen

Man kann den 2. INT-Kern nicht zur beschleunigung eines einzelnen threads nutzen, genausowenig kann man die Datenleitungen recyceln wie Intel das macht. Man hat also mehr oder weniger den CMT-Vorteil ad acta gelegt... und das wofür? - weil man nicht in der Lage ist einen vernünftigen decoder vorne dranzubauen?

Das Hauptproblem sind wohl die beiden Threads. Die muss man irgendwie da durchschleußen, AMD hat sich jetzt fürs vertikale MT entschieden, de-facto läuft der Decoder pro Kern also grob-gesehen mit halben Takt. Wenn Du jetzt aufs Doppelte verbreiterst hilft das aber auch nichts, da man pro Thread kaum 8 Decoder auslasten kann

Wenn ich mir das so ansehe und mit der Liste von Agner Fog vergleiche... sollten sie doch in Gottes namen erst die anderen Punkte angehen und den Decoder noch etwas verbreitern, abgefedert durch loop cache und fertig. Aber das alles wieder zu separieren was man mühselig zusammengefasst hat... naja...

Das Problem sind doch auch die µCode-Befehle. Bisher gibts nur einen µCode-Dec., wenn der arbeitet, ist alles blockiert.
Ich verstehe Deine Argumente, aber die bei AMD sind sicherlich nicht blöd, die haben seit Anfang 2011 BDs im Lab und kennen Agners Schwachstellenliste sicherlich etwas länger. Genausogut konnten sie sicherlich auch diverse Optionen durchsimulieren. Ich bin sicher, dass sie nicht die Schlechteste für Steamroller genommen haben ^^

Ja, deswegen ist aber eine hohe pro Kern Leistung immer noch wichtig. Man muss deswegen ja nicht zu Single-Cores zurückkehren, aber doch auf eine möglichst hohe Performance pro Kern bedacht sein.

Ja, wichtig schon, aber Performance/Watt und Die-Flächenverbrauch ist eben wichtiger. Der Rest sollte laut Plan ja aus dem Takt kommen. Steamroller sollte da eigentlich langsam hinkommen, wo AMD hinwill. Schon mit Piledriver steigt IPC und Takt etwas, dann noch nen schönen Schub bei beidem für Steamroller, dann wär ich zufrieden. Gut, Intel hat dann Haswell, aber wenn sie die Steamroller-FPU auch verbreitern/verbessern (immerhin wissen wir ja schon von der DIV-Einheit), wird das dann doch ne runde Sache. Intel wird weiter besser sein, aber nicht mehr so stark. (hoffentlich ^^).

Und dafür müssen 2 getrennte Decoder her? Sehe ich nicht so. Ein breiterer oder flexiblerer Decoder erhöht doch den Durchsatz genauso. Ich kann Ge0rgy nur zustimmen, getrennte Decoder führen das CMT Design nur ad.absurdum. Ich würde es viel lieber sehen, dass man aus den beiden Integer Clustern einen macht.

Siehe oben, was interessiert mich CMT, das ist so wichtig wie die Gehäusefarbe rosa bei nem Notebook. Schön anzuschauen, aber wenn der schwarze Rechner mehr Wumms bei gleichen Kosten & Stromverbrauch hat, ist mir das egal.

Mehr als 2 geht nicht? Dir ist aber schon klar, dass das theoretische Maximum bei 4 liegt?

Und dir ist anscheinend entgangen, dass ich von INT-Cores redete Oder willst Du die 2 Instruktionen LEA & INC/DEC mitzählen ... ? Das läuft bei mir unter Meßfehler.

Das ist nicht ganz korrekt.

Ich schrieb:

Aktuell bekommt AMD nur eine 256b AVX Instruktion pro Takt durch die FPU, da steht Intel besser da.

Und das ist korrekt, und zwar ganz
Ich schrieb nicht umsonst AVX, und nicht AVX+FMA+XOP

Erstmal sind Instruktionen eher nebensächlich, entscheidend sind die Rechenoperationen, die in der Instruktion verpackt sind. Intel kann momentan maximal 2 256-bit Rechenoperationen pro Takt, Bulldozer hingegen 4 256-bit Rechenoperationen, also doppelt so viele.

4 256bit Operationen? Also auch mit FMA und XOP geht das nicht, wir redeten doch gerade nur von der FPU, oder? Da kriegst Du keine 4 durch. Mit FMA bekommst Du zwei durch die beiden 128b FMACs, nicht vier, und die IMACs sind nur 128bittig. Wenn Du die noch dazurechnen willst (ist ja eh irgendwie komisch INT Units in der FPU), dann kommen wir max. auf 2x256 plus 2x128.

Allerdings ist für Bulldozer FMA notwendig. Zudem teilen sich hier die Rechenoperationen in jeweils 2 Integer und FP. Integer wird mWn momentan auch nur durch XOP unterstützt. Bei Intel geht das halt nicht, da deren Rechenwerke nur 128-bittig sind, und für 256-bit FP Rechenoperationen die Integer Rechenwerke "missbraucht" werden. Nicht besonders elegant, aber besser als nichts als Übergangslösung.

Ich finds praktisch, 256b for free. Das kostet keine extra Leitungen und die INT-Pfade würden durch die Port-Begrenzung eh brach liegen. Einziger Nachteil ist der Strafzuschlag beim Moduswechsel SSE <> AVX. Das kostet bei Intel, bei AMD ists umsonst. Damit kommt die AMD Lösung faulen Programmierern näher. Die können einfach mal schnell ein paar brauchbare AVX/FMA-Befehle in den alten SSE-Code mischen, und sich übers Speedup freuen.

 

[gruffi]

Siehe oben, was interessiert mich CMT, das ist so wichtig wie die Gehäusefarbe rosa bei nem Notebook. Schön anzuschauen, aber wenn der schwarze Rechner mehr Wumms bei gleichen Kosten & Stromverbrauch hat, ist mir das egal.

Hat er aber nicht. CMT verbessert ja Flächen- und Energieeffizienz. Bei gleichen Kosten und gleicher Leistungsaufnahme kann der "schwarze Rechner" also nicht mehr Wumms haben.

Und dir ist anscheinend entgangen, dass ich von INT-Cores redete Oder willst Du die 2 Instruktionen LEA & INC/DEC mitzählen ... ? Das läuft bei mir unter Meßfehler.

Das ist erstmal nebensächlich. Die theoretisch maximale IPC liegt trotzdem bei 4.

Und das ist korrekt, und zwar ganz

Na offensichtlich nicht, siehe nachfolgend.

4 256bit Operationen? Also auch mit FMA und XOP geht das nicht

Ok, sind vermutlich doch nur 3. Ich zitiere mal den SOG:

There are four logical pipes: two FMAC and two packed integer. For example, two 128-bit
FMAC and two 128-bit integer ALU ops can be issued and executed per cycle.

Ich bin davon ausgegangen, dass jeweils ein IMAC an den Integer Ports hängt. Ist aber doch nur an Port 0 einer. Wie auch immer, es sind 2x 128-bit FMA + 2x 128-bit SIMD. Macht also insgesamt bis zu 3 256-bit Operationen. Rein von den Kapazitäten steht AMD also erstmal besser da, und nicht wie von dir behauptet Intel.

Ich finds praktisch, 256b for free. Das kostet keine extra Leitungen und die INT-Pfade würden durch die Port-Begrenzung eh brach liegen. Einziger Nachteil ist der Strafzuschlag beim Moduswechsel SSE <> AVX. Das kostet bei Intel, bei AMD ists umsonst. Damit kommt die AMD Lösung faulen Programmierern näher. Die können einfach mal schnell ein paar brauchbare AVX/FMA-Befehle in den alten SSE-Code mischen, und sich übers Speedup freuen.

Also ich finde es nicht praktisch. Für mich ist es nur eine Notlösung. Damit baust du dir nur unnötig Wartezyklen an Ports ein, die ansonsten anderweitig genutzt werden könnten. Was anderes war aber vermutlich auf die Schnelle nicht machbar, um SB AVX zu spendieren. Wenn es so toll sein soll, dann frage dich doch mal, warum man das nicht schon mit SSE gemacht hat. Also die FPU auf 64-bit belassen und die anderen 64-bit von den Integer Rechenwerken abzweigen. Ich rechne damit, dass mit Haswell diese Notlösung wieder rausfliegt und dieser eine "echte" 256-bit FPU mitbringt.

 

[Duplex]

Hat er aber nicht. CMT verbessert ja Flächen- und Energieeffizienz. Bei gleichen Kosten und gleicher Leistungsaufnahme kann der "schwarze Rechner" also nicht mehr Wumms haben.

Im Vergleich zu Deneb gibt es keine x86 pro Takt mehr Leistung oder Effizienz Verbesserungen. / 45 > 32nm Vorteil.

AMDs größte Probleme bei Bulldozer sind aktuell

- Nur 1 FPU für 2 Threads
- Nur 1 Decoder für 2 Threads
- 16KB L1D Cache
- Allgemein langsame Cache Latenzen durch das Wright Trough Cache Design

Steamroller braucht

- 1 FPU pro Thread
- 1 Decoder pro Thread
- 32KB L1D Cache
- Schnellere Cache Latenzen

@gruffi
2x Cluster aus dem CMT Konzept > 1x Breites Cluster erstellen macht das Design aber deutlich breiter, ich glaube sowas ähnliches hat man bei einem stonierten K9 mal geplant, den Core Bereich vom K8 massiv breiter gestallten.

 

[Ge0rgy]

@Opteron
Es geht mir nicht um CMT als solches, der Punkt ist aber, wenn sich die decoder so mal eben auftrennen lassen und die Schwachstellen die Agner Fog in seinem Dokument angibt schon länger bekannt sind & simuliert, warum hat man BD dann überhaupt so gebracht und das mit den aufgrtrennten decodern nicht von Hause aus eingebaut.
Das Problem mit der Bandbreite existiert auch nur wenn beide threads vollast anliegen haben, BD schafft aber IPC von 2 nichtmal im Singlethread.Fall. Daher ist das Decoderproblem nur sekundär.
Dazu kommt, dass es im Programmablauf recht häufig schleifen gibt. Aktuell müssen die instruktionen in jedem schleifendurchlauf wieder und wieder durch die "langsamen" decoder. Ein Loop cache, wie der name schon sagt, verschafft dem Frontend hier luft, weil die schleife aus dem cache laufen kann und die decoder inzwischen schonmal weiterdecodieren können.
Daher würde ich eine verbreiterung und verbesserung des µCode-Verhaltens in Verbindung mit loop cache für besser halten.
Wenn man die CMT Vorteile ohnehin ad acta legt, hätte man sich den Aufwand ersparen können und gleich weder normale multicores bauen.
Aber wer bin ich schon...
Die von AMD werden sicher wissen was sie tun...
Intel sagt nicht umsonst, die Cachepipeline ist ebenso wichtig wie die Rechenpipeline selbst.
bezüglich der scout threads... nunja... in Zeiten wo die Sprungvorhersagen über 90% trefferquoten liefern können, würde ich mal fast denken sollte es auch möglich sein die wahrscheinlichkeit dass spMT richtig liegt halbwegs hoch zu bekommen...
.
EDIT :
.

Im Vergleich zu Deneb gibt es keine x86 pro Takt mehr Leistung oder Effizienz Verbesserungen. / 45 > 32nm Vorteil.

AMDs größte Probleme bei Bulldozer sind aktuell

- Nur 1 FPU für 2 Threads
- Nur 1 Decoder für 2 Threads
- 16KB L1D Cache
- Allgemein langsame Cache Latenzen durch das Wright Trough Cache Design

Bei Write through und Decodern sag ich nichts, aber der rest ist quatsch.
mehr als 16Kb L1D$ hat ein Sandybridge pro thread auch nicht wenn SMT zum Einsatz kommt.
Die FPU schlägt sich bestenfalls in Benchmarks nieder, im realen Leben ist der Anteil an FPU-Code, der dazu auch noch vollast verursacht vergleichsweise gering.
Und wir dürfen nicht vergessen, BD hat insgesamt 4 ALUs, Deneb nur 3.
Es stehen also absolut gesehen mehr ressourcen zur Verfügung, nur kann man die a) nicht alle für 1 Thread nutzen und b) bestehen durch das cachedesign und alle anderen von Agner Fog beschrieben Probleme (z.b. das mit den Zugriffen auf die Cachelines) noch genug Schlaglöcher.
Wenn AMD es schaffen würde die Int-Cores im Mittel so gut auszulasten dass sie ansatzweise eine IPC von 2 erreichen, dann würde ich sagen können AMD muss das Design verbreitern um sich weiter zu verbessern, aber wenn man nichtmal 2-fach OoO ausgelastet kriegt, hat man ganz andere Probleme...
.
EDIT :
.

Im Vergleich zu Deneb gibt es keine x86 pro Takt mehr Leistung oder Effizienz Verbesserungen. / 45 > 32nm Vorteil.

AMDs größte Probleme bei Bulldozer sind aktuell

- Nur 1 FPU für 2 Threads
- Nur 1 Decoder für 2 Threads
- 16KB L1D Cache
- Allgemein langsame Cache Latenzen durch das Wright Trough Cache Design

Steamroller braucht

- 1 FPU pro Thread
- 1 Decoder pro Thread
- 32KB L1D Cache
- Schnellere Cache Latenzen

@gruffi
2x Cluster aus dem CMT Konzept > 1x Breites Cluster erstellen macht das Design aber deutlich breiter, ich glaube sowas ähnliches hat man bei einem stonierten K9 mal geplant, den Core Bereich vom K8 massiv breiter gestallten.

Das wäre auch eine Rückkehr zum klassischen Kern, und eine Absage an die Clusterstruktur als Solche.
Aber K8 hatte seine Probleme nicht bei der Breite des inneren Kerns... sondern ironischerweise ebenfalls beim Frontend.

 

[FredD]

Interessante Diskussion. Die veröffentlichten AMD Marketing-Bildchen lassen miich jedoch nicht so recht an eine Abkehr vom CMT-Ansatz glauben.

 

[gruffi]

Im Vergleich zu Deneb gibt es keine x86 pro Takt mehr Leistung oder Effizienz Verbesserungen. / 45 > 32nm Vorteil.

Ich habe auch nicht von Deneb gesprochen. Es ging erstmal nur um Bulldozer. Beide Kerne 1:1 zu vergleichen, ist nicht so ohne weiteres möglich. Eine Bulldozer CU ist einen Tick kleiner als zwei Husky Kerne. Und mit dem Taktvorteil der Pipeline kann Bulldozer die schlechtere Skalierung von CMT gegenüber CMP gut ausgleichen. Also selbst so gesehen hat Bulldozer keinen Nachteil. Darüber hinaus besitzt er viele Erweiterungen, die Husky nicht besitzt, wie FMA, AVX, XOP, AES, SSSE3, SSE4, etc. Und Bulldozer steht gerade mal am Anfang der Entwicklung, während Husky, ausgehend vom K7, eine über 10 Jahre lange Entwicklung hinter sich hat. Das sollte das Potenzial des CMT Designs schon recht gut verdeutlichen.

AMDs größte Probleme bei Bulldozer sind aktuell

- Nur 1 FPU für 2 Threads
- Nur 1 Decoder für 2 Threads
- 16KB L1D Cache

Denke ich nicht. Das würde ja bedeuten, dass 2 Threads auf einer CU zu langsam wären. Sind sie aber nicht. Die Skalierung mit 70-80% liegt völlig im Rahmen des angekündigten. Ich denke, wir sind uns einig, dass ein Thread zu langsam ist, nicht zwei.

2x Cluster aus dem CMT Konzept > 1x Breites Cluster erstellen macht das Design aber deutlich breiter

Wieso macht es das Design breiter? 2x 4 Pipes mit je einer ALU oder AGLU ist doch theoretisch erstmal genauso viel Transistorlogik wie 1x 8 Pipes mit je einer ALU oder AGLU. Eventuell wird Verteilerlogik (Multiplexer) etwas aufwändiger. Aber wenn Intel das mit 6 Pipes schafft, dann sollte das auch noch mit 8 Pipes machbar sein.

 

[Crashtest]

Ähm an Bulldozer wird seit 2007 gebastelt ! Allein die SSE5 Entwicklung und der spätere Wandel zu XOP, AVX, FMA4 etc hat einige Zeit benötigt !

Manche Sachen kann Bulldozer auch wenns erst einmal "inaktiv ist", etwa
- FMA3
- CVT16 bzw. F16C
- einige Dinge von BMI

 

[Opteron]

Hat er aber nicht. CMT verbessert ja Flächen- und Energieeffizienz. Bei gleichen Kosten und gleicher Leistungsaufnahme kann der "schwarze Rechner" also nicht mehr Wumms haben.

Das war die Theorie, die Praxis hat man nun
Außerdem ist CMT ein zu schwammiger Begriff. Angenommen, sie trixen das nun hin, dass die riesige Sprungvorhersage weiterhin gemeinsam benutzt werden kann. Trotzdem gibts aber getrennte Decoder, 2 pro Thread statt 4 und statt 1x64kB gibts 2x32 L1I-Cache. Soviel mehr an Fläche braucht das nicht, und es wäre immernoch CMT; oder wie würdest DU das nennen?

Das ist erstmal nebensächlich. Die theoretisch maximale IPC liegt trotzdem bei 4.

Überleg Dir was Du sagst. Praktisch ist die IPC um 1. Wenn man jetzt so wie ich rechnet, hätte AMD immerhin noch ne Effizienz von 50%, in Deinem Fall nur von 25%. D.h. Du machst AMD schlechter als ich.

Na offensichtlich nicht, siehe nachfolgend.

Doch ganz offensichtlich schon. Nochmal ich schrieb AVX. AVX ist AVX und nicht AVX mit XOP und FMA. Meine Aussage bezog sich eindeutig auf AVX. Wenn ich X sage, kannst Du nicht sagen falsch, weil X zusammen mit Y ...
Du kannst gerne anmerken, dass ich den Sachverhalt mit FMA nicht erwähnt habe, der die theoretische Lage für AMD deutlich verbessern würde. Aber ich das hab ich absichtlich wegfallen lassen, da so gut wie keiner auf XOP+FMA codiert. Immerhin kümmern die sich bei x264 jetzt etwas darum, ein schöner Anfang, mehr aber auch nicht.
In der Praxis wird man ne Menge AVX-Code haben, bei dem AMD dann aber immer hinten liegen wird.

Ok, sind vermutlich doch nur 3. Ich zitiere mal den SOG:

Sag ich doch

Ich bin davon ausgegangen, dass jeweils ein IMAC an den Integer Ports hängt. Ist aber doch nur an Port 0 einer. Wie auch immer, es sind 2x 128-bit FMA + 2x 128-bit SIMD. Macht also insgesamt bis zu 3 256-bit Operationen. Rein von den Kapazitäten steht AMD also erstmal besser da, und nicht wie von dir behauptet Intel.

Siehe oben, ich habe behauptet das Intel mit AVX-Code AMD überlegen ist. Das war vorher schon richtig, und das bleibts auch
Ich akzeptiere gerne Deinen FMA-Hinweis, aber wieviel das in der Praxis bringt muss man erstmal abwarten. Mehr als 5%-Relevanz seh ich erstmal nicht, deswegen ließ ich das weg. Naja immerhin schauts im Moment schon besser aus, als damals mit 3dnow.
3 Opterationen würd ich aber auch nicht rechnen, die IMACs können nur INT und kein FP, helfen also nicht für den FP-Durchsatz. Man könnte sie jetzt bei INT-Zuschlagen, dann hätte man nen schönen 4er Durchsatz mit reinem INT-code. Aber solange keiner XOP nutzt, ist das auch nur schöne Theorie

Also ich finde es nicht praktisch. Für mich ist es nur eine Notlösung. Damit baust du dir nur unnötig Wartezyklen an Ports ein, die ansonsten anderweitig genutzt werden könnten.

Nö, denn die INT-Einheit hängt am gleichen Port. Wenn da jetzt ne FP-OP kommt, wäre der INT-Teil, der auch mit dran hängt eh arbeitslos.

Was anderes war aber vermutlich auf die Schnelle nicht machbar, um SB AVX zu spendieren. Wenn es so toll sein soll, dann frage dich doch mal, warum man das nicht schon mit SSE gemacht hat. Also die FPU auf 64-bit belassen und die anderen 64-bit von den Integer Rechenwerken abzweigen.

Na das war damals P4 und der mobile-Chip Yonah, die hatten noch ganz andere Ports. Insbesondere hatte die nur 2, Conroe wurde dann auf 3 aufgebohrt. Wenn mans grob betrachtet also von 2fach superskalar auf 3.

Ich rechne damit, dass mit Haswell diese Notlösung wieder rausfliegt und dieser eine "echte" 256-bit FPU mitbringt.

Jo Haswell wird so oder so ein großer Umbau, bin gespannt was das wird und wie sie FMA integeren werden.

 

[Opteron]

@Opteron
Es geht mir nicht um CMT als solches, der Punkt ist aber, wenn sich die decoder so mal eben auftrennen lassen und die Schwachstellen die Agner Fog in seinem Dokument angibt schon länger bekannt sind & simuliert, warum hat man BD dann überhaupt so gebracht und das mit den aufgrtrennten decodern nicht von Hause aus eingebaut.

Das ist ne gute Frage. Vermutlich haben sie falsch simuliert, oder sich aufs ursprüngliche Konzept von Glew verlassen ...

Das Problem mit der Bandbreite existiert auch nur wenn beide threads vollast anliegen haben, BD schafft aber IPC von 2 nichtmal im Singlethread.Fall. Daher ist das Decoderproblem nur sekundär.Dazu kommt, dass es im Programmablauf recht häufig schleifen gibt. Aktuell müssen die instruktionen in jedem schleifendurchlauf wieder und wieder durch die "langsamen" decoder. Ein Loop cache, wie der name schon sagt, verschafft dem Frontend hier luft, weil die schleife aus dem cache laufen kann und die decoder inzwischen schonmal weiterdecodieren können.

Ja nen Loop Buffer brauchts auf alle Fälle auch, aber das Thema hatten wir schon. Wenn Loop-Buffer, dann zwei pro Thread und dann ist ne Implementierung mit eigenem Decoder evetuell einfacher/besser/praktischer.

Daher würde ich eine verbreiterung und verbesserung des µCode-Verhaltens in Verbindung mit loop cache für besser halten.

Bin ich auch dafür, aber eventuell braucht mans halt in einem Aufwasch mit dezidierten Decodern (und hoffentlich weiterhin gemeinsam benutzer Sprungvorhersage).

Wenn man die CMT Vorteile ohnehin ad acta legt, hätte man sich den Aufwand ersparen können und gleich weder normale multicores bauen.
Aber wer bin ich schon...

Selbe Frage an Dich, wie an gruffi, was genau ist CMT?

Die von AMD werden sicher wissen was sie tun...

Hoffentlich

Intel sagt nicht umsonst, die Cachepipeline ist ebenso wichtig wie die Rechenpipeline selbst.

Jupp, die besten Rechenwerke bringen nichts, wenn die Daten nicht rangeschafft werden können.

bezüglich der scout threads... nunja... in Zeiten wo die Sprungvorhersagen über 90% trefferquoten liefern können, würde ich mal fast denken sollte es auch möglich sein die wahrscheinlichkeit dass spMT richtig liegt halbwegs hoch zu bekommen...

Naja, Sprungvorhersage ist was anderes, als spekulativ ausführen. Wie gut das liefe müßte man erstmal testen. Bin mir gerade nicht sicher, ob Glew dazu schon was schrieb.

@FredD:
Ebenfalls gleiche Frage, wann ist ein Chip CMT, und wann nicht

 

[Ge0rgy]

Ok die Definition ist schwammig, zugegeben, aber der Witz beim CMT war doch grade, dass Aufwändige Teile shared werden um Transistoren zu sparen.
Und das Frontend gehört wohl definitiv zu den aufwändigen Parts. Wie groß die Decoder selbst dabei allerdings genau sind, entzieht sich meiner Kenntnis.
Das ursprüngliche Konzept von Glew war ja dazu da spMT zu ermöglichen/vereinfachen, wenn sie wirklich so dusslich sind, das dann für baren Münze zu nehmen, spMT einfach wegzulassen und zu erwarten dass die Rechnung aufgeht, sind sie entweder dümmer als ich dachte oder ständig bekifft.
Ich kann doch auch nicht bei einem hochgezüchteten Turbomotor "mal eben" den Turbo weglassen und dann erwarten dass da ein super Aggregat rauskommt!?
Sprungvorhersage wird doch bereits benutzt um abzuschätzen wie ein sprung ausgeht und die Daten vorab in die caches zu laden. Ist es da so abwegig das nicht nur in die caches zu holen sondern gleich schonmal zu berechnen?
Ich meine Memory Dismabiguation ermöglicht ja schon loads vor stores zu machen und dabei in Kauf zu nehmen dass das falsche geladen wird weil der store es überschrieben hätte.
Sprungvorhersage ermittelt was als nächstes für Daten gebraucht werden. Also ist "die mitte" dazwischen ja wohl das spekulative rechnen.
Ich frage mich wie stark ein auf 6 fach aufgebohrter Decoder einen BD heute schon beschleunigen würde ohne dass man viel ändert.
Aber wieso meinst du zwei loop buffer pro thread!? je einen für Int und FP-Code oder wie?
ich denke der LB als solcher würde wenn groß genug sogar im aktuellen fall mit shared decoder vieles erleichtern. Er während die recheneinheiten munter takt um takt eine schleife durchjubeln könnte ein 6-fach decoder schonmal wieder ordentlich instruktionen nachschieben damits weitergeht.
Mit einem einzigen loop Buffer / Trace cache pro Modul hätte man evtl. noch ganz andere Möglichkeiten, man könnte nämlich im singlethread-Fall unabhängige Instruktionen auf dem zweiten int-Kern rechnen lassen. Die Aufteilung der Instruktionen auf die Int-Kerne wäre also im singlthread-Fall weniger statisch. Da effektiv sowieso alle instruktionen aus dem gemeinsamen I$ kommen wäre es also auch wurscht welcher INT-Core sie nun definitiv ausführt.
Naja, ich träume zuviel.
Aber irgendwie kommt mir die Sache mit den getrennten decodern quer. IMHO könnte man dann gleich wieder konventionelle Kerne bauen und sich das ganze Drama sparen.
Nebenbei bemerkt, wäre interessant ob ein BD aktuell mit Loop Buffer überhaupt die 2er IPC knacken kann oder ob es im retirement und bei LOAD/STORE da nicht noch etwas klemmt...
Ein paar der von Agner Fog gefundenen "Probleme" betraf ja auch unnötige Verlangsamungen bei bestimmten Cachezugriffen wenn die eine cacheline überspannen o.ä.
Also müsste man hier erstmal Hand anlegen und die cachepipeline optimieren bevor man sich über die decoder gedanken macht.
Was mich bei getrennten decodern auch interessiert, ob man dann nicht gleich 3 pro INT-Core bräuchte um die FP-unit mit gefüttert zu halten... mit 2 Decodern bei 2 ALUs kann man nur Int gesättigt halten, nicht auch noch FP.

 

[FredD]

Wenn Loop-Buffer, dann zwei pro Thread ...

Schlägt zwar in eine andere Richtung (VLIW), dürfte aber deine Aussage zumindest relativieren: Clustered Loop Buffer

@FredD:
Ebenfalls gleiche Frage, wann ist ein Chip CMT, und wann nicht

Da müsste man wohl die Ingenieure von Sun fragen, die haben das Konzept zuerst aufgebracht und so benannt. Ich würde den Begriff auf "Architektur mit mehr als 1 Integer ALU pro Kern, die auf gemeinsam geteilte Funktionseinheiten zugreifen" zusammenraffen.

 

[gruffi]

Angenommen, sie trixen das nun hin, dass die riesige Sprungvorhersage weiterhin gemeinsam benutzt werden kann. Trotzdem gibts aber getrennte Decoder, 2 pro Thread statt 4 und statt 1x64kB gibts 2x32 L1I-Cache. Soviel mehr an Fläche braucht das nicht, und es wäre immernoch CMT; oder wie würdest DU das nennen?

Das wäre aber kontraproduktiv für singlethreaded Performance. Was genau hast du damit also gewonnen?

Überleg Dir was Du sagst. Praktisch ist die IPC um 1. Wenn man jetzt so wie ich rechnet, hätte AMD immerhin noch ne Effizienz von 50%, in Deinem Fall nur von 25%. D.h. Du machst AMD schlechter als ich.

Das ändert trotzdem nichts an der theoretisch maximalen IPC von 4. Das sollte für AMD ja vielmehr das Signal sein, dass man bezüglich Auslastung noch Spielraum nach oben hat.

Doch ganz offensichtlich schon. Nochmal ich schrieb AVX. AVX ist AVX und nicht AVX mit XOP und FMA. Meine Aussage bezog sich eindeutig auf AVX.

Ich weiss ja nicht, ob dir das nicht bekannt ist, aber FMA ist Teil der AVX Spezifikation. Und die Integer Einheiten kommen nicht nur bei XOP zum Zuge, sondern genauso bei MMX, SSE und AVX. Wie ich bereits sagte, was du geschrieben hast, ist nicht ganz korrekt. Intel steht bezüglich Ausführungskapazitäten nicht besser da. Ganz im Gegenteil. Daran ändern übrigens auch 3 statt 4 256-bit Ops nichts.

3 Opterationen würd ich aber auch nicht rechnen, die IMACs können nur INT und kein FP, helfen also nicht für den FP-Durchsatz.

Darum ging es auch gar nicht. Keiner hat ausschliesslich von FP Operationen gesprochen.

Nö, denn die INT-Einheit hängt am gleichen Port.

Ist das nicht schon Einschränkung genug? Bei AMD hängen sie schliesslich an unterschiedlichen Ports. Was ist, wenn eine Integer Operation gerade ausgeführt wird? Dann ist einer der Ports bei Intel auf jeden Fall erstmal blockiert für eine 256-bit FP Operation. Und hast du dir schon mal die Befehlslatenzen angeschaut? Was Intel da macht, gibt's nicht gratis. Das hast du ja nun schon selbst erwähnt.

Na das war damals P4 und der mobile-Chip Yonah, die hatten noch ganz andere Ports.

Ich spreche von Pentium-M / Core. Die hatten im Grunde die gleichen Ports. Da hat sich bis heute nicht viel geändert.

 

[Opteron]

@Ge0rgy:
Sorry, das mit dem 2 Puffer pro Thread war großer Blödsinn
Meinte 2 pro Modul, für jeden Thread einen, das wurde dann verkürzt wiedergegeben und damit ziemlicher Unsinn ^^

Ansonsten, tja das Front-End .. tolle Baustelle. Hab mich gerade wieder an die Schwungrad-Sache erinnert, das hatte Dresdenboy in der guten alten Zeit mal ausgegraben, hatte das hier mal zusammengefasst:
http://www.planet3dnow.de/vbulletin/showthread.php?p=4314475#post4314475

Hab auch nochmal das Paper überflogen, interessant ist eventuell die Aussage über CISC-Decoder im Allgemeinen:

Due to the use of CISC ISA, the parallel x86 decoders have been traditionally one of the most complex parts of the processor, limiting the maximum achievable clock frequency and amounting for an important part of the total power budget.

Eventuell ging einfach nicht mehr beim BD, größere Decoder hätten eventuell die Taktfrequenz gedrückt. Mit Flywheel könnte man das auch umgehen. Hoffentlich kommts noch, oder wenigstens halt irgendein Puffer *g*
Im Flyweehl Patent reden sie auch von nem doppelt so hoch getaktetem Front-End, wäre ja ideal fürs 2 Kerne
Da könnte man dann weiter spekulieren, ob ct vielleicht was falsch verstanden hat. Z.B. das jeder Thread seinen eigenen Trace-Cache / µOpPuffer, oder wie auch immer wirs nennen, bekommt.

Das wäre aber kontraproduktiv für singlethreaded Performance. Was genau hast du damit also gewonnen?

Tipp: Zwei Caches = Doppelter Durchsatz.

Das ändert trotzdem nichts an der theoretisch maximalen IPC von 4. Das sollte für AMD ja vielmehr das Signal sein, dass man bezüglich Auslastung noch Spielraum nach oben hat.

Ja so siehts der Optimist

Ich weiss ja nicht, ob dir das nicht bekannt ist, aber FMA ist Teil der AVX Spezifikation.

Wer hat Dir denn den Unsinn erzählt? FMA hat eigene CPUID. Wenns so wäre, dann würde Sandy-Bridge ja auch FMA können müssen, schließlich hat er AVX und laut Deiner Auffassung würde das FMA beinhalten. Nene, das ist großer Käse, den Du da erzählst.
Und selbst wenn irgendwo in nem aktuellen Intel AVX Manual was von FMA stünde, dann wäre das sicherlich nicht AMDs FMA4 *g*

Und die Integer Einheiten kommen nicht nur bei XOP zum Zuge, sondern genauso bei MMX, SSE und AVX.

Ah, das stimmt, v.a. SSSE3 geht noch auf die beiden Ports, das Shuffel-Zeugs halt. Gut, da hast Du also recht.

Wie ich bereits sagte, was du geschrieben hast, ist nicht ganz korrekt. Intel steht bezüglich Ausführungskapazitäten nicht besser da. Ganz im Gegenteil. Daran ändern übrigens auch 3 statt 4 256-bit Ops nichts.

Auch wenn Dus weiter nicht einsehen willst ich schrieb explizit AVX Instruktion. Da ist es auch egal, ob irgendein Manual vielleicht nen Schreibfehler hat. Eine FMA-Instruktion ist ganz sicher keine AVX Instruktion. Keine Ahnung, was Du da für ein Interpretationsproblem hast

Darum ging es auch gar nicht. Keiner hat ausschliesslich von FP Operationen gesprochen.

Doch ich, ne AVX-Instruktion ist perse FP. INT Befehle kommen erst mit AVX2

Ist das nicht schon Einschränkung genug? Bei AMD hängen sie schliesslich an unterschiedlichen Ports. Was ist, wenn eine Integer Operation gerade ausgeführt wird? Dann ist einer der Ports bei Intel auf jeden Fall erstmal blockiert für eine 256-bit FP Operation.

Hmm nö, wieso sollte es ein Problem sein? Wenn eine INT gerade ausgeführt wird, dann kann logischerweise kein FP Befehl an dem einen Port drankommen. Aber insgesamt gibts 3 Ports, an jedem hängen gemischte INT/FP Units, das reicht schon.

Und hast du dir schon mal die Befehlslatenzen angeschaut? Was Intel da macht, gibt's nicht gratis. Das hast du ja nun schon selbst erwähnt.

Hm meinst Du die Latenz beim Moduswechsel? Ja die hab ich erwähnt. Ansonsten - bei den normalen Latenzen - war AMD aber sehr selten vorne. Darüber will ich mich aber gar nicht beschweren, ist eher normal, BD ist halt auch mehr ein Hochtaktdesign, als Intels Ansatz.

Ich spreche von Pentium-M / Core. Die hatten im Grunde die gleichen Ports. Da hat sich bis heute nicht viel geändert.

Nenn mal Codenamen, z.B. Yonah, Pentium-M gabs viele.
Conroe war bereits 128bittig. Gegenüber Yonah wurde da nicht nur AMD64 und von 64->128b SSE aufgebohrt, sondern auch ein dritter Port (Port 5) nachgerüstet, wie schon erwähnt eben der Schritt von 2fach auf 3fach superskalar. Das entspannt die ganze Lage allgemein, wenn da ein kompletter Port mit 3-4 untergeordneten INT/FP-Units zusätzlich angeschlossen wird.
Ums abzuschließen: Datenpfade waren von 64 -> 128b nicht das Problem, da eh viel umgebaut wurde. Aktuell dagegen wurde nur die Vektoren auf 256b erweitert, nur dafür großartig Leitungen zu verlegen rentiert nicht. Außerdem gibts noch 2 weitere Ports, an die man eventuelle INT-Ops vergeben kann. Beim Yonah häts nur eine Alternative gegeben. Nebenbei bemerkt, wenn Du schon Intel kein "echtes" 256b AVX bescheinigst, was hat dann AMD? Da ists doch eher schlimmer, eine 256b Instruktion muss in 2 Ops zerlegt werden und wenn man direkt mit 2 gleichwertige 128b Befehlen programmiert ist man ~3% schneller.

 

[gruffi]

Tipp: Zwei Caches = Doppelter Durchsatz.

Bei singlethreaded Workloads? Eher nicht.

FMA hat eigene CPUID.

Und? Wen interessiert das denn? Du kannst dir das AVX Whitepaper bei Intel runterladen und selbst nachschauen. Danach können wir gerne nochmal darüber reden, wer hier Unsinn erzählt. Ich zitiere dir sogar den relevanten Teil:

FMA is a future extension of Intel AVX

Der Punkt ist einfach, dass Intel noch kein FMA bei Sandy Bridge bringen konnte. Daher haben sie FMA ein extra Kapitel spendiert. Und deshalb hat auch CPUID ein extra Bit dafür. Was nichts daran ändert, dass FMA zu AVX gehört.

Doch ich, ne AVX-Instruktion ist perse FP. INT Befehle kommen erst mit AVX2

Ich weiss nicht, was du für ein Problem hast, dir auch mal was sagen zu lassen. Aber eines sollte dir bewusst sein, ohne überheblich klingen zu wollen, über solche Sachen weiss ich ganz bestimmt besser Bescheid als du. Was du hier erzählst, ist schon wieder Halbwissen. Wie zuvor auch schon. AVX(1) ist nicht per se FP, auch wenn hier sicherlich der Fokus liegt. AVX(1) besitzt auch implizite und explizite Ganzzahloperationen. Implizite sind jene, die ebenfalls von Ganzzahlrechenwerken verarbeitet werden, selbst wenn sie als FP Instruktionen deklariert sind. Ein typisches Beispiel sind logische Operationen (and, or, xor). Und du darfst dir gerne mal im AMD SOG anschauen, wo diese Operationen verarbeitet werden. Richtig, nicht in den FMACs, sondern an Port 2 und 3. Also den Ports, wo das ganze Ganzzahl Gedöns dranhängt. Es ist also problemlos möglich, dass 4 AVX Instruktionen an allen 4 Ports ausgeführt werden, auch ohne FMA.

Hmm nö, wieso sollte es ein Problem sein? Wenn eine INT gerade ausgeführt wird, dann kann logischerweise kein FP Befehl an dem einen Port drankommen.

AMD kann es aber eben gleichzeitig mit getrennten Ports, Intel nicht. Mal davon abgesehen, jede Instruktion hat eine gewisse Latenz, braucht also eine bestimmte Anzahl an Zyklen, bis sie von den EUs verarbeitet wurde. Inwiefern man jeden neuen Zyklus bereits eine neue Operation nachschieben kann, kann ich dir nicht sagen. Wenn die Rechenwerke aber voneinander unabhängig arbeiten, sollte das möglich sein. Bei Intels Lösung ist das auf jeden Fall nicht möglich, da die Rechenwerke eben nicht mehr voneinander unabhängig sind.

Hm meinst Du die Latenz beim Moduswechsel? Ja die hab ich erwähnt. Ansonsten - bei den normalen Latenzen - war AMD aber sehr selten vorne. Darüber will ich mich aber gar nicht beschweren, ist eher normal, BD ist halt auch mehr ein Hochtaktdesign, als Intels Ansatz.

Mal davon abgesehen, dass AMD kein Hochtaktdesign besitzt, ich sprach nicht von AMD. Es ging um Intel vs Intel, mit und ohne diese Notlösung.

Nenn mal Codenamen, z.B. Yonah, Pentium-M gabs viele.

Core war Yonah. Der Vorgänger in Form des Pentium-M war glaube ich Dothan.

Conroe war bereits 128bittig. Gegenüber Yonah wurde da nicht nur AMD64 und von 64->128b SSE aufgebohrt, sondern auch ein dritter Port (Port 5) nachgerüstet, wie schon erwähnt eben der Schritt von 2fach auf 3fach superskalar. Das entspannt die ganze Lage allgemein, wenn da ein kompletter Port mit 3-4 untergeordneten INT/FP-Units zusätzlich angeschlossen wird.

Port 5 ändert aber nichts am Sachverhalt. Das sind ja lediglich weitere Operationen. Thema ist erstmal Port 0 und 1. Und die existierten eben schon bei Yonah. Wenn's also so toll gewesen sein soll, hätte man schon dort Integer und FP Rechenwerke gemeinsam nutzen können. Die Ausgangssituation war die gleiche wie bei SB. Unterschied ist lediglich, dass es damals um die Hälfte der Datenbreite ging. Der sonstige Umbau beim Core 2 tut da nichts zur Sache.

Nebenbei bemerkt, wenn Du schon Intel kein "echtes" 256b AVX bescheinigst, was hat dann AMD?

Bitte nicht schon wieder so viel erfinden. Etwas derartiges habe ich nicht gesagt. Ich sagte "echte" 256-bit FPU. Wie diese dann strukturiert ist, 1x 256-bit, 2x 128-bit (AMD) oder 4x 64-bit, ist ein anderes Thema.

 

[Crashtest]

Also FMA gehört nicht zu AVX !

Oben stehts doch gut erklärt:

Sandy kann AVX. Sandy kann aber kein FMA. Wäre FMA ein Teil von AVX könnte der Sandy dies doch !!!!

Es ist durch aus möglich, dass FMA ein Teilbestandteil von AVX2 wird - vergleichbar dem Basissatz, dass SSE2 bei AMD64 dabei ist (es gibt kein AMD64-fähigen Prozzi ohne SSE2)

Nebenbei - bekämpft euch auf Computerbase oder per PM !!!!!!!!

 

[gruffi]

Natürlich gehört FMA zu AVX. Das Zitat ist doch eindeutig. Ich glaube, ihr habt einfach Verständnisprobleme mit dem Oberbegriff AVX und einzelnen Iterationen davon. AVX(1), AVX2, AVX3 oder was da noch kommen mag, ist alles AVX. Genauso wie SSE(1), SSE2, SSE3, etc, alles SSE ist.

 

[ONH]

Ach ne, dann ist ja klar das ihr beide aneinander vorbeigeredet hat der eine meint mit AVX die Erweiterungen (Vonder ersten bist zur Versionwelche Nächstes Jahr oder Später in Prozessoren implementiert werden) allgemein und er Andere die erste Version welche Intel in SB implementiert hat, wo FMA nicht dabei ist. Dann kann man ja jetzt das Streiten darum was dazugehört lassen, da schlussendlich wohl beide nicht unrecht haben, und zurück zum Thema Kaveri kommen.

 

[Dresdenboy]

Ok, zu warten, bis der Diskussionsstaub sich legt, würde wohl dazu führen, dass ich mich erst auf Seite 100 des Threads beginne einzumischen ;^) Also werfe ich jetzt mal ein paar Gedanken ins Feld:

Wie die von mir im Trinity-Thread geposteten P/F-Kurven zeigten, sinkt in höheren Taktbereichen die Effizienz (Performance/Watt) schnell. Was da nicht zu sehen war: ein (zunehmender Teil) davon ist Leakage.

Was dagegen für das Design festgelegt wurde, sind die TDP-Stufen. Wenn nun fleißig hier und da zusätzliche Logik eingebaut wird, wächst erstmal die Leakage, unabhängig vom Clock-Gating (welches die Auslastungseffekte abmildert). Aber auch im idle-Betrieb sind ein paar Verbraucher aktiv. Also die separate FPU pro Kern könnte den Idle-Verbrauch vom Modul um 20% erhöhen (Clock-Anteil entspr. Flächenanteil plus den FP-Grundumsatz).

Beim Linpack-Benchmark nutzt die FPU (inkl. Anteil bei "Clock") etwa 30% des Verbrauchs allein in Anspruch. Mit doppelter FPU wäre das dank weniger Auslastung zwar geringer, aber durch die notwendigen Erweiterungen bei Decoder, L/S-Unit usw. schätze ich, dass der Verbrauch dann immer noch grob 25% höher wäre.

Dazu nochmal die Graphen bei The Register (für mehr Farbe im Thread):

http://www.theregister.co.uk/2011/02/24/amd_bulldozer_core_isscc/page2.html

Ergebnis:

Idle+20%, Load+25%. Höherer Idle-Verbrauch wirkt sich auf die Turbospielräume anderer Module aus und wäre schlecht für Mobile-CPUs, der FP-Load-Verbrauch schränkt den Takt generell ein, etwa. 15-20% (die Spannung kann dann ja gesenkt werden). Also nach Taktkorrektur erreicht das Konstrukt bei HPC evtl. 50% mehr FP-Performance, bei Spielen u.ä. FP-Codes so 0-20%. Als dedizierer HPC-Chip wäre das interessant.

Die Herstellkosten des Chips würden nur um ein paar Dollar steigen.

Man kann die Auswirkungen eines dedizierten Decoders, L2-Caches, FPU und aller weiteren geteilten Komponenten in Aten-Ra's Blog nachlesen:
http://atenra.blog.com/2012/02/01/amd’s-bulldozer-cmt-scaling/

Die 4M/4T-Fälle einiger FP-Benchmarks zeigen genau den Fall.


Idontcare im Anandtech-Forum hat da auch eine ausführliche Analyse verschiedener Verbrauchseffekte beim Sandy Bridge durchgeführt:
http://forums.anandtech.com/showthread.php?p=32451355#post32451355

 

[Opteron]

Du kannst dir das AVX Whitepaper bei Intel runterladen und selbst nachschauen. Danach können wir gerne nochmal darüber reden, wer hier Unsinn erzählt. Ich zitiere dir sogar den relevanten Teil:

Natürlich gehört FMA zu AVX. Das Zitat ist doch eindeutig. Ich glaube, ihr habt einfach Verständnisprobleme mit dem Oberbegriff AVX und einzelnen Iterationen davon. AVX(1), AVX2, AVX3 oder was da noch kommen mag, ist alles AVX. Genauso wie SSE(1), SSE2, SSE3, etc, alles SSE ist.

Ne, das Problem ist, dass Du nicht up-to-date bist und olle Kamellen erzählst. Dein Zitat gabs zuletzt in der 2009er Spezifikation. Dein AVX Paper gibts auch gar nicht mehr, das heißt jetzt nicht mehr "Intel® Advanced Vector Extensions Programming Reference" sondern allgemein "Intel® Architecture Instruction Set Extensions Programming Reference". Mittlerweile haben wir eben 2012 und es gibt anstatt der 2009er Version 6 (Dateiname: AVX_319433-006) jetzt Version 12a vom Februar 2012 (319433-012a).

Alt:

FMA is a future extension of Intel AVX

Neu:

FMA instruction extensions are described in Chapter 6.

Links:
http://software.intel.com/file/41604
http://software.intel.com/file/21558

Also bring Dich mal auf den neuesten Stand. Für mich ist das Thema damit beendet.

@Dresdenboy:
Danke. Hast Du eigentlich nochmal irgendwo was vom Flywheel gehört? Hab gerade gesehen, dass im Flywheelpaper in den Quellen auch auf ein früheres Paper verweisen. Das liest sich eigentlich genau wie die Implementierung des SandyB. µCode Caches:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.4152&rep=rep1&type=pdf

Vielleicht kommt Flywheel ja in Haswell ...

 

[gruffi]

Ne, das Problem ist, dass Du nicht up-to-date bist und olle Kamellen erzählst. Dein Zitat gabs zuletzt in der 2009er Spezifikation. Dein AVX Paper gibts auch gar nicht mehr, das heißt jetzt nicht mehr "Intel® Advanced Vector Extensions Programming Reference" sondern allgemein "Intel® Architecture Instruction Set Extensions Programming Reference". Mittlerweile haben wir eben 2012 und es gibt anstatt der 2009er Version 6 (Dateiname: AVX_319433-006) jetzt Version 12a vom Februar 2012 (319433-012a).

Nee, das Problem ist, dass du jetzt nur wieder nach Ausreden suchst. Ich habe neben der ursprünglichen Version auch 319433-011 hier. Die ist von Juni 2011 und mW auch die aktuellste Final Version. Da heisst es übrigens immer noch Intel® Advanced Vector Extensions Programming Reference. Da brauchst du nicht bis 2009 zurückzugehen oder mir was von irgendeiner Alpha Version erzählen, die du jetzt nach vielleicht 2 Tagen Suche gefunden hast, von der du bisher gar nichts wusstest. Das ist einfach nur kindisch. An meiner ursprünglichen Aussage ändert das ja nichts. AVX(1) und FMA gehören zur selben Spezifikation. Selbst wenn diese nun nicht mehr AVX, sondern anders heissen mag.

 

[Dresdenboy]

Interessante Diskussion. Die veröffentlichten AMD Marketing-Bildchen lassen miich jedoch nicht so recht an eine Abkehr vom CMT-Ansatz glauben.

Das glaube ich auch nicht, deshalb auch meine Ausführungen. Das Konzept ist nicht das Problem, sondern eher die beschlossenen Trade-Offs, Constraints, Kosten/Zeit/Komplexitäts-Überlegungen.

Aber wenn Zeit und Kosten bei BD1 noch nicht ausreichten, werden diese sich über den gezeigten Pfad noch gut akkumulieren.