News Skylake-SP: Der Ringbus ist tot, es lebe das Mesh

Volker

Ost 1
Teammitglied
Dabei seit
Juni 2001
Beiträge
14.298
#1
Die ersten Die-Shots der neuen Skylake-High-End-Prozessoren ließen es schon erahnen, jetzt macht Intel es offiziell: Der mit Nehalem eingeführte Ringbus-Interconnect ist Geschichte. Kerne, Cache oder System Agent sind jetzt über ein so genanntes Mesh-Netzwerk verknüpft, wie es Intel bereits bei Knights Landing eingeführt hatte.

Zur News: Skylake-SP: Der Ringbus ist tot, es lebe das Mesh
 
Dabei seit
Mai 2012
Beiträge
671
#2
Schöner Artikel. Wurde auch langsam Zeit, dass der Bus aufgebohrt wird... und in zehn weiteren Jahren wird dann endlich mal weiter in die Höhe gebaut und es gibt ein dreidimensionales Gitter.
 

Holt

Fleet Admiral
Dabei seit
Mai 2010
Beiträge
45.138
#3
Wie erwartet setzt Intel genau da an wo AMDs Konzept Schwächen hat: Bei der Latenz der Verbindung der Kerne untereinander. Da ist AMDs Konzept mit den CCX und der Fabric als Verbindung zwischen allen Komponenten schon den alten Ringbussen unterlegen und wird gegenüber den neuen Mesh nich stärker abfallen, sobald es viel Kommunikation zwischen den Kernen kommt. Da hat Intel ja schon lange viel Aufwand betrieben, siehe die TSX Befehle und dieser sollte sich bei entsprechenden Anwendungen auch bemerkbar machen. Mit den Skylake des Mainstream haben die Skylake-X /-SP nun wirklich nur noch den Namen gemein, da bin ich wirklich mal auf die Reviews gespannt.
 

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.355
#4
Habt ihr Infos wie da einzelne Kerne miteinander kommunizieren, die diagonal zueinander liegen also:

Code:
X O O O
O O O O 
O O O O
O O O X
und wie bei einem solchen Mesh Kollisionen vermieden werden?

Ansonsten ein großes Ui! So ein Mesh sorgt für reichlich Komplexität und Chipfläche wird das auch nicht wenig fressen.

@Holt:
Damit hast du recht, wird hätten Zen aber wohl noch deutlich später am Mark gesehen, wenn sie so eine komplexe Konstruktion gebracht hätten.
 
Zuletzt bearbeitet:

Holt

Fleet Admiral
Dabei seit
Mai 2010
Beiträge
45.138
#5
Ganz einfach, erst nach rechts und dann nach unten oder umgekehrt, je nachdem welcher Weg gerade frei ist. Von nichts kommt eben nichts, so ein Mesh dürfte Platz kosten, sofern Intel den nicht als 3D Struktur ausführt, aber selbst dann wären die Herstellungskosten deswegen höher, kostet doch auch jede Bearbeitungsschritt Geld. Dafür kosten die Intel CPU dann ja auch mehr.
 

ZeroZerp

Lt. Commander
Dabei seit
Okt. 2007
Beiträge
1.808
#6
Ich bin gespannt, wie sich das in der Praxis auswirkt.
In der Theorie ist vieles toll...

Wenns funktioniert wie angekündigt ist das ein wichtiger und großer Schritt in die richtige Richtung.

Grüße
Zero
 

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.355
#8
@Holt

Genau dieses Routing interessiert mich. Es macht einen enormen Unterschied ob da Routen fest vorgesehen sind, ein primitives Routing ohne Lasterkennung oder ein dynamisches Routing unter der Berücksichtigung der Auslastung der Route erfolgt. Gleichzeitig mit der Problematik, dass Kollisionen ja irgendwie auch vermeidet werden sollten bei gleichzeitig geringen Latenzen.



@Rock Lee

In der Welt dicker Server und High Performance Computing gibt es keine Spezialfälle. Es finden sich in der Regel immer Abnehmer :)
 
Zuletzt bearbeitet:
Dabei seit
Mai 2012
Beiträge
671
#9
Wie erwartet setzt Intel genau da an wo AMDs Konzept Schwächen hat
Naja, so spontan werden sie das wohl nicht entwickelt haben...

Was die Kommunikation zwischen den Kernen betrifft, so muss der Prozessor natürlich einen Kompromiss aus kurzem Weg und guter Lastverteilung wählen. Das sollte aber von vorneherein besser vermieden werden. So sollte die Software dafür sorgen, dass Aufgaben mit starker Inter-Core Kommunikation an physisch benachbarte Kerne überwiesen werden.
 

dfgdfg

Lt. Commander
Dabei seit
Sep. 2010
Beiträge
1.387
#10
Ist bekannt, ob die Technik auch bei Skylake-X verwendet wird? Eigentlich doch schon, da sie von der Server-Sparte stammen, oder?
 
Zuletzt bearbeitet:

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.355
#11
[...]So sollte die Software dafür sorgen, dass Aufgaben mit starker Inter-Core Kommunikation an physisch benachbarte Kerne überwiesen werden.
Was bedeutet, dass du das Laufzeitverhalten der Threads vorhersagen können musst. Trivial geht anders!
Ergänzung ()

https://semiaccurate.com/2017/06/15/intel-talks-skylakes-mesh-interconnect/

Semiacurate liefert etwas mehr Informationen und spekuliert auch über ein primitives Routing.
 

Holt

Fleet Admiral
Dabei seit
Mai 2010
Beiträge
45.138
#13
Genau dieses Routing interessiert mich. Es macht einen enormen Unterschied ob da Routen fest vorgesehen sind, ein primitives Routing ohne Lasterkennung oder ein dynamisches Routing unter der Berücksichtigung der Auslastung der Route erfolgt. Gleichzeitig mit der Problematik, dass Kollisionen ja irgendwie auch vermeidet werden sollten bei gleichzeitig geringen Latenzen.
Erstens wird Intel sich dabei schon einiges gedacht und viel simuliert haben und wäre es nicht besser als die Ringbusse wäre man bei denen geblieben. Zweitens werden sie solche Details schon gar nicht verraten, sonst könnte AMD diese Konzept noch leichter übernehmen.

Naja, so spontan werden sie das wohl nicht entwickelt haben...
Das stimmt, trotzdem ist es ein klarer Gegenentwurf zu dem Ansatz den AMD realisiert hat.
Was die Kommunikation zwischen den Kernen betrifft, so muss der Prozessor natürlich einen Kompromiss aus kurzem Weg und guter Lastverteilung wählen.
Und wie soll das gehen? Die Prozesse können zwar den Scheduler in der Hinsicht beeinflussen das sie vorgeben auf welchen Kernen sie ausgeführt werden können, aber ersten müsste der SW Entwickler wie von Piktogramm erwähnt die Auslastung der Kerne kennen und zweiten müsste er bei RYZEN und Derivaten auch noch wissen welches Kern zu welchem CCX gehört? Welches API informiert darüber?

Man kann immer SW so auf eine spezielle HW anpassen, dass sie damit optimal läuft, nur leider läuft sie dann auf anderer HW meist nicht mehr sehr optimal und der Aufwand lohnt sich auch nur in sehr wenigen und speziellen Fälle. Daher ist der weitaus bessere Ansatz immer noch eine HW zu schaffen auf der möglichst viel der bestehenden SW möglichst schnell läuft.
So sollte die Software dafür sorgen, dass Aufgaben mit starker Inter-Core Kommunikation an physisch benachbarte Kerne überwiesen werden.
Auch hier: Wie soll das rein praktisch gehen? Welche API verrät dem SW Entwickler, wozu auch der Entwickler des Task Schedulers im OS gehört, welche Kerne physisch Nachbar sind? Es kann aus dem 18 Kern Die ja auch eine 14 oder 16 Kern CPU werden, dann sind beliebige 2 oder 4 der Kerne deaktiviert und auf jeder CPU hat eine bestimmter Kern dann womöglich andere Nachbarn.

Gibt es einen Weg wie die CPU darüber informieren kann? Mir ist keine bekannt, aber könnte deswegen trotzdem einen geben. Nur der Ansatz Nachteile der HW mit SW Optimierungen ausbügeln zu wollen ist schon falsch, weil er viel Aufwand erfordert und daher kaum je in der Breite gangbar ist. Außerdem ist bei SW bei der viel Kommunikation zwischen den Threads und damit den Kernen der CPU nötig ist, diese meist zwischen allen Kernen nötig oder es ist nicht vorhersehbar zwischen welchen.

Nimm eine Datenbankanwendung z.B. für ein Reservierungssystem für eine Hotelkette. Da sind Dutzende oder Hunderte Clients, aber solange jeder Anfragen für ein anderes Hotel stellt, können sie vermutlich weitgehend unabhängig voneinander arbeiten. Wollen aber zwei für das gleiche Hotel für den gleichen Zeitraum ein Zimmer buchen, müssen sie miteinander koordiniert werden, damit nicht das letzte Zimmer an zwei Gäste vergeben wird. Wie will man da jemals vorhersagen können, welche beiden Clientprozesse nun diese beiden Anfragen um das letzte Zimmer für diese Nacht stellen werden um sie auf benachbarte Kerne zu schedulen? Ok, bei der Hotelreservierung ist die Performance wohl egal, aber an der Börse wäre das Anderes!

Ist bekannt, ob die Technik auch bei Skylake-X verwendet wird? Eigentlich doch schon, da sie von der Server-Sparte stammen, oder?
Genau, die Skylake-X dürften wie schon vorher die Broadwell-E und alle anderen Vorgänger in dem großen Sockel, auf den gleichen Dies wie die entsprechenden basieren und nur einige Funktionen wie (leider) die ECC RAM Unterstützung beschnitten und dafür mit anderen wie dem offenen Multi versehen sein. Da Intel kaum noch nebenbei Ringbusse auf dem Die haben wird, sollten auch die Skylake-X auf das Mesh setzen und damit haben sie mit den kleinen Mainstream Skylake wirklich kaum mehr als den Namen gemeinsam, denn auch was die Cachestruktur angehen unterscheiden sie sich, ebenso haben sie AVX512 und entweder ist das bei den Mainstream CPUs deaktiviert oder die Rechenwerke habe auch unterschiedliche Designs.
 

Holt

Fleet Admiral
Dabei seit
Mai 2010
Beiträge
45.138
#15

Hopsekäse

Lt. Commander
Dabei seit
Apr. 2009
Beiträge
1.402
#16
... Zweitens werden sie solche Details schon gar nicht verraten, sonst könnte AMD diese Konzept noch leichter übernehmen.
Richtig. Darüber, wie genau der Ringbus funktioniert, hat sich Intel in der Vergangenheit auch seeeeehr bedeckt gehalten. Nicht nur der Öffentlichkeit gegenüber, sondern sogar Partnern unter NDA.

Beim Knights Landing haben sie auch so ein Mesh. Da der ja noch den HBM an 4 Controllern mit an Bord hat, kann man da auch ein paar interessante Einstellungen fahren, die die Problematik der unterschiedlichen Entfernungen/Latenzen der Kerne zu diesen 4 Controllern unterschiedlich angehen.
Wer interesse daran hat, kann diesbezüglich mal "KNL cluster modes" googlen.

Dass man anständige Antworten darauf findet, wie genau das Mesh umgesetzt ist, würde ich also eher stark bezweifeln.

Vielleicht gibt es aber ähnliche Dinge wie die Cluster Modes auch beim Skylake-SP. Vielleicht ist die Latenz zum RAM aber auch so viel größer als zum MCDRAM des KNL, dass die geringen Unterschiede zwischen den Kernen nicht ins Gewicht fallen.

Für Skylake-X wäre das Thema vermutlich eh uninteressant. Desktop-Software unter Windows, die ihre Threads an das Mesh angepasst pint? Das würde mich arg wundern.
 

Krautmaster

Fleet Admiral
Dabei seit
Feb. 2007
Beiträge
19.112
#17
Ich halte den AMD Ansatz mit vielen Die dennoch sehr interessant wenn nicht gar besser. Ich denke die Szenarien die Kernübergreifende Kommunikation massiv benötigen sind selten, gerade dann selten wenn zb über 20 Threads belastet werden.

AMD muss ähnlich Numa schauen dass diese Threads nahe beieinander ausgeführt werden, innerhalb eines CCX. Dann aber ist die Kommunikation super fix. Bei also bis 4 Threads, was wohl den Großteil der typischen Szenarien bilden dürfte, hat das einen Vorteil.

Gleichzeitig ist eine einzige Die wie bei Zeppelin schon sehr wirtschaftlich und kompakt.

Mal sehen was Intels Mesh so kann und wie da die Latenzen Kern zu Kern aussehen. Bin gespannt. Vermutlich zu den genau nebeneinander liegenden super fix, komplett auf der anderen Seite der Die entsprechend langsamer.
 

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.355
#20
Erstens wird Intel sich dabei schon einiges gedacht und viel simuliert haben und wäre es nicht besser als die Ringbusse wäre man bei denen geblieben. Zweitens werden sie solche Details schon gar nicht verraten, sonst könnte AMD diese Konzept noch leichter übernehmen.

Das so etwas nicht vom Baum fällt ist klar -.-
Das es nicht sinnvoll ist, habe ich auch nicht einmal angedeutet.
Die können das Konzept vom Routing verraten, ohne das AMD damit auch nur eine Mannstunde sparen würde. Von "noch leichter" kann nicht die Rede sein, leicht ist bei da wirklich gar nichts.
 
Top