Kaveri - der Trinity Nachfolger

[Gipsel]

"consisting of four 32-bit memory channels."

Na klar doch..

Edit: "Currently most commonly deployed chips only feature 2 GBit capacity, which translates to 256MB per chip."

Das dürfte dann die Erklärung dafür sein warum man Desktops doch lieber mit DDR3/4 bauen mag. Allerdings frage ich mich wie die 8 GB der PS4 zustande kommen sollen. 32 GDDR5-Chips auf dem Mainboard?

Inzwischen gibt es 4 GBit-Chips (PS4 wird 16 davon benutzen). An einem 128Bit-Interface bekommt man 8 davon unter (im Clamshell-Modus, jeder Chip mit 16Bit angebunden, das unterstützt GDDR5 standardmäßig), sind dann also 4 GB maximal.

Edit:
Opteron hat natürlich recht. Wenn man sich mal die Datenraten anschaut, die laut BSN supported werden, sieht das viel eher nach DDR4 als nach GDDR5 aus.

 

[BavarianRealist]

Wieso sollte AMD dem Kaveri nicht die Möglichkeit der Nutzung von GDDR5 bieten? Die Technologie hat AMD im Hause und für die PS4_APU wird sie auch realisiert. Auf Basis von Kaveri könnte die weit bessere Gamer-APU entstehen, die mit den BD-Kernen auch im Singlethread-Bereich mehr leistet und für einen Windows-Rechner wohl deutlich universeller wäre als eine PS4-ähnliche APU. Wenn AMD dem Kaveri ordentlich GPU gibt und das Ganze mit GDDR5 ausgeliefert würde, hätte AMD damit womöglich wieder ein Produkt, womit sie sich dann klar von Intel differenzieren können. Für OEMs dürfte sich damit eine interessante Lösung anbieten, der Intel nichts entgegen stellen kann. Wollts sich AMD nicht auch in Zukunft mehr an große OEMs halten und vom Channel eher abwenden? Dann brauchen sie Lösungen, die den OEMs gefallen und die Intel (noch) nicht hat.

Die Idee mit dem GDDR5 und einem womöglich richtig GPU-starken Kaveri würde mir sehr gut gefallen.

 

[FredD]

DDR und GDDR verdeutlichen den Trade-Off zwischen Latenz (möglichst gering) und Bandbreite (möglichst hoch). So leicht dürfte sich ein auf niedrige Latenz ausgelegtes Design (insbesondere der GPU-Part, der bei Kaveri vermutlich wieder ohne L3 auskommen muss) nicht auf hohe Bandbreite umstellen lassen.

Ein ganz interessanter Artikel (neben den vielen nicht frei zugänglichen Fachartikeln zu diesem Thema) z.B:
http://archive.arstechnica.com/paedia/b/bandwidth-latency/bandwidth-latency-1.html

Ein Kaveri mit GDDR5 käme vermutlich dem PS4 "Orbis" recht nahe: ein breites auf maximales Multithreading/HSA-Nutzung ausgelegtes Design. Vermarkte dies mal bitte im Desktop-Bereich, welcher weiterhin von der Single-Threading Dominanz Intels (und der Software-Schmieden, die sich darauf ausruhen) bestimmt wird.

Wenn du mit "GPU-stark" mehr als die bisher spekulierten 512 Shader-Einheiten meinst, verstehe ich deine Aussage nicht ganz. Das Gegenstück davon (z.B. 128 Shader kombiniert mit 4 Steamroller-Modulen) würde eher dem Erfolgsmodell der Konkurrenz entsprechen (Vishera-Nachfolger). Würde mir auch sehr gut gefallen So viel zum Wunschdenken.

 

[Dresdenboy]

DDR und GDDR verdeutlichen den Trade-Off zwischen Latenz (möglichst gering) und Bandbreite (möglichst hoch). So leicht dürfte sich ein auf niedrige Latenz ausgelegtes Design (insbesondere der GPU-Part, der bei Kaveri vermutlich wieder ohne L3 auskommen muss) nicht auf hohe Bandbreite umstellen lassen.

Es sind eher zwei Trade-Offs zwischen schmal und breit (Bitleitungen) sowie langsam und schnell (Transferrate pro Leitung). Und das Ganze lässt sich mit Stacking noch deutlich steigern.

Die Latenzen der DRAM-Chips haben eher physikalische Grenzen. Die Bandbreite wird auch intern beeinflusst (wieviel DRAM-Bänke gleichzeitig angesprochen werden). Die Interfaces (DDRx/GDDRy) spielen eher eine Rolle bei der Bandbreite (passend zu den gleichzeitig ausgelesenen DRAM-Bänken). Die Latenz der Bänke wird dadurch nicht beeinflusst, genauso wie mehrere Frauen gleichzeitig trotzdem 9 Monate bis zur Geburt von Kindern benötigen.

P.S.: Im S|A-Forum merkte jemand an, dass man auf dem Kaveri (?) Devkit-Foto keine DIMMs sehen kann.

 

[Opteron]

P.S.: Im S|A-Forum merkte jemand an, dass man auf dem Kaveri (?) Devkit-Foto keine DIMMs sehen kann.

Na das sieht man doch gleich, hatten wir auch schon hier:
http://www.planet3dnow.de/vbulletin/showthread.php?p=4742653

AUf der Llano-Plattform gabs das auch nicht, vermutlich ist es unter dem Radiallüfter versteckt, da ist ja Platz, die CPU ist ja daneben.
Interessanter ist da Gipsels Entdeckung, dass auch keiN Chipsatz vorhanden ist. Falls Kaveri also nicht auch ein voller SoC mit integrierter SB ist (Sockel FM3?), sollte das ein Kabini System sein.

 

[FredD]

Schön ausgeführt (Trade-Offs).

P.S.: Im S|A-Forum merkte jemand an, dass man auf dem Kaveri (?) Devkit-Foto keine DIMMs sehen kann.

Ein PS4-Devkit erscheint bei einem Spiele-Entwickler auch deutlich schlüssiger. ("Die andere Erklärung", siehe Opterons Post, der mir schnell zuvorgekommen ist). Immerhin kann man ein BluRay Laufwerk sehen.

 

[Markus Everson]

Wieso sollte AMD dem Kaveri nicht die Möglichkeit der Nutzung von GDDR5 bieten?

Vermutlich aus dem gleichen Grund aus dem AMD nach dem PhenomII aufgehört hat DualMode-RAMController zu verbauen. Glaubst Du etwa die OEMS haben darum gebettelt die Bestückungsfrage durch "eine Auswahl weniger" einfacher zu gestalten?

Die Technologie hat AMD im Hause und für die PS4_APU wird sie auch realisiert.

Die PS4_APU dürfte Sony exclusiv für sich in Anspruch nehmen. Ein eigenes Die wäre zwar möglich, die Kosten müssten dann aber angesichts des Preissegments durch sehr hohe Stückzahlen wieder reingeholt werden. Die sehe ich nicht, Du etwa?.

Auf Basis von Kaveri könnte die weit bessere Gamer-APU entstehen, die mit den BD-Kernen auch im Singlethread-Bereich mehr leistet und für einen Windows-Rechner wohl deutlich universeller wäre als eine PS4-ähnliche APU.

Weit besser als PS4 reicht aber nicht. Sie muss weit besser sein als Kaveri+dGPU und weit besser als Core+dGPU.

Wollts sich AMD nicht auch in Zukunft mehr an große OEMs halten und vom Channel eher abwenden?

Richtig. Wie kommst Du darauf das die OEMs auf Lowcost APUs stehen die nur mit Hochpreis-RAM zusammen arbeiten?

 

[Gipsel]

DDR und GDDR verdeutlichen den Trade-Off zwischen Latenz (möglichst gering) und Bandbreite (möglichst hoch).

Nicht so ganz. Alle DRAM-Chips haben seit Jahren Latenzen im identischen Bereich, wenn man es in Nanosekunden ausdrückt. Als typische/gute Werte kann man so etwa 10-10-10-30 ns annehmen. Das gilt über alle DDR-Varianten und auch für GDDR3/4/5 (die Speicherzellen sind ja die gleichen, die hängen nur an einem anderen Interface). Plusminus ein paar wenige Nanosekunden, wenn man sehr teuren oder billigen Speicher nimmt, aber das ist immer diese Region. Ich hatte mir mal kürzlich das Datenblatt von 6Gbps GDDR5 von Hynix rausgesucht. Der hat bei 1.5GHz zwar z.B. eine CAS-Latenz von 17 Takten (bei niedrigeren Frequenzen geht das runter, wenn man den mit nur 1 GHz [4Gbps] betreibt, sind CL 12 erlaubt), aber in ns kommt man auch wieder auf 11,3-10-12-28, also praktisch wie auch bei üblichem DDR3 (DDR3-2133 mit 11-11-11-30 hat in ns 10,3-10,3-10,3-28,1).

 

[Dresdenboy]

Na das sieht man doch gleich, hatten wir auch schon hier:
http://www.planet3dnow.de/vbulletin/showthread.php?p=4742653

AUf der Llano-Plattform gabs das auch nicht, vermutlich ist es unter dem Radiallüfter versteckt, da ist ja Platz, die CPU ist ja daneben.
Interessanter ist da Gipsels Entdeckung, dass auch keiN Chipsatz vorhanden ist. Falls Kaveri also nicht auch ein voller SoC mit integrierter SB ist (Sockel FM3?), sollte das ein Kabini System sein.

Die Llano-Plattform ist auch ein interessanter Hinweis. Zumindest habe ich mal den direkten Weg gewählt und den Originalposter des Bildes gefragt. Antwort: die DIMMs sind auf der Rückseite. Evtl. fänden wir da auch etwas vom Chipsatz.

 

[Complicated]

Interessante Info von Sony - dieses Jahr sollen noch 16 Mio. PS4 ausgeliefert werden:
http://www.pcgames.de/PlayStation-4...illionen-PS4-Konsolen-in-diesem-Jahr-1059091/

Mit der PlayStation 4 läutete Sony am 20. Februar die Next-Generation ein - der Release der PS4 ist für Ende dieses Jahr geplant. Und offenbar hat sich Sony zum Ziel gesetzt, in diesem Jahr 16 Millionen PlayStation 4-Konsolen an den Handel auszuliefern.

 

[Dresdenboy]

Das wäre ein ordentlicher Zuwachs zu AMD's üblichen Umsatzzahlen. Leider ist das Konsolengeschäft sehr Q4-lastig.

 

[Complicated]

Sony hat August als Launch Monat[/STRIKE] als Zulierfermonat der Teile genannt in dem Artikel. [STRIKE]Kann sein, dass sie einige Monate Vorsprung vor der Xbox haben wollen.
http://www.digitimes.com/news/a20130304PD221.html

Having high hopes on its Playstation 4 (PS4) game console, Sony internally expects the machine's annual shipments to reach 16 million units in 2013 with the supply chain expected to start mass shipments in August, according to sources from PS4 component makers.

Sollte für AMD früher in den Büchern stehen

 

[gruffi]

BSN hat einen Artikel über Kaveri und Steamroller. Infos stammen angeblich von "Preliminary BIOS and Kernel Developer's Guide for AMD Family 15h Models 30h-3Fh Processors". Einige interessante News, wie ich finde:

• 2-3 CUs (4-6 "Kerne")
• GDDR5 SI
• 96 KB L1I, 3-fach assoziativ
• virtualisierter Interrupt Controller
• Onion Interface auf 256-bit verbreitert

IPC Verbesserungen:

• Store to load forwarding optimization
• Dispatch and retire up to 2 stores per cycle
• Improved memfile, from last 3 stores to last 8 stores, and allow tracking of dependent stack operations.
• Load queue (LDQ) size increased to 48, from 44.
• Store queue (STQ) size increased to 32, from 24.
• Increase dispatch bandwidth to 8 INT ops per cycle (4 to each core), from 4 INT ops per cycle (4 to just 1 core). 4 ops per cycle per core remains unchanged.
• Accelerate SYSCALL/SYSRET.
• Increased L2 BTB size from 5K to 10K and from 8 to 16 banks.
• Improved loop prediction.
• Increase PFB from 8 to 16 entries; the 8 additional entries can be used either for prefetch or as a loop buffer.
• Increase snoop tag throughput.
• Change from 4 to 3 FP pipe stages.

 

[Opteron]

Oh wow cool, endlich mal handfeste Daten
Da schreib ich doch gleich ne News dazu.

Danke

 

[Markus Everson]

Sony hat August als Launch Monat als Zulierfermonat der Teile genannt in dem Artikel.

Falsch. Sony kam in dem Artikel nicht zu Wort und wurde auch nicht zitiert. Papa, Charlie hat gesagt sein Papa hat gesagt...

 

[gruffi]

Noch ein paar Gedanken zum BKDG.

Bis zu 3 CUs wäre auf jeden Fall unerwartet. Scheinbar will man sich doch nicht einfach so im "High-End" Segment geschlagen geben. Damit könnte man zumindest auch APU-seitig i5 besser unter Druck setzen und nicht nur i3. Nicht nur bei Desktops, vor allem bei Notebooks. 3 CUs mit etwas weniger Takt dürfte auch der Effizienz zugute kommen im Vergleich zu 2 CUs mit mehr Takt. Vielleicht gibt 28nm Bulk aber auch nicht so hohe Taktraten her? Wir werden es sehen. Schaut scheinbar so aus, dass Kaveri nicht grundlos verzögert wurde, sondern dass man nochmal einige Hebel an der richtigen Stelle angesetzt hat. Aber erst mal abwarten, ob die Infos aus dem BKDG letztendlich auch so zutreffen. Ich bin da immer etwas vorsichtig. Auf den bisherigen Kaveri Roadmaps war jedenfalls immer nur von maximal 4 "Kernen" (2 CUs) die Rede.

GDDR5 basiert ja auf DDR3. Ungewiss, ob FM2 deshalb ausreichend ist oder doch ein neuer Sockel notwendig wird. Abwärtskompatibilität wäre aber schon nicht schlecht.

2 Stores pro Takt sollte eine weitere Baustelle beseitigen und die bisher deutlich zu niedrige L1 Schreibrate verbessern. Hoffentlich hat man auch die Leserate noch weiter verbessert, speziell was den L2 betrifft.

2x 4 Ops Dispatch ist etwas seltsam, da auf der Folie zu Steamroller noch was von +25% mehr Bandbreite pro Thread stand. Bisher war es 1x 4 Ops Dispatch. Letztendlich wäre es aber auch nicht wirklich überraschend. Macht auf jeden Fall Sinn aufgrund des angepassten Frontends mit 2 Decoder-Einheiten. +25% ist wohl einfach das, was an Performance rauskommt, unabhängig von den Kapazitäten.

Auch interessant, die Verkürzung der FP Pipeline. Sollte sich grundsätzlich auf alle FP Workloads positiv auswirken mit kürzeren Instruktionslatenzen, geringere Penalty bei Branch Misprediction usw.

 

[Gipsel]

Change from 4 to 3 FP pipe stages.

Auch interessant, die Verkürzung der FP Pipeline. Sollte sich grundsätzlich auf alle FP Workloads positiv auswirken mit kürzeren Instruktionslatenzen, geringere Penalty bei Branch Misprediction usw.

Da wird nur nichts verkürzt. Die floating point Pipelines haben 6 Stages für die Arithmetik und das bleibt ziemlich sicher auch so. Was sich ändert, ist daß die Anzahl der Pipelines von 4 auf 3 reduziert wird. Das zitiert BSN entweder falsch oder es steht falsch im Guide (wäre nicht ungewöhnlich). Bisher gibt es 2 FMA-Pipes und 2 SIMD-ALU-Pipes (Integer, Bitmanipulationen). Mit Steamroller gibt es dann nur noch 2 FMA-Pipes und eine zusätzliche SIMD-Pipeline, vermutlich werden die Instruktionen auch ein wenig umverteilt.

 

[Dresdenboy]

2x 4 Ops Dispatch ist etwas seltsam, da auf der Folie zu Steamroller noch was von +25% mehr Bandbreite pro Thread stand. Bisher war es 1x 4 Ops Dispatch. Letztendlich wäre es aber auch nicht wirklich überraschend. Macht auf jeden Fall Sinn aufgrund des angepassten Frontends mit 2 Decoder-Einheiten. +25% ist wohl einfach das, was an Performance rauskommt, unabhängig von den Kapazitäten.

Das passt zumindest zu Patenten von Sean Lie aus 2008, wo die gleichzeitige Verteilung der Ops an beide Kerne gleichzeitig über die sowieso vorhandenen Pfade beschrieben wurde. Die höhere Bandbreite ergibt sich daraus, dass in dem Takt, wo ein Kern bisher sein Dispatch Packet erhielt, nun auch der zweite Kern ein Packet erhalten kann. Bisher war das nicht möglich. Das war auch für einen Teil des Leistungseinbruchs eines Threads verantwortlich, wenn ein zweiter auf dem Modul lief. Alles andere (dass es keine +100% sind), ergibt sich aus anderen Gegebenheiten (Fetch Buffer, Dekodierbarkeit und Zusammensetzung des Codes).


Die 3xFP-Pipes sind ja schon vorgestellt worden.

 

[gruffi]

Da wird nur nichts verkürzt. Die floating point Pipelines haben 6 Stages für die Arithmetik und das bleibt ziemlich sicher auch so. Was sich ändert, ist daß die Anzahl der Pipelines von 4 auf 3 reduziert wird.

Das hatte ich mir auch schon gedacht, dass sie das eventuell durcheinander gebracht haben, da die zusätzlichen Stufen für FP mehr als nur 4 sein sollten. Zitiert wird aber:

Change from 4 to 3 FP pipe stages.

Zudem wird von verkürzten Befehlsletenzen gesprochen. Das ist erst mal ziemlich eindeutig, dass hier die Pipelinestufen gemeint sind und nicht die Ports der FP-Ausführungseinheit. Ob es stimmt oder nicht, bleibt abzuwarten. Wäre ja nicht der erste Lapsus in AMDs PDFs.


@Dresdenboy

So wie ich AMD verstanden habe, sollen beide Decoder/Dispatcher auch Ops für ein und denselben Thread weiterleiten können. ZB Dispatcher 1 schickt seine Ops an einen Integer Cluster, während Dispatcher 2 seine Ops an die FPU schickt. Würde auf jeden Fall auch die singlethreaded Performance steigern. Vielleicht fliegt dann Vertikales Multithreading generell raus? Halte ich sowieso für keine sonderlich gute Idee bei einem Clusterdesign. Ich meine, momentan lässt das Frontend immer nur einen Thread pro Takt durch. Es gilt aber pro Takt zwei Integer Cluster und eine fette FPU möglichst hoch auszulasten. Das kann eigentlich nur zu einem Unverhältnis führen. Ausser man hat ein sehr breites Frontend. Nur ob das dann sonderlich effizient arbeiten kann, ist fraglich.

 

[Opteron]

Zudem wird von verkürzten Befehlsletenzen gesprochen. Das ist erst mal ziemlich eindeutig, dass hier die Pipelinestufen gemeint sind und nicht die Ports der FP-Ausführungseinheit. Ob es stimmt oder nicht, bleibt abzuwarten. Wäre ja nicht der erste Lapsus in AMDs PDFs.

Mit Sicherheit falsch, denn wie Gipsel schon sagte sinds im Moment 6. Also können sie sich mit 3 statt 4 nicht darauf beziehen. Es sei denn, man rechnet gleich mit 2 Fehlern

So wie ich AMD verstanden habe, sollen beide Decoder/Dispatcher auch Ops für ein und denselben Thread weiterleiten können. ZB Dispatcher 1 schickt seine Ops an einen Integer Cluster, während Dispatcher 2 seine Ops an die FPU schickt.

Das ist alles ein bisschen komisch. Explizit steht da nur was von den INT-Clustern:

- Increase dispatch bandwidth to 8 INT ops per cycle (4 to each core), from 4 INT ops per cycle (4 to just 1 core). 4 ops per cycle per core remains unchanged.

Wobei ich das Fette nicht ganz kapier, bisher warens doch nur 4 OPs alle 2 Cycle pro Core, oder nicht
Hmm, oder bezogen sie sich damit halt nur auf die Bandbreite? Das wäre dann aber doppelt gemoppelt, steht ja schon davor, dass es 4 sind, wozu die Wiederholung?
Naja .. halt ein AMD PDF *G*

Ansonsten:

- Dispatch and retire up to 2 stores per cycle

Wozu könnte man das brauchen? Können da soviele Stores anfallen? Bin mal gespannt, wie der L2 das abpuffern soll, mit den Write-Through L1 ist der ja auch gut beschäftigt.

Increased L2 BTB size from 5K to 10K and from 8 to 16 banks.

Wow ... Das hört sich nach viel-hilft-viel an .. glatte Verdopplung.

- Increase PFB from 8 to 16 entries; the 8 additional entries can be used either for prefetch or as a loop buffer.

Wieso ist der Loop-Buffer im Prefetch Buffer eingebaut? Prefetch bezieht sich doch auf Daten, und zumindest Intels Loop-Buffer bezog sich doch auf Instruktionen, oder nicht?

Würde es Sinn machen Instruktionen in nem Daten-Prefetch-Buffer abzulegen? Oder ist das eher ne Art L0D-Cache für 8 Einträge?

- Increase snoop tag throughput.

Klingt nach optimierter Core<>Core-Kommunikation, da haperte es bisher ja auch (sagten zumindest einmal die Schachprogrammierer im realworldtech Forum).

- Store queue (STQ) size increased to 32, from 24.

Neben den 2 Stores pro Takt also auch noch 30% größere Puffer. Die Stores müssen bisher ziemlich sch...lecht gewesen sein, dass AMD da jetzt so dick nachbessert.

- Improved memfile, from last 3 stores to last 8 stores, and allow tracking of dependent stack operations.

Weiss einer was das ist? Ist das der Minicache, der die letzten Stores für abermalige,sofortige Loads vorhält und den Write-Through-Nachteil etwas kaschiert?

 

[Gipsel]

Zitiert wird aber:

Zudem wird von verkürzten Befehlsletenzen gesprochen. Das ist erst mal ziemlich eindeutig, dass hier die Pipelinestufen gemeint sind und nicht die Ports der FP-Ausführungseinheit.

Nun, Du mußt aufpassen, was Zitat ist und was Schlußfolgerung von BSN. Wir sind uns ja einig, daß das mit den Latenzen nicht stimmen kann und die Pipeline-Anzahl meint (entweder falsch zitiert oder es steht falsch drin). Dann kannst Du aber nicht die aufgrund einer falschen Voraussetzung gezogene Schlußfolgerung (die dann notgedrungen ebenfalls falsch sein muß) der niedrigen Latenzen heranziehen, um zu vermuten, daß die Anzahl der Pipeline-Stages vielleicht doch gesunken ist. Das wäre ein logischer Fehler. Der BSN-Fritze hat da schlicht nicht aufgepaßt.

 

[Opteron]

P.S: Sind wir uns einige das der letzte Absatz zu torrenza bei BSN Bockmist ist?
Das hat doch nichts mit PCIe End-point Device zu tun ... torrenza war doch alles @Hypertransport und gemeinsamen Adressraum, wenn man will sozusagen ein HSA-Vorreiter

 

[Gipsel]

Das ist alles ein bisschen komisch. Explizit steht da nur was von den INT-Clustern:

Weil vermutlich die FPU nicht mit 8 auf einmal klarkommt. Wenn also beide Decoderblöcke nur FP-µOps ausspucken, müssen sich die etwas einbremsen, um z.B. die (mal ins Blaue getippt) Summe von 4 FP-Ops/Takt nicht zu überschreiten.

Wobei ich das Fette nicht ganz kapier, bisher warens doch nur 4 OPs alle 2 Cycle pro Core, oder nicht

Ja, aber in diesem zweiten Takt sind es dann 4 Ops/Takt.

Wieso ist der Loop-Buffer im Prefetch Buffer eingebaut? Prefetch bezieht sich doch auf Daten, und zumindest Intels Loop-Buffer bezog sich doch auf Instruktionen, oder nicht?

Na die Decoder bzw. der L1-I (pre-)fetchen doch auch. Wenn ein kleiner Loop da vollständig reinpaßt, muß man nicht ständig aus dem L1-I$ fetchen => spart Strom. Aber wer weiß, ob das gemeint ist. Hätte eher daran gedacht, daß dafür der pro Kern/Thread 256 Byte große InstructionByteBuffer herhält.

Weiss einer was das ist? Ist das der Minicache, der die letzten Stores für abermalige,sofortige Loads vorhält und den Write-Through-Nachteil etwas kaschiert?

Wenn ich raten müßte, würde ich auf irgendwas mit der Sideband Stack-Engine tippen. Aber ehrlich gesagt: k.A.

 

[Dresdenboy]

@Dresdenboy

So wie ich AMD verstanden habe, sollen beide Decoder/Dispatcher auch Ops für ein und denselben Thread weiterleiten können. ZB Dispatcher 1 schickt seine Ops an einen Integer Cluster, während Dispatcher 2 seine Ops an die FPU schickt. Würde auf jeden Fall auch die singlethreaded Performance steigern. Vielleicht fliegt dann Vertikales Multithreading generell raus? Halte ich sowieso für keine sonderlich gute Idee bei einem Clusterdesign. Ich meine, momentan lässt das Frontend immer nur einen Thread pro Takt durch. Es gilt aber pro Takt zwei Integer Cluster und eine fette FPU möglichst hoch auszulasten. Das kann eigentlich nur zu einem Unverhältnis führen. Ausser man hat ein sehr breites Frontend. Nur ob das dann sonderlich effizient arbeiten kann, ist fraglich.

Das Patent dazu ist dies hier:
http://www.strutpatent.com/patent/0...llel-dispatch-and-method-thereof#!prettyPhoto
Dort kann man in den Drawings (spez. Fig. 5) den Ablauf sehen.

Wobei ich das Fette nicht ganz kapier, bisher warens doch nur 4 OPs alle 2 Cycle pro Core, oder nicht

Wahrscheinlich im Durchschnittsfall. Wenn nur 1 Thread liefe, ginge ja auch jeden Zyklus ein Paket.

Wozu könnte man das brauchen? Können da soviele Stores anfallen? Bin mal gespannt, wie der L2 das abpuffern soll, mit den Write-Through L1 ist der ja auch gut beschäftigt.

Möglicherweise war das ein künstliches Bottleneck. Wenn pro Dispatch-Paket nur 1 Store möglich war, und 2 oder 3 Stores am Stück folgten, mussten zwangsweise 3 Dispatch-Pakete gebaut werden, selbst, wenn es außer den Stores keine Befehle gab. Und für 3 Zyklen könnte der Dispatcher nicht viel für Thread 2 tun.

Weiss einer was das ist? Ist das der Minicache, der die letzten Stores für abermalige,sofortige Loads vorhält und den Write-Through-Nachteil etwas kaschiert?

Meinst du im WCC?

 

[Opteron]

Ja, aber in diesem zweiten Takt sind es dann 4 Ops/Takt.

Aber nicht pro Core ...

Na die Decoder bzw. der L1-I (pre-)fetchen doch auch. Wenn ein kleiner Loop da vollständig reinpaßt, muß man nicht ständig aus dem L1-I$ fetchen => spart Strom. Aber wer weiß, ob das gemeint ist. Hätte eher daran gedacht, daß dafür der pro Kern/Thread 256 Byte große InstructionByteBuffer herhält.

HMm ok, die Instruktionsprefetcher sind mir noch nicht so aufgefallen, aber wieso nicht. Ich mal nochmal bei Jaguar geschaut, der hat 4x32 Byte:

Und dort steht dabei, dass der Puffer im L1I-Cache ist. Sollte dann beim Steamroller wohl ähnlich sein, AMD wird kaum das Rad 2x erfinden. Auf jeden Fall weisst es darauf hin, dass es kein µOp Puffer wird, sondern "nur" ein x86-Op-Puffer. Schade, aber besser als nichts und Steamroller bekommt immerhin 8 Einträge, also vermutlich 256 Byte. Weiss noch jemand wie groß das Ding beim Core2 war? (Und ich seh gerade, dass da ja auch was von einem IC-Prefetcher steht). Also wirds dann schon so sein.

Edit: Selbst gegoogelt, Agner Fog nennt für den Core2 4x16Byte = 64 Byte für den Loop Cache. Wäre dann bei AMD doppelt oder gar vierfach soviel (bei 1 Thread pro Modul, falls AMD das nicht fest partioniert hat). Hmm .. apropos .. das ist wohl der Nachteil dieser Anordnung ... der LoopCache muss für beide Threads herhalten ( Wobei ich mir jetzt nicht ganz sicher bin, waren die Queues im Front-End nicht immer doppelt für jeden Thread extra angelegt? Glaube mich dunkel zu erinnern ^^) Wie auch immer, danach warten dann dicke Decoder auf die Ops, aber die brauchen ja wieder extra Strom. Aber naja, wie gesagt, ganz sicher besser als nichts, und wenigstens etwas größer als Intel damals Intel gab für die 4x16 Byte ein Äquivalent von 18 x86 Ops an. Das wären dann also ~36 im AMD-Fall, eventuell gar 72 im singlethread- oder extra-Queue-Fall. Klingt doch schon mal ganz ordentlich.
(Nebenbei bemerkt könnte sich dann AVX-Codieren wegen des kürzeren (platz-sparenden) VEX-Präfixe lohnen - zumindest falls man ne Schleife nahe am Limit hat).

Wahrscheinlich im Durchschnittsfall. Wenn nur 1 Thread liefe, ginge ja auch jeden Zyklus ein Paket.

Hm ok, das würde dann noch einigermaßen Sinn machen.

Möglicherweise war das ein künstliches Bottleneck. Wenn pro Dispatch-Paket nur 1 Store möglich war, und 2 oder 3 Stores am Stück folgten, mussten zwangsweise 3 Dispatch-Pakete gebaut werden, selbst, wenn es außer den Stores keine Befehle gab. Und für 3 Zyklen könnte der Dispatcher nicht viel für Thread 2 tun.

Ach Du denkst anders herum, Platz in den Dispatch-Paketen ... möglich, aber da hieß es doch immer, dass es pro Store im Schnitt 2 Loads gäbe, zumindest für nen 2. Store wäre also automatisch Platz gewesen.

Meinst du im WCC?

Ja irgendwo da drumherum, da stand mal irgendwo was in nem PDF oder Artikel, eventuell sogar in der Store Queue.