AMD Genesis: Angeblich Threadripper 4000 in AIDA64 gesichtet
Threadripper 3000 ist noch nicht mal richtig für Herbst 2019 angekündigt, da geistert nun bereits Threadripper 4000 durchs Internet - angeblich auf Basis von Zen 3. Die Herleitung, dass es sich um die vierte HEDT-Generation von AMD handelt, ist zwar schlüssig, aber auch wild - zumindest so früh vor Veröffentlichung.
AMD will an Threadripper festhalten und nach letztem Stand aus der Gerüchteküche sollen die Prozessoren für die HEDT-Plattform, so Intels Gattungsbezeichnung, im Oktober erscheinen. Nun gibt die Datenbank von AIDA64 den nächsten Hinweis. Im Forum von Planet3DNow meldete man, dass in AIDA64 die die Codenamen "Vermeer" und "Genesis" aufgetaucht sind. Und die sind nicht für Threadripper im Oktober, sondern sollen schon zur Nachfolgegeneration gehören.
Die 4000er-Reihe, wenn man so will. Vermeer soll dabei für Ryzen 4000 und Zen 3 stehen, während Genesis noch Fragen aufwirft. Als dann etwas tiefer gegraben wurde, stieß man in den USA auf einen Genesis Peak im Bundestaat Washington, in direkter Nachbarschaft zu Castle Peak und Colfax Peak. Auf Basis dessen vermutet man, dass es sich nur um Threadripper 4000 handeln kann, denn für Threadripper 3000 ist der benachbarte Castle Peak reserviert, während Threadripper 2000 Colfax (Peak) ist.
Das ist natürlich alles recht wilde Spekulation, aber es wäre schon naheliegend, dass es sich bei Genesis um die übernächste Threadripper-Generation handelt. Ebenso wild spekuliert sind die potenziellen Neuerungen in Zen 3. PCI Express 5.0 und DDR5 fallen da, aber ob das wirklich so kommen wird, ist eher ungewiss. Da bei Threadripper von Ende 2020 die Rede ist, wäre es vielleicht etwas zu früh für diesen Sprung. Es wurde aber auch immer wieder spekuliert, dass das SMT auf vier Threads pro Kern aufgebohrt wird, was sicher auch zumindest interessant wäre.
Auch lesenswert: AMD Ryzen 3000 & 4000: Codenamen Castle Peak, Vermeer und Renoir aufgetaucht
Als nächstes steht jetzt erst einmal die dritte Generation von Threadripper auf dem Plan; die wird ein Derivat von den Epyc-Prozessoren "Rome" werden, sehr wahrscheinlich erneut für Sockel TR4 erscheinen und PCI Express 4.0 unterstützen. Mittels der Zen-2-Chiplets kann AMD Konfigurationen bis 64 Kernen in 7 nm anbieten. Wo Threadripper endet, ist unklar. Wirtschaftlich gesehen dürfte es bei 24 oder maximal 32 Kernen sein. Dem IO-Controller in 12 nm wird erwartungsgemäß ein Quad-Channel-Speicherinterface nachgesagt, die DDR4-3200 unterstützen. Dazu kommen bis zu 64 Lanes PCI Express 4.0, wovon üblicherweise 4 Lanes für den auf dem Mainboard verwendeten IO-Hub (mutmaßlich X590) abgezweigt werden und 16 Lanes beantragt in der Regel die Grafikkarte.
Quelle: Planet3DNow
Ehrlich gesagt glaube ich, dass die Verteilung des Speicherplatzes automatisch durch die Benutzung erfolgt. Ein Cache macht ja nichts anderes, als die Daten und die Speicheradresse von Speicheradresse XY an Cacheposition X+(0...n) zu speichern und bei erneutem Bedarf wieder bereitzustellen, um so den Speicherzugriff zu vermeiden, wobei X das Cachetag, XY eine vollständige Speicheradresse und n die Assoziativität des Caches ist. Dadurch wird bei einer Benutzung von einem Cache durch mehrere Kerne (also in der Regel ab L2) automatisch den Kernen mit der meisten Benutzung der meiste Cache "zugeteilt".
Hier ist ein Artikel von Intel zu dem Thema: Software Techniques for Shared-Cache Multi-Core Systems | Intel(R) Software
Ob zwei Threads auf die gleichen Daten zugreifen, hängt natürlich von der Art der Threads ab. Für SMT wäre es eher von Nachteil, da die Threads offensichtlichen von den Ergebnissen des jeweils anderen abhängig sind und immer wieder aufeinander warten müssen. Grundsätzlich ist es aber zumindest bei Intel auf L1- und meinem Wissen nach auch L2-Ebene so, dass der Prozessor für die gerade laufenden Threads Daten vorrätig zu halten versucht und dabei teilt er den verfügbaren Speicherplatz ein. Je weniger Threads parallel laufen, desto mehr Daten können pro Thread für den Fall einer etwaigen Wiederverwendung zwischengespeichert werden.
OK, wir reden von verschiedenen Schedulern. Ich meinte den vom OS. Klar, der in der CPU hat keine Zeit, da kommen die Logiken zum Einsatz, die ich oben auch erwähnte. Mehr als ein Zähler oder ein paar Signale, die die ALUs über ihren Arbeitszustand von sich geben, ist da nicht drin.
Der Scheduler selbst dürfte gar kein Bewusstsein für das Konzept "Thread" haben. Der schickt die vom Decoder angelieferten Micro Ops in die Ausführungseinheiten und kann bestenfalls abhängige/spekulative Befehle nachrangig behandeln. Aber derartige Entscheidungen werden innerhalb eines Taktzyklus getroffen, selbst unter Berücksichtigung des kompletten Decodings steht viel zu wenig Zeit für eine Überprüfung der Thread-Eigenschaften zur Verfügung. Wie nach einschlägigen Hacks bekannt sein sollte, lässt zumindest Intel selbst Zugangsberechtigungen erst parallel zur eigentlichen Berechnung überprüfen, weil es weniger Leistung kostet, wenn ein Teil der Berechnungen wieder verworfen werden muss, als wenn man vor dem Start jeder Berechnung erst eine komplexe Entscheidung treffen muss.
So richtig leuchtet mir das nicht ein, warum es wirklich Nachteile geben sollte, außer dadurch, dass das Scheduling versagt. Die Threads müssten ohne SMT ja auch laufen und würden auch Cache belegen und hätten auch Kommunikationsaufwand. Idealerweise spart man sich lediglich einige aufwändige Kontextwechsel und hat eine höhere Auslastung der Rechenwerke, aber wenn der Scheduler schwere Threads zusammenpackt, ächzen halt ein paar Kerne und ein paar drehen Däumchen. Das ist im Moment das einzige was mir wirklich einleuchtet, was mit SMT passieren kann und ohne nicht. Das sollte aber eigentlich lösbar sein, wenn das OS weiß, welche logischen Kerne jeweils einen physischen ausmachen. Zumindest, wenn die Last der einzelnen Threads nicht wild schwankt.