AMD Zen-Prozessoren sollen bis zu 16 Kerne besitzen

[Notoran]

Fdsonne und mrdude. Ein herz und eine Seele. Seit jeher

Gesendet von meinem GT-I9300 mit der Hardwareluxx App

 

[unl34shed]

Verstehe ich das mit dem "In-Order" richtig? Es ist dann bei Multithreaded Anwendungen, für den Programmierer vorhersagbar welche Threads in welcher Reihenfolge ausgeführt werden
?
Ich bin bisher nur wenig mut ultithreading in den Vorlesungen in berührung gekommen,a ber wenn das stimmt.. dann würde das die Entwicklung solche Anwendungen erheblich vereinfachen... wenn AMD dann nichts ähnliches bringt, dann haben wir bald Anwendungen die auf Intels multithreaded laufen und auf AMD (oder älteren Intels) nicht!
Ehrlicdh gesagt würde ich einen Fortschritt dieser Art als Entwickler definitiv begrüßen.

Das hat nichts mit Multithreading zu tun.

In-Order (Execution) bedeutet, die Befehle werden genau in der Reihenfolge abgearbeitet, in der sie im Programmcode stehen. Das heißt, dass zB. bei einem Load die Pipeline je nach Ladezeit leerlaufen kann.

Dem entgegen wirkt Out-of-Order Execution, wo einzelne Befehle auch früher ausgeführt werden können, als sie im Programmcode stehen. zB. Bei einem Load wird die Pipeline mit den nächsten Arithmetischen Operationen gefüllt (vorausgesetzt natürlich sie beziehen sich nicht auf den neu geladenen Wert). Das ganze ist auch bei superscalaren Prozessoren von Vorteil, weil nicht jede Pipeline alle Befehle ausführen kann bekommt man eine bessere Auslastung. Der Nachteil von Oout-of-Order ist aber der etwas höhere Stromverbrauch und die Logik, die man dafür benötigt. Die höhere Performance spricht aber dafür, deswegen wird es seit Jahren bei x86 CPUs eingesetzt.

 

[Unrockstar]

Thema Modularität. Sollte AMD es schaffen VISC Rechtzeitig Marktreif zu bekommen, bräuchte man eine große ST Performance garnicht, da man mehrere Kerne zu einem Thread nutzen kann. AMD Steckt da derzeit echt viel Geld hinein:

VISC CPU ‘virtual core’ design emerges: Could this be the conceptual computing breakthrough we’ve been waiting for? | ExtremeTech

Gab aber auch mal einen Thread hierzu von mir

 

[mr.dude]

Verstehe ich das mit dem "In-Order" richtig? Es ist dann bei Multithreaded Anwendungen, für den Programmierer vorhersagbar welche Threads in welcher Reihenfolge ausgeführt werden
?

Nein. unl34shed hat es ja schon erklärt. In-Order und OoO (Out of Order) beziehen sich auf die Verarbeitung eines Befehlsstroms (Thread). Bei In-Order werden alle Instruktionen stur nacheinander abgearbeitet. Wenn zwei aufeinander folgende Instruktionen voneinander abhängig sind, dann muss die Verarbeitung der zweiten Instruktion eben solange warten, bis die erste Instruktion fertig verarbeitet wurde. Mechanismen für ILP (Instruction Level Parallelism) können dann nicht mehr greifen. Anders schaut das bei OoO aus. Hier können Instruktionen in beliebiger Reihenfolge ausgeführt werden, um Abhängigkeiten zu umgehen und so mehrere Instruktionen parallel auszuführen, um pro Takt eine höhere Performance zu erzielen. Voraussetzung dafür ist natürlich, dass Ergebnisse durch eine Neuordnung der Instruktionen nicht verfälscht werden. In-Order hat den Vorteil, dass der Platz- und Energiebedarf relativ gering ist, weil man sich einiges an Verarbeitungslogik sparen kann. Der Nachteil ist, dass die Performance deutlich geringer als bei OoO ausfällt. Bei Multithreading spielt das dann allerdings weniger eine Rolle. Hier kann ein Cluster aus In-Order Kernen bei gleichem Durchsatz effizienter sein als ein Cluster aus OoO Kernen. Und das versucht sich auch MorphCore zu Nutze zu machen.

Ein Programmierer muss gar nicht wissen, in welcher Reihenfolge Threads ausgeführt werden. Was soll ihm das bringen? Mit dedizierten Hardwarethreads werden Softwarethreads sowieso parallel ausgeführt. Gängige Betriebssysteme greifen zwar nach wie vor auf Slicing zurück, wo es dann tatsächliche eine zeitliche Reihenfolge gibt, typischerweise in Intervallen von wenigen Millisekunden. Aber das erledigt der Thread-Scheduler des Betriebssystems, transparent für den Programmierer.

Thema Modularität. Sollte AMD es schaffen VISC Rechtzeitig Marktreif zu bekommen, bräuchte man eine große ST Performance garnicht, da man mehrere Kerne zu einem Thread nutzen kann. AMD Steckt da derzeit echt viel Geld hinein:

VISC CPU ‘virtual core’ design emerges: Could this be the conceptual computing breakthrough we’ve been waiting for? | ExtremeTech

VISC geht allerdings den umgekehrten Weg wie MorphCore und ist nochmal eine ganze Ecke radikaler.

 

[DragonTear]

Ahh, danke, ihr beiden! Hätte mich genauer einlesen sollen auf was sich das bezieht.. zur MorphCore hatte ich nur ziemlich undurchsichtige Erklärungen gefunden.

Ein Programmierer muss gar nicht wissen, in welcher Reihenfolge Threads ausgeführt werden. Was soll ihm das bringen? Mit dedizierten Hardwarethreads werden Softwarethreads sowieso parallel ausgeführt. Gängige Betriebssysteme greifen zwar nach wie vor auf Slicing zurück, wo es dann tatsächliche eine zeitliche Reihenfolge gibt, typischerweise in Intervallen von wenigen Millisekunden. Aber das erledigt der Thread-Scheduler des Betriebssystems, transparent für den Programmierer.

Naja, mit meiner Vermutung über in-Order meinte ich eben die Threads, dass deren Ausführungsreihenfolge vorhersagbar sei.
Dass der Thread-Sheduler transparent arbeitet würde ich eher nicht sagen. Wenn ich 2 Threads starte, dann kann ich nicht wissen welcher zuerst ausgeführt wird und ob diese Reihenfolge auch immer eingehalten wird.
Ich muss "per Hand" (oder mittels einer (meist höhren) Programmiersprache halb-automatisch) dafür sorgen dass z.B. die Threads nicht versuchen gleichzeitig die selbe Speicherzelle zu beschreiben oder das Programm mit veralteten Daten arbeitet weil der Windows-sheduler zufällig grade dann meinen Thread pausiert hat, nachdem ich eine Abfrage durchgeführt habe und sich dann die Bedingung in der Zwischenzeit durch den anderen Thread ändert. Selbst wenn man seine Threads dann synchronisiert hat, muss man auch noch aufpassen dass es zu keinen "Deadlocks" kommen kann usw.

 

[Holt]

Sollte AMD es schaffen VISC Rechtzeitig Marktreif zu bekommen, bräuchte man eine große ST Performance garnicht, da man mehrere Kerne zu einem Thread nutzen kann.

Wobei das immer von der jeweiligen Aufgabe und den Abhängigkeiten der Berechnungen untereinander abhängt. Wobei das VISC Konzept ja auch noch die Ausführung von x86 und ARM Code beinhaltet, aber lassen wir das mal weg, das wird auch nur in besonderen Fällen relevant werden, tut zum Thema Singlethread Performance nichts zur Sache und normale PCs können bisher ja nur x86 Code ausführen und werden daher nur damit gefüttert.

Anders schaut das bei OoO aus. Hier können Instruktionen in beliebiger Reihenfolge ausgeführt werden, um Abhängigkeiten zu umgehen und so mehrere Instruktionen parallel auszuführen, um pro Takt eine höhere Performance zu erzielen.

Nein, nicht parallel, das wäre ja gerade VISC , das ist gewissermassen OoO in Parallel. OoO ordent nur die Reihenfolge um, damit Befehl zuerst verarbeitet werden für die die Daten schon bereitstehen, während andere für die die nötige Daten erst noch geladen werden müssen und somit später zur Verfügung stehen werden, dann eben erst später ausgeführt werden.

Ein Beispiel: Man rechnet (A + B) / (C * D)
A steht nur im RAM, B, C und D im Cache und im Programm wird erst A + B gerechnet. Dann müsste man bei In-Order CPUs ersten bis A geladen wurde und dann kann erst C * D gerechnet werden und dann wird als letzte Rechung die Division ausgeführt. Bei OoO kann die Berechnung von C * D vorgezogen werden und damit müssen nach dem Eintreffen von A nur noch 2 statt 3 Opteration ausgeführt weren, weil in der sonst ungenutzten Wartezeit ausgeführt wurde.

VISC würde jetzt hier auch nichts bringen, aber wenn alle vier Werte im Cache stehen, dann ist es ein Unterschied. OoO würde nichts bringen, wenn es dann keine (unterschiedlichen) Wartezeiten für das Laden der Werte gibt, aber mit VISC würde ein Kern A + B berechnen und der andere wirklich parallel dazu C * D, danach dann führt dann noch eine Kern die Division aus und das Ergebis liegt eben füher vor, was mit IPC bedeutet.

Das Limit von VISC ist aber, dass eben die Division nicht parallel erfolgen kann, denn sie hängt von dem Ergebnis der Addition und dem der Multiplikation ab, diese müssen also ausgeführt worden sein, bevor die Division erfolgen kann. Und wie viel VISC bringt hängt dann auch sehr davon ab, wie schnell die Daten zwischen den Kernen ausgetauscht werden können, denn einer der Zwischenergebnisse muss ja von dem einen Kern zum anderen kommen, so ganz einfach ist es also auch nicht und wenn dabei in der Praxis mehr Zeit draufgeht als die eine zweitere Berechung auf dem Kern gekostet hätte, geht der Schuss nach hinten los. Dann kommt man schnell eine Lage wo es sich nur bei ganz bestimmten Algoritmen lohnt.

Voraussetzung dafür ist natürlich, dass Ergebnisse durch eine Neuordnung der Instruktionen nicht verfälscht werden.

Das ist richtig und gilt auch für VISC. Damit ist der Vorteil eben auch je nach Anwendung sehr unterschiedlich. Noch vor OoO hat Intel übrigens HT als Lösung gebracht um die Kerne in der Zeit in der sie auf Daten warten müssen besser auszulasten. Daher bringt HT bei den meisten Anwendungen bei OoO CPUs auch viel weniger als bei den In-Order CPUs, denn durch OoO werden gerade diese Wartezeiten auch sinnvoll durch das Vorziehen nachfolgender Instruktionen vermindert.

Die Diskussion ob MorphCore in bestimmten Situationen nun In-Order arbeitet oder nicht, halte ich zum jetzigen Zeitpunkt für irrelevant. Bei Single-Thread Lasten wird es sicher OoO sein, sonst würe die ST-Performance ja dramatisch schlechter, da sind wir uns wohl alle einig. Bei massiv parallelen Lasten sehe ich keine zwingenden Grund warum es nicht auch eingeschränktes OoO sein sollte, außer dem Aufwand und von daher wäre es sinnvoll es OoO zu machen, wenn man weiter nur ein SMT mit wenigen Threads, z.B. 2 wie bisher bei Intels HT ausführt und eben einfach nicht so in die Tiefe geht und dafür eben zwei Threads abarbeiten, also auf die OoO Einheit aufteilt. In-Order bringt ja wohl erst dann Vorteile, wenn man ein SMT (HT) mit 4 Threads oder noch mehr pro Kern macht, wobei Konzept von 2012 ja sogar von 6 bis 8 Threads pro Kern ausgeht.

Lass uns also abwarten wie es konkret umgestetzt wird und welche Vorteile es dann hat, denn vom akademischen Konzept zur praktischen Implementierung ist es ja immer auch ein weiter Weg und dabei erfolgen oft noch viele Veränderungen und Verbesserungen. Es wird auch oft nicht alles konkret veröffentlicht, da man den Wettbewerbern auch nicht zu viele Ideen geben will.

In-Order hat den Vorteil, dass der Platz- und Energiebedarf relativ gering ist, weil man sich einiges an Verarbeitungslogik sparen kann.

Genau die Logik existiert aber in einem MorphCore sowieso schon. Wenn ich da jetzt statt die nächsten 8 oder 16 Intruktionen darauf zu untersuchen welche ich vorziehen muss und kann, dann nur 4 Threads machen und für jeden nur die nächsten 2 bis 4 Instruktionen ansehen, dann könnte so ein Mischkonzept die effizientere Lösung sein.

Bei Multithreading spielt das dann allerdings weniger eine Rolle. Hier kann ein Cluster aus In-Order Kernen bei gleichem Durchsatz effizienter sein als ein Cluster aus OoO Kernen.

Wobei dann aber eben entsprechend mehr Kerne vorhanden sein müssen, damit das stimmt, was wegen der Einfachheit der Kerne bei gleicher Chipfläche ja auch zu realisieren ist.

Ein Programmierer muss gar nicht wissen, in welcher Reihenfolge Threads ausgeführt werden. Was soll ihm das bringen? Mit dedizierten Hardwarethreads werden Softwarethreads sowieso parallel ausgeführt.

Eben, ein Programmierer muss nur die nötigen Syncronierieungen einfügen, wenn er über Threads hinweg auf Daten zugreift, was leider viele Programmierer immer noch nicht beherrschen. Diese Synchronierungen sind aber wichtig, denn nur so kann z.B. sichergestellt werden, dass die Daten auch innerhalb der einzelnen L1 und L2 Caches der Kerne stimmig sind.

VISC geht allerdings den umgekehrten Weg wie MorphCore und ist nochmal eine ganze Ecke radikaler.

Wobei die Frage ist, wie weit sich beides auch kombinieren lässt. Wenn man breite Register und Ausfürhungseinheiten hat die auch aufgeteilt werden können (Buldozers FPU lassen grüssen), dann wäre es ja nicht unmöglich dort zwei Instruktionen parallel zu verarbeiten, die je nur die Hälfte der Breite nutzen.

Fazit: Es bleibt spannend, die Hersteller haben noch neue Ideen die CPUs zu optimieren und man wird abwarten müssen, was kommt und vor allem was es am Ende wirklich bringt. Denn schon in der Vergangenheit waren ja nicht alle theoretisch wohlklingenden Konzepte in der Praxis auch wirklich erfolgreich.

 

[unl34shed]

@Holt: lies sich mal in das Thema superskalare CPU ein. Das ist was du mit visc verwechselst.

Visc arbeitet auf einer höheren Ebene

 

[mr.dude]

Dass der Thread-Sheduler transparent arbeitet würde ich eher nicht sagen. Wenn ich 2 Threads starte, dann kann ich nicht wissen welcher zuerst ausgeführt wird und ob diese Reihenfolge auch immer eingehalten wird.

Dafür gibt's dann Strategien und Funktionen zur Threadsynchronisierung. Eine geordnete Ausführung von Thread gibt's sowieso nicht. Wenn du zB zwei Threads erzeugst, dann muss die Ausführung nicht wie folgt ausschauen:

1 - 2 - 1 - 2 - 1 - 2 ...
oder
2 - 1 - 2 - 1 - 2 - 1 ...

Die Ausführung kann zB auch mal so ausschauen:

1 - 2 - 1 - 1 - 2 - 1 ...

Ich muss "per Hand" (oder mittels einer (meist höhren) Programmiersprache halb-automatisch) dafür sorgen dass z.B. die Threads nicht versuchen gleichzeitig die selbe Speicherzelle zu beschreiben oder das Programm mit veralteten Daten arbeitet weil der Windows-sheduler zufällig grade dann meinen Thread pausiert hat, nachdem ich eine Abfrage durchgeführt habe und sich dann die Bedingung in der Zwischenzeit durch den anderen Thread ändert.

Dafür gibt's extra Synchronisierungsobjekte, wie Mutex oder Semaphore. "Per Hand" sollte man das besser nicht machen, da diese Synchronisierung auf atomarer Ebene stattfinden muss, um Sicherheit zu gewährleisten. "Per Hand" kann man normalerweise nicht auf atomarer Ebene mit gängigen Sprachen programmieren.

Nein, nicht parallel, das wäre ja gerade VISC

Doch, parallel. Das nennt sich wie gesagt ILP. VISC ist was anderes.

Die Diskussion ob MorphCore in bestimmten Situationen nun In-Order arbeitet oder nicht, halte ich zum jetzigen Zeitpunkt für irrelevant. Bei Single-Thread Lasten wird es sicher OoO sein, sonst würe die ST-Performance ja dramatisch schlechter, da sind wir uns wohl alle einig.

Das ist eben die spannende Frage im Moment. In der ersten MorphCore Implementierung scheint die Aktivierung des In-Order Modus einzig von der Anzahl der Threads abhängig zu sein.

When does MorphCore Switch Modes?
In our current implementation of MorphCore, we switch between
modes based on the number of active threads (other policies are part
of our future work). A thread is active when it is not waiting on any
synchronization event. The MorphCore starts running in OutofOrder
mode when the number of active threads is less than a threshold (2
in our initial implementation). If the OS schedules more threads
on MorphCore, and the number of active threads becomes greater
than the threshold, the core switches to InOrder mode.

Die Frage ist nun, was passiert wenn zB 2 Threads auf einen Kern geschoben werden. Ein Thread der viel Performance und ein Thread der wenig Performance verlangt. Bisher ist genau das optimal für HTT. Mit MorphCore könnte es passieren, dass der Thread, der viel Performance verlangt, plötzlich um einiges langsamer läuft. Dem müsste man dann wiederum mit intelligenterem Umschalten in den In-Order Modus entgegenwirken.

Genau die Logik existiert aber in einem MorphCore sowieso schon.

Deshalb glaube ich auch nicht, dass MorphCore beim Multithreading jemals so effizient sein kann wie ein reines In-Order Design bzw wie ein schlankes Design ohne irgendwelche fette OoO Logik. Und daher finde ich auch sowas wie HSA nochmal eine Ecke vielversprechender, wo explizit auf Latenz und Durchsatz zugeschnittene Verarbeitungseinheiten in einem System zum Einsatz kommen. Aber das ist ein anderes Thema. Deswegen kann MorphCore ja trotzdem gegenüber bisherigen OoO Designs was bringen.

Aber wie gesagt, das ist hier off-topic. Vergesst nicht, hier geht's um Zen. Für VISC und MorphCore gibt's passendere Threads.

 

[DragonTear]

Dafür gibt's dann Strategien und Funktionen zur Threadsynchronisierung. Eine geordnete Ausführung von Thread gibt's sowieso nicht. Wenn du zB zwei Threads erzeugst, dann muss die Ausführung nicht wie folgt ausschauen:

1 - 2 - 1 - 2 - 1 - 2 ...
oder
2 - 1 - 2 - 1 - 2 - 1 ...

Die Ausführung kann zB auch mal so ausschauen:

1 - 2 - 1 - 1 - 2 - 1 ...

Dafür gibt's extra Synchronisierungsobjekte, wie Mutex oder Semaphore. "Per Hand" sollte man das besser nicht machen, da diese Synchronisierung auf atomarer Ebene stattfinden muss, um Sicherheit zu gewährleisten. "Per Hand" kann man normalerweise nicht auf atomarer Ebene mit gängigen Sprachen programmieren.

Du musst mir keine Widerholung meiner Kurse geben
Das was du nennst, Mutex, Semaphores, etc. nutzen, würde ich als "von Hand" bezeichnen (richtiges "von Hand", aka Assembler kennt doch ein Medieninformatiker garnicht mehr :P ), denn der Programmierer muss im Kopf haben was er wo locken oder freigeben kann... was nochmals einen ganzen Haufen mehr an logischem Denken abverlangt als sequenzielles Programmieren.

Halb Automatisch ist dann z.B. in Java wo man einfach nur "synchronized" angeben muss um einen Codeabschnitt als solchen zu definieren, oder man mit einem "Monitor" arbeiten kann. Ich würde mir allerdings ein System wünschen wo das vollautomatisch läuft.. am besten das meinen sequenziellen Code effizient mutlitthreaded ausführt.
Wenn gar die CPU selbst in der Lage wäre, sowas zu bewerkstelligen, wäre das definitiv ein sehr großer Meilenstein.
Wird aber wohl vorerst logischerweise ein Wunschtraum bleiben
Okey.. genug off Topic.

 

[Holt]

Doch, parallel. Das nennt sich wie gesagt ILP.

Das können aber die x86er CPUs alle nicht, die sind zwar Superskalar und führen unterschiedliche Verarbeitungsschritte an einem Befehl parallel aus, aber eben wie die Monatge eines Autos am Fliessband und am Ende gibt es für die Hochzeit, wenn also der Motor in die Karosserie kommt, doch nur eine Station. Wirklich parallel führen die x86er CPUs also die Befehle eben nicht aus.

Das ist eben die spannende Frage im Moment. In der ersten MorphCore Implementierung scheint die Aktivierung des In-Order Modus einzig von der Anzahl der Threads abhängig zu sein.

Ist das wirklich eine praktische Implementierung?

Mit MorphCore könnte es passieren, dass der Thread, der viel Performance verlangt, plötzlich um einiges langsamer läuft.

Es gibt für die CPU keine Threads die viel Performance verlangen und solche die weniger verlangen. Entweder ein Thread läuft, dann muss die Befehlskette verarbeitet werden oder er wartet auf irgendwas und dann läuft er nicht auf der CPI, den Thread gibt es dann für die CPU nicht. Von daher ist Dein Ansatz schon falsch. Die Frage ist also eher, ob das Weiterlaufen eines Thread im In-Order Modus dazu führt das die Befehle früher abgearbeitet sind als wenn er ständig warten müsste, weil ein anderer Thread gerade aktiv ist. Es ist eher so die Frage ob mehr Autos durch Engstelle kommen (angenommen wenn ein Hochwasser ein Stück einer ganzen Autobahn weggerissen hat) wenn ich dort nun nur eine Asphaltspur mache auf der sie schnell fahren können, sich aber vorher von mehreren Spuren auf die eine einfädeln müssen (OoO) oder ob man 2 bzw. 4, 6, 8 Standpsuren mit Schlaglöcher hat, wo jeder nur langsam vorankommt, dafür alle viele parallel fahren können (In Order). Kommen nur weniger Autos an die sowieso alle hintereinander auf einer Spur fahren, also Singlethread, ist die Antwort einfach.

 

[DTX xxx]

An die CPU Experten die noch nie an einer CPU Architektur gearbeitet haben, praktisch alle hier.
Werde ich mit dem Zen Windows 10 starten können oder brauche ich mindestens einen Celeron G1820?

 

[madjim]

An die CPU Experten die noch nie an einer CPU Architektur gearbeitet haben, praktisch alle hier.
Werde ich mit dem Zen Windows 10 starten können oder brauche ich mindestens einen Celeron G1820?

Sehr witzig, jedoch nicht sachlich.

 

[DerGoldeneMesia]

Naja die Frage ist wie schnell zen wird, und mit skylake hat man da ja konkurrenz, intel könnte ja einen 72kerner anbieten.
Ich hoffe AMD gibt da vorher auskunft.

 

[mr.dude]

Das können aber die x86er CPUs alle nicht

Natürlich können die das. ZB Pipelining beherrschen AMD und Intel Prozessoren schon sehr lange. Deshalb hat auch jeder Kern zB mehrere ALUs, um Operationen parallel ausführen zu können.

Ist das wirklich eine praktische Implementierung?

Ob die praktisch ist oder nicht, keine Ahnung. Aber sie dürfe erst mal die einfachste sein.

Es gibt für die CPU keine Threads die viel Performance verlangen und solche die weniger verlangen.

Natürlich gibt es diese. Es gibt Threads, die permanent Last erzeugen. Und es gibt Threads, die nur sporadisch Last erzeugen, unterbrochen von Warte- bzw Haltezyklen, weil sie auf bestimmte I/O Ereignisse warten müssen. Wie das dann auf Instruktionsebene ausschaut, war nicht das Thema. Es ging lediglich um Lastverteilung.

Werde ich mit dem Zen Windows 10 starten können

Nein, du wirst das nicht können. Andere werden aber sehr wohl in der Lage dazu sein.

- - - Updated - - -

Um mal wieder zum Thema zurückzukommen, angebliches Blockdiagramm zu einer HPC Zen APU:



Sowas in abgespeckter Form wäre auch ein super Desktop- oder Konsolenchip.

 

[DragonTear]

Interessantes Teil. Besonders mit HBM speicher. Würde allerdings ein riesiger Chip werden o.o

 

[DerGoldeneMesia]

32MB Cache und 16GB HBM Memory sehr interessant aber vielleicht max.

Bei Bulldozer hab ich das papier geküsst weils so gut aussah. Zum Glück hab ich eine Frau.

 

[CHAOSMAYHEMSOAP]

Um mal wieder zum Thema zurückzukommen, angebliches Blockdiagramm zu einer HPC Zen APU:

Naja, sieht eher wie das Fantasieprodukt eines AMD Fanboys aus. Alleine der CPU Part wäre etwa so komplex wie ein Haswell-EP.
Dazu dann noch der Grafikteil, bei dem ich mir nicht sicher bin, ob man für die angegebene DP Leistung nicht mehr Transistoren benötigen würde, als momentan in den APUs verbaut wird.
Die 64 PCIe 3.0 Lanes gibt es auch nicht zum Nulltarif und was soll der 1 GBit Controller rechts unten im Bild?

Bei einer kommenden Server CPU würde man doch 10 GBit und/oder mehrere GBit Ports und mind. einen HT-Link erwarten.

 

[ONE_FOR_ALL]

Man wird doch mal träumen dürfen.

 

[mr.dude]

Naja, sieht eher wie das Fantasieprodukt eines AMD Fanboys aus.

Nicht wirklich. Seattle hatte bereits 8 Kerne. Und der ist nur 28nm. Doppelt so viele Kerne und doppelt so viel shared L3 pro Kern sollte machbar sein in 14nm.

Alleine der CPU Part wäre etwa so komplex wie ein Haswell-EP.

Was heisst komplex? Haswell EP ist vor allem gross. Der ist aber auch nur 22nm. Ausserdem ist die Komplexität aufgrund eines modularen Aufbaus deutlich reduziert bei der Zen APU. Wenn du mal genau hinschaust, es sind nicht einfach 16 Kerne, sondern 4 Cluster mit jeweils 4 Kernen und einem L3 Segment.

Dazu dann noch der Grafikteil, bei dem ich mir nicht sicher bin, ob man für die angegebene DP Leistung nicht mehr Transistoren benötigen würde, als momentan in den APUs verbaut wird.

Wo steht da was zur DP Performance? Da steht nur was zur DP Rate. Und die ist bei aktuellen FirePros nicht anders.

Die 64 PCIe 3.0 Lanes gibt es auch nicht zum Nulltarif und was soll der 1 GBit Controller rechts unten im Bild?

Sicherlich Ethernet System Management Port (RGMII). Den hatte auch schon Seattle.

Bei einer kommenden Server CPU würde man doch 10 GBit und/oder mehrere GBit Ports und mind. einen HT-Link erwarten.

Das ist aber eben kein allgemeiner Server Prozessor, eine CPU schon mal gar nicht, sondern ein spezielles HPC APU Design. Sozusagen AMDs Exascale Entwicklung. Sowas gab es auch schon vorher als Konzept. Mittlerweile ist man wohl soweit, es auch umzusetzen.

 

[ONE_FOR_ALL]

Bin ich beim Googlen gerade drüber gestolpert.Apples A7 soll Patent von US-Universität verletzen Ein paar Jahre zurück hatte Intel doch ein paar Probleme mit den gleichen Patenten. AMD sollte mal ein Paar Millionen in die Hand nehmen und sich das Patent lizensieren,scheint extrem wichtig für die Sprungvorhersage.

 

[Phantomias88]

@one_for_all
Erledigt: Chip-Hersteller: AMD rüstet mit Design-Lizenz von ARM gegen Intel auf - IT + Medien - Unternehmen - Handelsblatt
Was kommt als nächstes?

 

[ONE_FOR_ALL]

@one_for_all
Erledigt: Chip-Hersteller: AMD rüstet mit Design-Lizenz von ARM gegen Intel auf - IT + Medien - Unternehmen - Handelsblatt
Was kommt als nächstes?

????

 

[Phantomias88]

AMD ist einer der Hauptträger der ARM Lizensen.
HBM Speicher im ZEN hören sich aber auch mächtig böse an...

 

[ONE_FOR_ALL]

Ich liebe AMD auch

 

[Holt]

Natürlich können die das. ZB Pipelining beherrschen AMD und Intel Prozessoren schon sehr lange. Deshalb hat auch jeder Kern zB mehrere ALUs, um Operationen parallel ausführen zu können.

Welche Kernen haben mehrere ALUs? Dafür würde ich aber gerne mal Belege sehen, denn die ALU ist die zentrale Ausführungseinheit für die Integerbefehle und Opterationen, da wäre mit keine x86er CPU bekannt, wo ein Kern mehr als eine ALU hat. Das Pipelining ist natürlich eine Art von Parallelität, aber das sind eben die Vorstufen zur Auführung die dort erledigt werden, die eigentliche Operation findet in der ALU statt, oder eben in der FPU aber eben nicht parallel für zwei Befehle oder bestenfalls parallen in der ALU und in der FPU, keine Ahnung ob die das beherrschen.

Natürlich gibt es diese. Es gibt Threads, die permanent Last erzeugen. Und es gibt Threads, die nur sporadisch Last erzeugen, unterbrochen von Warte- bzw Haltezyklen, weil sie auf bestimmte I/O Ereignisse warten müssen. Wie das dann auf Instruktionsebene ausschaut, war nicht das Thema. Es ging lediglich um Lastverteilung.

Natürlich ist genau das das Thema, oder kann Deine CPU sogar vorhersagen, wie lange der Thread auf diese I/O Ereignisse warten muss? Reale CPUs können das natürlich nicht und wenn ein Threas läuft, müssen sie die Befehle so lange so schnell wie möglich abarbeiten bis eben das Warten auf ein Ergeignis ihn wieder stoppt. Ob die Wartezeit nur nur 1% der 99% der Gesamtlaufzeit ausmacht, kann eine CPU gar nie vorab wissen, das sieht hinterher im Resourcen Monitor oder bei top.

Um mal wieder zum Thema zurückzukommen, angebliches Blockdiagramm zu einer HPC Zen APU

Was soll den "16 Lanes switchable with 2 of SATA Express" bedeuten? Soll man da 8 SATA Express Geräte anschliessen können, die es erstens auf dem Markt noch überhaupt nicht gibt und die zweitens für Enterprise sowieso irrelevant sind? SATA Express ist ein Rohrkrepierer, denn es bietet nur maximal 2 PCIe Lanes was gerade mal eine Bandbreite erlaubt, die schon heute von schnellen Consumer SSDs mit PCIe 3.0 x4 wie Intel 750 und Samsung SM951 überboten wird.

Für Enterprise war daher auch von Anfang an SFF-8639 vorgesehen, was sich auch beim Consumer HW durchsetzen wird, bevor SATA Express überhaupt in die Gänge kommt. Deshalb schreibt Anandtech auch sehr passend:

The SFF-8639 is essentially SATA Express on steroids and offers four lanes of PCIe connectivity for up to 4GB/s of bandwidth with PCIe 3.0 (although in real world the maximum bandwidth is about 3.2GB/s due to PCIe inefficiency). Honestly, aside from the awkward name, SFF-8639 is what SATA Express should have been from the beginning because nearly all upcoming PCIe controller designs will feature four PCIe lanes, which renders SATA Express useless as there's no point in handicapping a drive with an interface that's only capable of providing half of the available bandwidth. That said, I wasn't at the table when SATA-IO made the decision, but it's clear that the spec wasn't fully thought through.

SFF-8639 hat aber mit SATA und SATA Express nichts mehr zu tun, weil es eben keine SATA Ports sondern nur die 4 PCIe Lanes gibt. Und warum sata-io.org auf SATA Express gesetzt hat ist auch klar, hätte man gleich auf SFF-8639 setzen wollen, wäre man ja nicht mehr zuständig gewesen. Wer schafft sich schon gerne selbst ab?

Das AMD nun bei einer Server CPU/APU/SoC auf 18 SATA Express Anschlüssen setzen würde, kann ich mir wirklich nicht vorstellen, wenn dann auf 4 SFF-8639 Anschlüssen. Wäre zwar schön wenn wenigstens die Häfte wahr wäre, sieht aber zu sehr nach Fake aus.

 

[CHAOSMAYHEMSOAP]

AMD ist einer der Hauptträger der ARM Lizensen.

ARM wäre echt arm dran, wenn sie von dem ewigen Verlierer so abhängig wären. Zumal AMD noch nicht einmal ein fertiges ARM Produkt anbieten kann.

 

[CyLord]

ARM wäre echt arm dran, wenn sie von dem ewigen Verlierer so abhängig wären. Zumal AMD noch nicht einmal ein fertiges ARM Produkt anbieten kann.

Warum immer eine Wertung dabei sein muss - das verstehe ich nicht. Von was/wen macht sich denn ARM abhängig?

 

[CHAOSMAYHEMSOAP]

ARM ist von seinen Lizenznehmern abhängig. Die Wertung bezieht sich auf das Unternehmen AMD und den Bullshit den der Acht-Acht-Liebhaber wieder mal in die Welt setzt, denn ARM wird seine
Existenz nicht von einem Versagerunternehmen wie AMD abhängig machen. Zumal mit Apple und Qualcomm wesentlich größere Unternehmen ARM Lizenzen erworben haben und das auch noch
wesentlich früher als AMD. Und im Gegensatz zu AMDs ARM CPU kann man deren Produkte auch tatsächlich kaufen.

 

[Phantomias88]

Was soll den "16 Lanes switchable with 2 of SATA Express" bedeuten? Soll man da 8 SATA Express Geräte anschliessen können, die es erstens auf dem Markt noch überhaupt nicht gibt und die zweitens für Enterprise sowieso irrelevant sind? SATA Express ist ein Rohrkrepierer, denn es bietet nur maximal 2 PCIe Lanes was gerade mal eine Bandbreite erlaubt, die schon heute von schnellen Consumer SSDs mit PCIe 3.0 x4 wie Intel 750 und Samsung SM951 überboten wird.

Der Komplette Satz: "16 Lanes switchable with 2 of SATA Express, 14 Lanes of SATA.
Also Zwei von den 16 sind für SATA Express die Restlichen für SATA (non Express).

Übringens hat Anand unrecht mit dem Overhead von PCIe, es handelt sich um PCI-Express 3 !
Der Overhead bei einer 128/130Bit Codierung liegt bei nicht mal 5% (PCIe 2 hatte noch 20%).

 

[DerGoldeneMesia]

die meisten hätten wohl gerne ein tablet mit einer amd apu.