AMD Zen - erste Bilder von Zen

Y

YoWoo

Gast
AMD Zen - erste Bilder von Zen (Nachtrag: Fakeverdacht)

Hier tauchen gerade einige Bilder im Netz auf, mich wundern aber die Anführungsstriche, könnte ein Fake sein. Ich hatte mal gelesen, dass AMD eine Technik aufgekauft hat, die es ermöglicht 4 physikalische Kerne als einen darzustellen, um so höhere Single Thread Performance zu erreichen. Angeblich würde man somit 100%+80%+60%+40% = 280% an theoretischer Leistung erreichen. Ich finde nur den Artikel nicht mehr, in der Folie liest sich das so, kann mich aber auch irren.

Ich schaue mir mal andere Folien an, ich denke das ist ein Fake.

unit.jpg

zen.jpg
 
Zuletzt bearbeitet:
AW: AMD Zen - erste Bilder von Zen (Nachtrag: Fakeverdacht)

Glaube, dass es trotzdem ein Fake ist, da noch keinerlei Informationen über die neue Grafikkarten Serie draußen ist und über die Prozessoren angeblich schon.
 
AW: AMD Zen - erste Bilder von Zen (Nachtrag: Fakeverdacht)

warten wir mal ab, es gibt auch schon vorher leute die sachen gepstet haben, wo letzten endlich auch keiner wusste ob sie stimmen und am ende waren sie richtig
 
Na hoffentlich stehen sich die 4 virtuellen Kerne, die zusammen nach außen einen Kern repräsentieren, in der Zusammenarbeit nicht im Weg... Stichwort: execution stalls.
 
Pry_T800 schrieb:
Allerdings ist der Ansatz, 4 Kerne Virtuell an einem Thread arbeiten zu lassen, recht gut. [...]

Das ist vor allem ineffizient. Nicht nur in Anbetracht der Chipfläche die für vergleichsweise geringere Steigerungen der Performance benötigt wird, sondern auch in Sachen Energieeffizienz. Ein guter Teil der Steigerung besteht bei solchen Konzepten meist daran, Rechenoperationen Spekulativ auszuführen. Entsprechend oft werden aber auch Rechenoperationen umsonst ausgeführt, da sie verworfen werden.
Wobei Spekulative Rechnungen in der CPU Architektur nichts Neues sind.
 
Zuletzt bearbeitet:
Piktogramm schrieb:
Ein guter Teil der Steigerung besteht bei solchen Konzepten meist daran, Rechenoperationen Spekulativ auszuführen.
Ist das ein solches Konzept? Wäre ja ziemlich dämlich.
Sprungvorhersage ist seit den P4 deutlich verbessert worden - und trotzdem werden keine langen Pipelines mehr genutzt.
 
Wie stehen denn bitte die BranchPrediction und die Länge einer Pipeline in Relation zueinander?
 
@ Faust2011

Falsche Vorhersage=komplette gepipelinte Befehle zu verwerfen.
Sämtlicher Aufwand zum Befüllen unnütz gewesen, bei kurzer Pipeline also weniger, als bei langer.
Oder nicht?
 
Zuletzt bearbeitet:
Das ist mir schon klar. Allerdings verstehe ich Deinen Satz nicht... die Effizienz einer Branch Prediction Unit ist die eine Sache, der architekturelle Aufbau einer CPU (Pipeline) eine andere. Dass im Falle einer Mis-Prediction die Pipeline alles (spekulativ ausgeführte) verwerfen muss, ist ebenfalls klar. Vielleicht finde ich das Wörtchen 'trotzdem' in Deinem Satz irreführend.
 
Faust2011 schrieb:
Vielleicht finde ich das Wörtchen 'trotzdem' in Deinem Satz irreführend.
Ich bezog mich auf Piktogramms Aussage, daß ZEN eine "spekulative" Architektur sei - wie lange Pipelines bei späten P4.
Deshalb meine Frage an ihn, ob Bearbeitung eines Threads durch mehrere Kerne wirklich "auf Verdacht" arbeitet.
Ob man die Berechnungsleistung zum Befüllen einer langen Pipeline, oder die spekulativ ausgeführten Berechnungen weiterer Kerne verwerfen muss, kommt doch aufs gleiche raus - oder ist das nicht vergleichbar?
Trotz besserer Sprungvorhersage scheint Erhöhung Transistorbudget für Spekulationssicherheitsabhängige Leistungssteigerung ja mittlerweile Ineffizient zu sein.
 
Zuletzt bearbeitet:
Ich habe nicht behauptet, dass Zen das tun würde, sondern wollte nur die Freude von Pry_T800 etwas dämpfen, was das Nutzen von n Kernen zur Beschleunigung eines einzelnen Threads bewirkt.

Zudem sind die Vorgänge schon etwas anders gelagert. Bei der Sprungvorhersage in "klassischen" CPUs geht es meist eher darum den einzelnen, wahrscheinlichsten Fall schonmal zu berechnen. Bei der spekulativen Ausführung die man mit mehreren CPU Cores machen kann, wird jedoch (unter anderem) einfach mal jede Möglichkeit auf Verdacht berechnet. In der Regel wird eines dieser Ergebnisse brauchbar sein und die anderen werden verworfen. Damit lässt sich durchaus Zeit gewinnen und das Ganze lässt sich sicher auch noch weiter treiben. An der Stelle hört mein Halbwissen aber auch schon auf.
 
Zuletzt bearbeitet:
So ein Ansatz wäre aber kaum praktikabel. Typischer x86-Code besteht zu 20-25% aus Sprüngen, da hat man schnell mehr wahrscheinliche Zweige zusammen als die CPU Kerne hat.
Mir fällt nur ein einziges Szenario ein, wo das funktionieren könnte, nämlich bei Code unmittelbar nach einer Schleife - den könnte man, sofern keine Datenabhängigkeiten bestehen, schonmal ausführen, während ein anderer Kern noch an der Schleife selbst arbeitet. Dürfte nur in der Praxis keine Mehrleistung bringen.
 
Piktogramm schrieb:
Zudem sind die Vorgänge schon etwas anders gelagert. Bei der Sprungvorhersage in "klassischen" CPUs geht es meist eher darum den einzelnen, wahrscheinlichsten Fall schonmal zu berechnen.

Lange Pipeline flushen kostet extrem oft einige wenige Befehle, etwas weniger oft, wenn die Sprungvorhersage taugt.
Erspart bei Erfolg Latenzen bei Zugriffen.

Piktogramm schrieb:
Bei der spekulativen Ausführung die man mit mehreren CPU Cores machen kann, wird jedoch (unter anderem) einfach mal jede Möglichkeit auf Verdacht berechnet.
Berechnet Spekulative Vorausberechnung a la "Zen" auf zusätzlichen Kernen wirklich noch risikoreicher grössere und komplexere Vorhersagen auf weiteren Kernen?

Piktogramm schrieb:
Damit lässt sich durchaus Zeit gewinnen und das Ganze lässt sich sicher auch noch weiter treiben.
Helf' mir auf die Sprünge!
Wie sollte komplexe Vorhersage effizienter sein, als simple?





Ich will nicht "Pry" das Wort reden, sondern wüsste nur gerne, ob mehrere Kerne nicht-spekulativ an einem Thread arbeiten können.






Edit:
VikingGe schrieb:
Mir fällt nur ein einziges Szenario ein, wo das funktionieren könnte, nämlich bei Code unmittelbar nach einer Schleife - den könnte man, sofern keine Datenabhängigkeiten bestehen, schonmal ausführen, während ein anderer Kern noch an der Schleife selbst arbeitet. Dürfte nur in der Praxis keine Mehrleistung bringen.
THX! Sowas wollte ich hören.
 
Zuletzt bearbeitet:
wollte nur die Freude von Pry_T800 etwas dämpfen

Soviel freude war da gar nicht dabei, mein Gedanke war nur, in Szenarien, wo soetwas viel eingesetzt werden könnte, weil die Kerne gerade eh nichts besseres zu haben, könnte es einen Vorteil bringen. Dass das ganze ineffizient sein mag ist mir auch bewusst. Wie gut da die Software dynamisch auf solcher Art von Szenarien reagieren kann, entzieht sich meiner Kenntnis.


Cu der Pry
 
Zurück
Oben