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

[Volker]

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

 

[mr_andersson]

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]

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]

Habt ihr Infos wie da einzelne Kerne miteinander kommunizieren, die diagonal zueinander liegen also:

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.

 

[Holt]

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.

 

[.Sentinel.]

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

 

[Rock Lee]

erstmal abwarten, ob die Vorteile überhaupt messbar sind.

Und damit meine ich den Cbase-Parcour...nicht irgendwelche exotischen Spezialfälle.

 

[Piktogramm]

@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

 

[mr_andersson]

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]

Ist bekannt, ob die Technik auch bei Skylake-X verwendet wird? Eigentlich doch schon, da sie von der Server-Sparte stammen, oder?

 

[Piktogramm]

[...]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 (16. Juni 2017)

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

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

 

[Seiku]

Danke AMD, dass Intel aus den Puschen kommt.

 

[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.

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.

 

[ottoman]

Danke AMD, dass Intel aus den Puschen kommt.

So einfach würde ich es mir nicht machen. Das Design was hier vorgestellt wurde, ist schon seit Jahren in der Entwicklung. Das wäre auch ohne AMDs Ryzen gekommen.

 

[Holt]

Danke AMD, dass Intel aus den Puschen kommt.

Das hat mit AMD nichts zu tun, so eine Umstellung braucht viel Vorlauf und Intel geht hier wie gesagt einen ganz anderen, zu AMDs Ansatz mit den CCX und der Fabric komplett gegensätzlichen Weg.

 

[Hopsekäse]

... 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]

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.

 

[DjangOC]

erstmal abwarten, ob die Vorteile überhaupt messbar sind.

Und damit meine ich den Cbase-Parcour...nicht irgendwelche exotischen Spezialfälle.

Dir ist schon bewusst, an wenn sich die EX Ableger richten?
Die sind für Spezialfälle konzipiert, und nicht für "Ich muss CSGO mit 800fps gamen können"-Gamer...

 

[Popey900]

Das wäre auch ohne AMDs Ryzen gekommen.

Bestimmt, aber mindestens 5 Jahre später.

 

[Piktogramm]

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.