Kaveri - der Trinity Nachfolger

[Gipsel]

Aber nicht pro Core ...

Na klar pro Core. Bei BD kann ein Kern vier µOps in einem Rutsch (in einem Takt) erhalten.

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.

Laut dem Software Optimization Guide gibt es bereits jetzt einen sogenannen Instruction Byte Buffer (der bei Jaguar offenbar nur noch Instruction Buffer heißt). AMD behauptet, daß der pro Thread 16 Einträge von jeweils 16 Byte großen Windows enthalten kann, also 256 Byte pro Core oder 512Byte insgesamt. Damit werden offenbar L1-I Cache-Misses (die vermutlich den L1-I-Prefetcher triggern) abgefedert bzw. Fetch und Decode entkoppelt. Die Erweiterung zu einem Loop-Buffer sollte eigentlich ziemlich straightforward sein. Aber eventuell kann nur die Hälfte des IB/PFB (der jetzt 32Byte Windows bekommt?) als Loop Buffer benutzt werden, keine Ahnung.

 

[gruffi]

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.

Das ist aber nicht das, was ich meine. Dort reden sie von einem gemeinsamen Frontend, das die Instruktionen eines Threads an beide Integer Cluster schicken kann. Also eher das berühmt berüchtigte Anti-Hyperthreading oder konkreter, SpMT.

 

[Gipsel]

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.

Dazu nochmal Genaueres. Bisher sieht es so aus:

Mit Steamroller dann so:

Pipe 0 (FMA0)​

|

Pipe 1 (FMA1)​

|

Pipe 2 (FSTORE)​

FPFMA (fmul, fadd, fmac) | FPFMA (fmul, fadd, fmac) | FPSTO (fpstore)
FPMAL (MMX/AVX/SIMD ALU [adds, bitops, cmps] | FPXBR (shuffles?, packs, permutes) | FPMAL (MMX/AVX/SIMD ALU [adds, bitops, cmps])
FPCVT (fconverts) | | FPSHUF (shuffles, packs?, permutes?)
FPMMA (MMX/AVX/SIMD INT multiplier) | |

Die einsame SIMD-ALU Einheit in Pipe2 wird in die Pipe0 integriert und die Store-Pipe bekommt eine zusätzliche Shuffle-Einheit, was immer die dann genau macht (eventuell, wird die bisherige XBR-Einheit aufgeteilt und kann in Steamroller keine shuffles mehr).

 

[Dresdenboy]

Das ist aber nicht das, was ich meine. Dort reden sie von einem gemeinsamen Frontend, das die Instruktionen eines Threads an beide Integer Cluster schicken kann. Also eher das berühmt berüchtigte Anti-Hyperthreading oder konkreter, SpMT.

Auch, aber die Dispatcher-Anbindung wird in weiteren Patenten von Sean Lie gezeigt, auch zum Zwecke des schnelleren Transfers von Dispatch Packets. Begründung: Die Leitungen sind sowieso da.

 

[Opteron]

Na klar pro Core. Bei BD kann ein Kern vier µOps in einem Rutsch (in einem Takt) erhalten.
Laut dem Software Optimization Guide gibt es bereits jetzt einen sogenannen Instruction Byte Buffer (der bei Jaguar offenbar nur noch Instruction Buffer heißt). AMD behauptet, daß der pro Thread 16 Einträge von jeweils 16 Byte großen Windows enthalten kann, also 256 Byte pro Core oder 512Byte insgesamt. Damit werden offenbar L1-I Cache-Misses (die vermutlich den L1-I-Prefetcher triggern) abgefedert bzw. Fetch und Decode entkoppelt. Die Erweiterung zu einem Loop-Buffer sollte eigentlich ziemlich straightforward sein. Aber eventuell kann nur die Hälfte des IB/PFB (der jetzt 32Byte Windows bekommt?) als Loop Buffer benutzt werden, keine Ahnung.

Ja genau der IBB war das. Also für 2 Threads - gut Aber so ganz sicher bin ich mir noch nicht, wieso schreibt BSN was von nem "PFB" und schreibt nicht IBB?

Naja nehmen wir mal an, es ist der IBB: Dann muss das so ausgesehen haben:

BDv1: 16x16byte je Threads
BDv2: 8x32byte je Threads // da der PFB bei BDv3 auf 16 erhöht wurde, müssen es bei BDv2 also 8 gewesen sein, würde auch dazu passen, dass die Einträge auf 32byte vergrößert wurden. Entweder das oder PFB != IBB
BDv3: 16x32byte je Threads // davon 8 als Loop-Cache

Ergo: 8x32 byte Loop-Cache pro Thread = 256 Byte = 72 Instruktionen (nach alter Intel Rechnung, 4x soviel wie Core2 (4x16 kByte))

Ich würde mal sagen, dass wir da zufrieden sein sollten, oder?

Edit:
Wie verträgt sich das eigentlich mit den Puffern nach dem Decoder? Die gibts ja auch:

Although AMD doesn’t like to call it a cache, Steamroller now features a decoded micro-op queue. As x86 instructions are decoded into micro-ops, the address and decoded op are both stored in this queue. Should a fetch come in for an address that appears in the queue, Steamroller’s front end will power down the decode hardware and simply service the fetch request out of the micro-op queue. This is similar in nature to Sandy Bridge’s decoded uop cache, however it is likely smaller. AMD wasn’t willing to disclose how many micro-ops could fit in the queue, other than to say that it’s big enough to get a decent hit rate.

www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture

Wieso macht man den Loop-Cache nicht dort?

Wobei ich mich auch frage, was da so neu sein soll, dass sind die die Dispatch-Puffer, die die Anandleute meinen, oder nicht?

After examining the instruction window, the decoders translate each x86 instruction into 1 or 2 macro-operations and place them into a queue for dispatching.

http://www.realworldtech.com/bulldozer/5/

P.S: Googlesuche nach PFB bringt abgesehen von unserem Thread hier (und ähnlich) nichts verwertbares. Ist dann wohl ne BSN-eigene Abkürzung. Sowas nervt einfach nur, goldene NDA-PDFs in Amateurhänden ^^

 

[tex_]

Edit:
Wie verträgt sich das eigentlich mit den Puffern nach dem Decoder? Die gibts ja auch:
www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture

Wieso macht man den Loop-Cache nicht dort?

Wobei ich mich auch frage, was da so neu sein soll, dass sind die die Dispatch-Puffer, die die Anandleute meinen, oder nicht?
http://www.realworldtech.com/bulldozer/5/

Vielleicht, ist jetzt neu, dass auch die Adressen mit gespeichert werden, so dass man abfragen kann, ob eine Instruktion schon mal dekodiert wurde (war vlt. vorher nur ein FIFO?). Den Loop-Cache vor die Decoder zu verlegen macht man unter Umständen weil er dort nicht so groß sein muss wie wenn er hinter ihnen wäre und wenn die Instruktionen dann in dem OP-Buffer hinter dem Decoder liegen müssten diese ja trotzdem nicht nochmal dekodiert werden.
Ist jetzt aber reine Spekulation meinerseits.

 

[Alter Sack]

Sorry, ich bin neu hier und habe bisher nur öfters mitgelesen.
Mit meinem Wissen ist´s auch nicht weit her.
Allerdings brennen mir einige Fragen unter den Nägeln.

- Wäre Stacked Memory auf dem APU-Gehäuse eine Möglichkeit? Normalen DDR3 -oder DDR4 Speicher könnte man für den Desktop ja sozusagen als L2-Ram anbinden.

- Warum hält AMD an diesem komplizierten Cache-Design fest und kopiert nicht das Intel-System? Hat das lizenzrechtliche Gründe?

- Weshalb kann ein Modul nicht als 1 Kern arbeiten? Dadurch würde die Single-Thread Schwäche behoben (mit Ausnahme der FP-Leistung).

- Warum ist tut sich bei den Cache-Latenzen nichts?

- Weshalb geht man nicht vom derart hochfrequenten Design ab, wo man doch mit GF und vorher der eigenen Fertigung, traditionell eine Schwachstelle hat?

VG

 

[amdfanuwe]

@Alter Sack
Hab nur was grundsätzliches dazu zu sagen:
Man sollte immer bedenken, dass die Entwicklung eines Designs mehrere Jahre dauert. Als die Grundlagen zu BD gelegt wurden, ging man wohl davon aus, dass die Prozesstechnik entsprechende fortschritte macht: Schneller, weniger Verbrauch, höhere Transistordichte etc. Mit der Kriese 2009 traten verzögerungen bei den Fertigern ein. 32 nm gab es Probleme, 28nm läßt auf sich warten... Denke mal, ursprünglich hatte man schon mit höheren Frequenzen und geringeren Verbrauch bei BD gerechnet und PD schon für 22nm geplant.
Zudem kann man allgemein sagen, dass sich Logik schnell mit vielen Transistoren lösen läßt oder eben mit weniger Transistoren und dafür aber mehr Takte benötigt. Viele Transistoren erhöhen den Verbrauch, mehr Takt macht es langsamer. Es ist immer ein Abwägen, wo man die Prioritäten setzt.
Ebenso muß abgewogen werden, wo man Arbeitszeit investiert. Dazu muß man erst genau wissen, wieviel Mehrleistung eine Überarbeitung bringt und welche Nachteile die Überarbeitung dann hat. Es ist immer ein Abwägen. Daher, bei Fragen wie: Warum macht man jenes oder solches nicht: Die Probleme sind anderweitig größer bzw. andere Baustellen bringen mehr Performance als das angesprochene Problem.
Wieso kopiert man nicht...: Selbst wenn man die Patente nutzen darf, steht in den Patenten kein genauer Schaltplan. Da ist dann noch einiges reinzustecken, bis es so läuft, wie bei dem Original.
Dann noch generell zu Ingenieuren: Wenns nach denen geht, kommt ein Produkt erst auf den Markt, wenn es perfekt ist, also nie. Irgendwann wird für ein Projekt die Deadline gesetzt und wenn dann das neue nicht richtig funktioniert, wird das alte Bewärte verbaut und das neue kommt vielleicht in die nächste Revision.
Da wir nie erfahren, wieso der Projektleiter entsprechend entschieden hat und wie die aktuelle Prioritätenliste aussieht, können wir nur spekulieren und uns Aufregen über ( vermeintliche ) Fehlentscheidungen.

 

[gruffi]

@Alter Sack

Stacked Memory wird früher oder später sicherlich kommen. Die Frage ist nur wann. Mit Kaveri wahrscheinlich noch nicht.

Welches komplizierte Cache-Design? Intels Cache-Design ist doch komplizierter aufgrund der 3 Level. Macht bei AMD Null Sinn. Mit 256 KB L2 kommst du nicht weit.

Die Frage ergibt keinen Sinn. Du meinst vielleicht, warum kann ein Modul nicht alle seine Ressourcen einem Thread zur Verfügung stellen? Nun, theoretisch könnte es das. Die Frage ist nur, macht das Sinn? Geteilte Ressourcen erhöhen die Komplexität und können sich ab einem gewissen Punkt negativ auswirken. Bulldozer versucht deshalb den besten Mittelweg aus dedizierten und geteilten Einheiten pro Thread zu gehen. Das ist auch nicht die Problematik der singlethreaded Performance. Bulldozer ist 4-fach OoO und kann theoretisch 8 Ops pro Takt verarbeiten. Das ist ausreichend für gute singlethreaded Performance. Die Baustellen liegen eher an anderer Stelle.

Was meinst du? Sind denn schon Cache-Latenzen von Kaveri bekannt? Wäre mir neu.

Bulldozer ist kein Hochfrequenzdesign. Bitte nicht von dem immer mal wieder kolportierten Irrglauben verunsichern lassen. Bulldozer besitzt lediglich eine 20-30% besser taktbare Pipeline als K10. Und das war mMn auch die richtige Designentscheidung. Ich denke, AMD wird zukünftig weniger Taktprobleme als Intel bekommen. Vielleicht erinnert man sich noch an den Ur-K10 und wohin das führen kann.

 

[BavarianRealist]

Sehe ich mir die angeblichen Benches zur Grafik-Performance von Kabini/Temash an, dann dürfte das GDDR5-Interface für Kaveri eine logische Schlussfolgerung sein. Wenn die kleinen APUs schon mit einer so hohen GPU-Leistung aufwarten, dann könnte hier Kaveri eine neue Dimension werden. Notebooks mit Kaveri brauchen dann womöglich überhaupt keine Grakas mehr. Das spart den OEMs wieder viel Geld, weil man auf diese Komplexität komplett verzichten kann.

Es gefällt mir mehr und mehr, dass AMD sich endlich auf seine Stärken konzentriert und diese versucht in den Produkten umzusetzen. Womöglich stehen morgen AMD-CPUs/APUs in den Systemen für hohe Gaming-Performance. AMD muss das in allen seine Produkten nutzen
.
EDIT :
.
GDDR5 gibt es bereits am Markt als auch den Kontroller baut AMD längst für die Grakas. Gleichzeitig dürfte der Kontroller ähnlich den Grakas auch das "normale" DDR3-Interface bieten. Und da wäre es ja nur logisch, dass man auch DDR4 unterstützt, damit es genutzt werden kann, sobald es auf den Markt kommt. Weil aber DDR4 noch nicht da ist, setzt man wohl auf GDDR5. Flexibiliät ist hier Trumpf.

 

[Alter Sack]

Erstmal danke ich Euch für die Antworten.

@ gruffi

Naja ich dachte, dass das teilweise inclusive design vllt. komplizierter ist,
als ein vollständig inklusives Design.
Aber auf Kaveri trifft das wohl eh nicht zu, wegen des fehlenden L3.

O.K. bei der Single-Thread- Performance lag ich wohl komplett daneben.

Bei den Latenzen ändert sich wohl laut den Gerüchten nichts.
Zumindest wurde nichts erwähnt, soweit ich das mitbekommen habe.

Hoffen wir das Beste.

VG

 

[gruffi]

Naja ich dachte, dass das teilweise inclusive design vllt. komplizierter ist,
als ein vollständig inklusives Design.

Was heisst teilweise? Die Bobcat Architektur ab Kabini/Temash und die Bulldozer Architektur ab Trinity ist vollständig inklusive. Teilweise inklusive gibt's nur noch beim Serverdesign Orochi.

Bei den Latenzen ändert sich wohl laut den Gerüchten nichts.

Dann bringe mal eine Quelle für diese Gerüchte. Bisher ist mir nichts zu Latenzen bekannt.

 

[Opteron]

Dann bringe mal eine Quelle für diese Gerüchte. Bisher ist mir nichts zu Latenzen bekannt.

Stand auf Anandtech im Steamrollerartikel und bezog sich auf den L3 Cache. Die Gründe wären bekannt,aber AMD würde nichts daran ändern. Wundert auch nicht, der Grund ist der niedrige Takt, Intel hatte beim Nehalem in ner offiziellen Folie auch 52 Takte für ihren damaligen L3@2.133 MHz angegeben. Stromverbrauchsmäßig kann sich es intel nun seit Sandy leisten den Takt voll laufen zu lassen, AMD aber nicht, vielleicht ja bei 20nm.

Aber wie schon öfters geschrieben ist es bei AMD fast egal, sie haben ja 2MB L2, nicht 256kB. Da ist der L3 nicht so wichtig und die 20Takte für den L2 sind noch ok.

Einziger Kritikpunkt meinerseits bleiben die TLBs, da sollten sie noch ne zusätzliche Schippe nachlegen. 96 ist doch ne schöne Zahl

 

[gruffi]

Stand auf Anandtech im Steamrollerartikel und bezog sich auf den L3 Cache.

Naja, das ist ja hier im Thread nicht wirklich von Belang. Das kann man gerne beim Orochi Nachfolger diskutieren. Hier interessiert uns nur L2. Wobei selbst die L2 Latenz nicht so kritisch ist, weil mit den Daten 2 Threads gefüttert werden. Bei Intel ist es eben nur einer.

Stromverbrauchsmäßig kann sich es intel nun seit Sandy leisten den Takt voll laufen zu lassen.

War SB nicht eher eine Ausnahme? Ich dachte, bei IB ist der L3-Takt wieder entkoppelt.

 

[Opteron]

Naja, das ist ja hier im Thread nicht wirklich von Belang. Das kann man gerne beim Orochi Nachfolger diskutieren. Hier interessiert uns nur L2.

Jo dachte ich mir schon, dass es da eventuell ein Mißverständnis gab, deswegen hab ichs erwähnt.

War SB nicht eher eine Ausnahme? Ich dachte, bei IB ist der L3-Takt wieder entkoppelt.

Ne, der läuft nachwievor mit voellem Coretakt, alles andere wäre stark verwunderlich, schließlich haben sie durch den Shrink auf 22nm noch bessere Stromspareigenschaften.

 

[gruffi]

/offtopic

Ich denke da liegst du falsch. Habe es mir nochmal angeschaut. Der L3 ist tatsächlich ab IB (?) SB-E wieder entkoppelt. Muss also nicht mit Kerntakt laufen, abhängig vom Energiebudget. Mit Haswell geht man sogar wieder BTTR, also mehr wie Nehalem. Mehr dazu hier. Scheinbar steigt die L3 Latenz sogar etwas mit Haswell. Dafür gibt's mehr Durchsatz.

 

[Opteron]

Ich hatte nur geschrieben "voller Coretakt", nicht gleiche Taktdomäne Dass SandyE ne eigenen Taktbereich hat stimmt, aber der läuft halt trotzdem mit vollem Kerntakt, auch wenn er entkoppelt ist
Wie besagt, intel kann es sich leisten ... AMD könnte den L3 Takt technisch gesehen auch anheben, aber das zöge halt zuviel Energie.

Das mit Haswell ist interessant, ist ansonsten halt unpraktisch mit so ner GPU und dem L3-Zugriff ... AMD ist Schuld, die mit ihrer blöden APU-Idee ^^

 

[gruffi]

Von vollem Kerntakt habe ich aber gar nichts geschrieben. Ich fragte lediglich, ob das nicht eher die Ausnahme war und der L3 mittlerweile wieder entkoppelt ist. Und du meintest daraufhin "Ne ...". Eben doch. Nix ne. SB (IB?) scheint lediglich die Ausnahme zu sein. Der L3 wird normalerweise entkoppelt und muss daher nicht mit Kerntakt laufen.

 

[Locuza]

Mal eine Frage an die Experten.
PCIe 2/3 stellt doch den Verbindunsbus zwischen CPU und GPU her, 8/16 GB/s je Richtung. (+ Hohe Latenzen)

Bei Kaveri wurde die Interkommunikation von CPU und GPU doch auf 256-Bit aufgebohrt?
Verwendet wird hier doch auch PCIe, aber wie hoch ist hier die Bandbreite und wie ist die Latenz einzuordnen?
Wegen der lokalen Nähe müsste sie doch deutlich besser sein, bloß kann man irgendwie abschätzen wie deutlich? (Trinity, Llano als Vergleichsmaßstab?)

Anhang anzeigen 27200

Das war beim Llano, also ist die Interkommunikation ~27 GB/s schnell zwischen GPU und CPU, während sie nur ~7 GB/s schafft bei PCIe2.

Edit: Wobei CPU und GPU doch über Onion kommunizieren bzw. den FCL ( Bei 650Mhz 10,4 GB/s je Richtung beim Llano. siehe real tech world)
http://www.realworldtech.com/fusion-llano/2/

Und genau dieser wird bei Kaveri 256-Bit breit sein, im Gegensatz zu den 128-Bit.
Würde in 20,8 GB/s resultieren (Bei 650Mhz)

Okay, die einzige Frage die ich bei dem Wirrwar habe, was wäre bei einer APU das Gegenstück von dem Flaschenhals PCIe3 am PC, welcher für die Kommunikation zwischen CPU und GPU sorgt?

 

[Complicated]

Eine APU hat diesen Flaschenhals eben nicht (in der Endversion), Da es dieses verschieben zwischen CPU und GPU nicht gibt. Es gibt nur noch eine Anbindung direkt an den Speicher. Dort liegen die Daten und müssen nirgendwo hin verschoben werden da sowohl GPU als auch CPU diese Adresse ansprechen können und Daten lesen und schreiben können. Die Frage ist nicht ob man die Datenleitung breiter machen muss, sondern ob man einfach weniger Daten darüber verschicken muss.

HSAfähige GPUs werden auch PCIe als Flaschenhals haben und ansonsten ist die Engstelle eben die Speicheranbindung - daher ist dieser Schritt mit GDDR5 auch nicht so verkehrt.

 

[hot]

Haswell entkoppelt den L3 wieder, nicht Ivy. Beim Ivy ist es AFAIK wie beim Sandy.


Und bei HSA könnte doch die GPU einfach wie eine CPU behandelt werden (außer, dass sie keine ist), also über CPU und GPU wird der gleiche Adressraum gelegt und PCIe dient als so ne Art NUMA-Konfiguration. Damit könnte die CPU den Grafikspeicher nutzen und die Grafikkarte den Hauptspeicher.

 

[Bobo_Oberon]

...
Bei Kaveri wurde die Interkommunikation von CPU und GPU doch auf 256-Bit aufgebohrt?
Verwendet wird hier doch auch PCIe, aber wie hoch ist hier die Bandbreite und wie ist die Latenz einzuordnen?
...

Hatte AMD nicht angedeutet, dass die Inter-Kommunikation bei den neuen APUs zwischen CPU- und GPU-Part eher an HyperTransport angelehnt ist?

Das dürfte die Latenzen zwischen beiden Kernkomponenten nochmals gegenüber PCI-Express verkürzen, also verbessern. Wobei ich anmerken will, dass der Schritt von PCI-Express 2.0 auf die Version 3.0 sicherlich auch die Latenzen verbessert.

MFG Bobo(2013)

 

[Opteron]

@gruffi:
Hast recht, hatte die Frage fälschlicherweise nur auf die taktfrage reduziert, da bei gleichem Takt trotz Entkopplung nicht soviel Leistung verloren geht. Die ~5 Takte würde ich unter den Tisch fallen lassen, aber jetzt ist ja alles klar

Ansonsten, Querposting aus dem Kabini-THread zu den Loop-Puffern. Die sind laut Fam16h PDF im l1-Instruktioncache:

The loop buffer is composed of four32-byte chunks and is essentially a subset of the
instruction cache.

Ist jetzt die Frage, wie das bei Steamroller gelöst ist, ob es da ähnlich gelöst ist. Falls ja frag ich mich, ob es im gemeinsamen Instruktionscache dann 2 Bereich für die Loop-Puffer gibt, oder nur einer. Einer wäre wohl ziemlich doof, denn wie soll man ne Schleife erkennen, wenn andauernd andere Zufallsinstruktions des 2. Threads dazwischenfunken

@Bobo:

Hatte AMD nicht angedeutet, dass die Inter-Kommunikation bei den neuen APUs zwischen CPU- und GPU-Part eher an HyperTransport angelehnt ist?

Hab ich nicht mitbekommen, wo sollte das gewesen sein? Nur die 256bit standen halt bei BSN.
PCIe2 zu 3 brauchte außerdem eher ne Verschlechterung der Latenz, da sie auf 128b/130b Codierung umgestiegen sind. Das heißt, das man erstmal 130bit am Stück übertragen muss, bevor man weiss was drinsteht. War zuvor mit 8/10bit viel besser, aber das brachte halt viel Overhead mit sich. Halt der übliche Kuh-Handel.

Bin mal gespannt, ob es das ominöse Hypertransport 4.0 wirklich gibt, das wäre eventuell doch die beste Lösung.

 

[FredD]

Hatte AMD nicht angedeutet, dass die Inter-Kommunikation bei den neuen APUs zwischen CPU- und GPU-Part eher an HyperTransport angelehnt ist?

Das dürfte die Latenzen zwischen beiden Kernkomponenten nochmals gegenüber PCI-Express verkürzen, also verbessern. Wobei ich anmerken will, dass der Schritt von PCI-Express 2.0 auf die Version 3.0 sicherlich auch die Latenzen verbessert.

MFG Bobo(2013)

Was die Latenzen in den unterschiedlichen Szenarien betrifft, ist HT klar überlegen.
Zumindest nach eigener Methodik, siehe auch S.10 des pdfs http://www.hypertransport.org/docs/wp/Low_Latency_Final.pdf
.
EDIT :
.
Zugegeben, der Vergleich (link) ist total überholt, nachdem beide Protokolle über je 2 Revisionen erfahren haben. Aktuellere Vergleiche konnte ich bisher nicht ausfindig machen.

 

[Stryki]

Man könnte noch die Kosten/Nutzen Frage stellen Hypertransport müsste AMD weiterentwickeln und PciE brauchen Sie auch.
Da stellt sich die Frage nach dem Vorteil gegenüber dem Nutzen.

E: Ich sehe grade an HT entwickeln HP,IBM und andere mit dann stellt sich nur die Frage nach den Aufwand der Implementierung 2 verschiedener Protokolle ob das Design dadurch komplexer wird.