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

[Holt]

AMD Ansatz ist vor allem für AMD besser, da man den billiger umsetzen kann, zumal wenn durch Kombination mehrer Dies CPU mit sehr vielen Kernen gebaut werden. Da AMD diesen Kostenvorteil auch an die Kunden weitergibt, haben auch diese was davon. Technisch könnte er allenfalls durch eine geringere Leistungsaufnahme prunkten, aber ansonsten dürfte er dem Mesh hoffnungslos unterlegen sein. Die Anwendung bestimmt dann letztlich, wie relevant dies ist und welcher der beiden Ansätze für die jeweilige Anwendung besser funktioniert oder vielleicht anderes gesagt: Ob auch AMD einfacherer Ansatz hinreichend gut funktioniert und man daher die Kostenersparnis mitnehmen kann oder nicht.

Das ist bei Serveranwendungen einfacher, die HW wird hier ja meist für eine bestimmte Nutzung ausgelegt und entsprechend gekauft, beim Desktop ist es hingegen meist so, dass man eine CPU wählt die bei einer möglichst breiten Bandbreite an SW gut performt, weil man da eben viel seltener nur eine Nutzung hat die wirklich so dominant ist, dass man seine HW extra darauf optimiert. Andererseits spielt dort der Preis eine viel größere Rolle und wenn es bei AMD dann eben 16 Kerne fürs gleiche Geld gibt was man bei Intel für 10 Kern CPUs hinlegt, dann könnten schon einige Anwendungen die unter der hohen Latenz zwischen den CCX leiden, dies über die zusätzlichen Kerne wieder ausgleichen. Da muss man die Tests abwarten, denn sowas kann man schwer im Detail vorhersagen.

Es sollte aber klein sein, dass die Vergleichen von RYZEN zu Broadwell-E nicht viel über das kommende Duell zwischen ThreadRipper und Skylake-X aussagen würden, da bei beiden die Stärken und Schwächen der Kommunikation zwischen den Kernen noch mal extremer ausfallen werden. Bei TreadRipper wird sie wegen der beiden Dies noch negativer auffallen, es ist dann nicht mehr nur jeder zweite Kern auf einem anderen CCX, sondern 3 von 4 und jeder zweite ist sogar auf einem anderen Die. Bei Skylake-X dürfte es dagegen eine noch geringere interne Latenzen geben, deshalb tauscht Intel ja die Ringbusse gegen das Mesh

 

[aldaric]

Ich zweifel daran, dass die bei AMD da jetzt absolut keinen Plan haben wie das funktioniert. Eher ist der Mesh für sie momentan uninteressant, da sie auf den Zeppelin-DIE setzen um damit momentan wirtschaftlicher zu produzieren.

 

[Holt]

AMD muss ähnlich Numa schauen dass diese Threads nahe beieinander ausgeführt werden, innerhalb eines CCX. Dann aber ist die Kommunikation super fix.

Sowas gibt es aber bisher nicht,
es gibt nur NUMA, wobei die CCX aber eben keine echten NUMA Kerne sind. Trotzdem hätte AMD sie als einzelne NUMA Nodes deklarieren können, nur würde dann eine ganze Menge SW nur auf den maximal 4 Kernen eines CCX laufen, da gerade viele der Programme die Heimanwender nutzen eben nicht NUMA aware sind. Dann wären 8 Kerner für Heimanwender recht sinnlos, weshalb AMD dies auch unterlassen haben dürfte.

Nur wie könnte eine Alternative "ähnlich NUMA" aussehen und sich von NUMA unterscheiden? Da fällt mir nichts ein was nicht auch bei NUMA so ist, denn auch wenn beide CCX auf einem Die am gleichen RAM Controller hängen, so wären eben die Regeln die gleichen: Keine Threads eines Programmes auf Kernen unterschiedlicher NUMA Nodes (CCX) starten wenn es dies nicht erlaubt und verbiete dann auch dem Scheduler die Threads zwischen NUMA Nodes hin und her zu schieben. Einzig die Regel für einen Thread möglichst nur RAM zu allozieren welches an dem NUMA Node hängt auf dem er läuft, wäre dann belanglos.

Bei also bis 4 Threads, was wohl den Großteil der typischen Szenarien bilden dürfte, hat das einen Vorteil.

Bei den 6 Kernern bis zu 3 und bei den bisherigen 4 Kernern bis zu 2.

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

Das ist ja eben der größte Vorteil des Designs und man kann mit dem gleichen Die auch CPUs mir mehr Kernen schaffen als er selbst besitzt.

Vermutlich zu den genau nebeneinander liegenden super fix, komplett auf der anderen Seite der Die entsprechend langsamer.

Solche Unterschiede gab es schon bei den Ringbussen, aber man kann eben nicht z.B. 28 Kerne alle direkt jeden mit jedem verbinden, dann wären kein Platz mehr so viele Kerne auf dem Die. Die zentrale Frage ist, ob die Daten wie auf dem Ringbus pro Takt nur immer maximal eine Station weiter kommen oder z.B. von ganz links auf den Knoten ganz recht springen können und damit im besten Fall jede beliebige andere Stationen in 1 bis 2 Takten erreichbar wäre.

Bestimmt, aber mindestens 5 Jahre später.

Nein, denn mehr Kerne wäre mit den Ringbussen nicht sinnvoll machbar und wegen AMD müssten sie das Mesh bestimmt nicht bringen, da selbst die Ringbusse gegenüber deren CCX Konzept selbst im Worst Case noch eine schneller Kommunikation zwischen den Kernen erlauben. Aber schon für Knights Landing war eine bessere Lösung als die Ringbusse nötig.

 

[Simon]

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.

Ich bin sicher bei AMD sitzen genug findige Ingeneure, die mittels Reverse Engineering und Analysen solche Details rausfinden. Dafür gibt es entsprechende Tracing-Tools. Nur mal eben kopieren ist halt nicht. So eine grundlegende Änderung im Design dauert 4-7 Jahre vom Reißbrett in die Massenproduktion.

AMD wollte mir Ryzen ein "billige" Lösung haben, um möglichst einfach die Anzahl der Kerne skalieren zu können, ohne ständig neue Masken auflegen zu müssen. Auch wird man sich bewusst sein, dass sich die gängigen Auftragsfertiger mit nativen 600 mm² DIE-Monstern im hohen Taktbereich in der Massenproduktion etwas schwerer tun. GPUs sind keine Referenz, da deutlich einfacher ausgelegt und wesentlich niedriger getaktet. IBMs POWER-CPUs ebenfalls nicht, verglichen mit einem Xeon/Core i werden hier bedeutungslose Stückzahlen produziert.

Dafür muss man halt mit Einschränkungen (CCX Latenzen) leben.

Das stimmt, trotzdem ist es ein klarer Gegenentwurf zu dem Ansatz den AMD realisiert hat.
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.
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.

Dafür gibt es das BIOS. Dort sind alle relevanten Infos gespeichert. Jedes größere OS hat entsprechende Anpassungen auf verschiedene Hardware-Plattformen. Siehe u.a. das Core-Parking bei Windows 10. Dort wird schon entsprechend geschaut, dass möglichst viele Tasks im Leerlauf auf möglich wenige Threads gelegt wird, damit möglichst viele Kerne pennen gehen können. Kein Hexenwerk.

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.

Es ist völlig Banane, die Hardware an die Software auszurichten. Es gibt weltweit Millionen an Software-Binaries, jedoch nur einige Dutzend CPU-Technologien. Was ist wohl einfacher? Eine Hardware zu entwickeln, die sich an Millionen verschiedenster Software anpasst, als die Software auf ein paar Architekturen zu optimieren?

Vergleich doch mal die ersten Spiele auf der Playstation 1 und die letzten ihrer Art. Da liegen grafisch Welten zwischen. Würde man jetzt jegliche Hardware im Entwicklungsstand einfrieren, würde der Softwarestack noch über Jahre hinweg etliche Prozente an Performance rausholen können. Heute wird bei der Software fast alles über irgendwelche Abstraktionsschichten und Hochsprachen soweit von der Hardware entkoppelt, was das ganze zwar kompatibel und portabel macht, jedoch in der Abstraktionsschicht ein entsprechender Overhead erzeugt. Würde man kritische Funktionen wieder vermehrt nativ auf eine bestimmte Hardware zurechtschneidern, wird man sicher wundern, was sich da noch rausholen lässt.

Aber heute geht in der Entwicklung (abgesehen von vielleicht HPC-Anwendungen) halt Schnelligkeit in der Entwicklung & Kompatibilität vor reiner Performance.

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!

Das wird schon auf weit höheren Leveln abstrahiert. Da gibt es dann in der SQL-Tabelle einen entsprechenden Lock auf die Zeile/Spalte und fertig. Das wird nicht auf CPU-Level gesetzt.

 

[Holt]

Ich zweifel daran, dass die bei AMD da jetzt absolut keinen Plan haben wie das funktioniert.

Natürlich dürfte auch AMD Ideen haben wie man sowas macht und es hat sicher auch Überlegungen in diese Richtung gegeben, keine Frage.

Eher ist der Mesh für sie momentan uninteressant, da sie auf den Zeppelin-DIE setzen um damit momentan wirtschaftlicher zu produzieren.

Eben, zumal die Fabric ja auch viel besser zu dem Konzept passt CPUs mit vielen Kernen auf der Basis mehrere Dies der Mainstream CPUs zu realisieren, was die Time-to-market deutlich senkt und obendrein kostet die Entwicklung gerade so großer Dies viele Hundert Millionen, was bei dem derzeitigen Marktanteil von unter 1% auf dem Servermarkt gar nicht zu rechtfertigen wäre. Keine kann garantieren das die Absatzzahlen so stark steigen werden, dass sich diese Geld wieder einspielen ließe.

Also hat AMD lieber ein Design gewählt welches das Risiko gering hält weil es weit geringere Investitionen erfordert, auch wenn dies eben an anderen Stellen Nachteile hat und man damit nicht bei jeder Anwendung mit Intels CPUs mithalten kann. Bei anderen Anwendungen kann man dafür den Vorteil der vielen Kerne ausspielen, von denen man wegen des einfacheren Designs mit CCX und einer Fabric auch mehr auf dem gleichen Platz unterbringen und diese über mehrere Dies verbinden kann, also mehr Kerne pro Sockel bekommt. Damit hat AMD Intel wirklich kalt erwischt, da es eigentlich deren Strategie war CPUs mit hohen Kernzahlen auf den großen LGA3647 für Dual-CPU Systeme zu beschränken.

 

[ampre]

Das mit dem Mash könnte ein Problem werden für Intel. Das Mesh macht den Chip wahrscheinlich sehr schnell ABER: So ein Mesh ist sehr komplex und dürfte bei so einem großen Chip die Ausbeute erheblich Senken.

AMD mit Ihren CCX Design werden zwar nicht die Leistungskrone damit erringen. Aber dafür könnten die Chips gut um die Hälfte billiger sein als die Chips von Intel. 4 kleine Chips auf einem Interposer sind weitaus besser als 1 Megachip.

Mal sehen was als nächstes kommt. Es bleibt ja nur noch übrig jeden Core mit jedem andern zu Verbinden. Das würde die Die Size dann aber sprengen.

 

[Dark Soul]

... müsste er bei RYZEN und Derivaten auch noch wissen welches Kern zu welchem CCX gehört? Welches API informiert darüber? ...

Wenn man bei den CPU Pfaden den "Device Instance Path" und die "Bios device name" anschaut sieht man dies (Beispiel 5820k):

ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_0 --> \_SB.SCK0.CP00
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_1 --> \_SB.SCK0.CP06
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_2 --> \_SB.SCK0.CP01
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_3 --> \_SB.SCK0.CP07
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_4 --> \_SB.SCK0.CP02
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_5 --> \_SB.SCK0.CP08
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_6 --> \_SB.SCK0.CP03
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_7 --> \_SB.SCK0.CP09
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_8 --> \_SB.SCK0.CP04
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_9 --> \_SB.SCK0.CP0a
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_a --> \_SB.SCK0.CP05
ACPI\GenuineIntel_-_Intel64_Family_6_Model_63_-_Intel(R)_Core(TM)_i7-5820K_CPU_@_3.30GHz\_b --> \_SB.SCK0.CP0b

Diese Infos kann man in c++ oder anderen sprachen über die System libs holen.

Die ersten 6 Cores im Bios sind die physischen Kerne, also 00 - 05, 06-0b sind logische Kerne (SMT). Auch sieht man hier das Windows dies anders anordnet. Gerade Core Identifier inkl. 0 sind physische, ungerade Kerne sind nur logische Kerne.

Ich nehme mal an, dass dies auch schon eine Optimierung von Windows ist. Bei AMD wird dies gleich sein. Somit werden wenn man eine 16-Kern CPU hat, die Cores mit den Bios device names CP00-CP03 - physisch und CPa0-cpa3 - logisch im gleichen CoreCluster sein. Soviel ich weiss, hat ja Microsoft angekündigt sich um die "CCX issues" zu kümmern.

Über alle CPU Architekturen hatte man ja schon ziemlich alle Bus Technologien durch^^ Bei älteren FSB Implementationen konnte ja zB nur ein Kern gleichzeitig auf den Memory Controller zugreifen.

Mit dem Ringbus wurde der Diameter (Distanz zwischen den zwei grössten Nodes im Netzwerk) bei einer hohen Anzahl Kerne sehr gross. Ist ja immer n/2 wenn n die Anzahl nodes im Netzwerk ist. Wenn Intel einen zweiten Ring einführt, bleibt der Diameter gleich, einzig die Anzahl Kollisionen werden (in einer perfekten Welt um Faktor 2) verringert.

AMDs Anzahl mit der Infinity Fabric hat an sich die effizienteste Netzwerk Implementierung die es gibt. Genutzt wird nämlich eine Crossbar (Diameter ist 1). Also kann man von "überall" nach "überall" ohne erhöhte wegkosten "durchgeschaltet" werden. Zu Kollisionen kann es hier nur kommen, wenn zwei gleiche Quellen auf das selbe Ziel zugreifen möchten. Wenn jede Quelle auf ein anderes Ziel zugreifen möchte, geschieht dies parallel. Nur leider kostet der Zugriff bis man auf der Crossbar ist, angeblich ein paar Taktzyklen. Oder AMD nennt das ganze Marketingmässig einfach Crossbar und es handelt sich in Tat und Wahrheit um ein Omega-Netzwerk. Dazu kommt, dass eine Crossbar mit Faktor n^2 in der Komplexität wächst. 8 Kerne untereinander direkt verbunden brauchen bereits 64 "Schalterelemente". Hier würde das Omega-Netzwerk wieder Abhilfe schaffen Solange wir nicht die Blaupausen der CPUs haben finden wir es nie raus

Wie auch immer Es bleibt spannend Nachdem Nvidia mit NVLink einen Hypercube Mesh Hybriden vorgestellt hatte, habe ich mich gewundert wie lange es dauern wird bis Intel / AMD dies auch tun

 

[Holt]

AMD wollte mir Ryzen ein "billige" Lösung haben, um möglichst einfach die Anzahl der Kerne skalieren zu können, ohne ständig neue Masken auflegen zu müssen.

Das ist offensichtlich und in der Situation in der AMD steckt bzw. gesteckt hat als das Projekt entwickelt wurde, war dies wohl auch alternativlos, zumal es im Serverbereich viel länger dauer wieder Fuß zu fassen als bei den Desktops, vor allem bei Selbstbauern die aktiv in Computerforen unterwegs sind.

Auch wird man sich bewusst sein, dass sich die gängigen Auftragsfertiger mit nativen 600 mm² DIE-Monstern im hohen Taktbereich in der Massenproduktion etwas schwerer tun. GPUs sind keine Referenz, da deutlich einfacher ausgelegt und wesentlich niedriger getaktet.

Wobei es mich nicht wundern würde, wenn auch künftige AMD GPUs auf dem gleichen Konzept beruhen werden und als MCM kommen, immerhin will AMD auch dort die Fabric einführen und so würde man auch noch die Fertigungskosten massiv senken. Obrendrein sind GPUs optimal für so ein Konzept, rechnet dort doch jede Einheit weitgehend unabhängig für sich auf einen Teil der Daten rum.

Dafür muss man halt mit Einschränkungen (CCX Latenzen) leben.

Eben TANSTAAFL!

Dafür gibt es das BIOS. Dort sind alle relevanten Infos gespeichert.

Wie kann man diese auslesen? Core-Parking ist ein generelles Feature der CPU und nicht nicht das gleiche wie die Geometrie der CPU bzgl. der Anordnung der Kerne. Wenn DU die ganze Methode der Abfrage nicht kennst, dann gibt es sie entweder nicht oder andere kennen sie auch nicht, was auf das Gleiche hinausläuft. Die üblichen API Funktionen geben nur aus welche Kerne es gibt und zu welchem NUMA Node sie gehören, aber nicht zu welchem CCX einer RYZEN CPU oder welche ein Nachbar von welcher an einem Ringbus (künftig Mesh) bei einer Intel CPU ist.

Core-Parking bei Windows 10. Dort wird schon entsprechend geschaut, dass möglichst viele Tasks im Leerlauf auf möglich wenige Threads gelegt wird, damit möglichst viele Kerne pennen gehen können. Kein Hexenwerk.

Klar, denn der Task Scheduler des OS bestimmt ja auch welche Threads / Prozesse auf welchem Kern laufen, daher weiß er auch welche nicht benötigt werden. Aber weiß er wer der Nachbar von wem ist?

Es ist völlig Banane, die Hardware an die Software auszurichten.

Nein ist es nicht, es dauert eben viele Jahre wenn man umgekehrt versuchen würde und sehr viele Entwickler und Firmen müssten da mitspielen, die CPUs kommen für x86er SW nur von zwei Fimen: AMD und Intel.

Es gibt weltweit Millionen an Software-Binaries, jedoch nur einige Dutzend CPU-Technologien. Was ist wohl einfacher? Eine Hardware zu entwickeln, die sich an Millionen verschiedenster Software anpasst, als die Software auf ein paar Architekturen zu optimieren?

Dutzende CPU Technologien nur, wenn man weiter in die Vergangenheit geht, den x86er SW läuft nur auf x86er CPUs und davon gibt es längst nicht so viele Dutzend die noch aktuell in größerem Umfang genutzt werden. Millionen von Programmen anzupassen ist unmöglich, die meisten dürften zwar noch genutzt, aber gar nicht mehr weiterentwickelt werden. AMD ist schon bei den APUs mit dem Versuch gescheitert die Vorteile seines HW Konzepts durch angepasste SW endlich mal ausspielen zu können.

Vergleich doch mal die ersten Spiele auf der Playstation 1 und die letzten ihrer Art. Da liegen grafisch Welten zwischen.

Der Vergleich hinkt, denn dabei geht es es um SW für eine spezielle HW und obendrein entwickelt sich SW natürlich auch weiter um die Möglichkeiten der HW nutzen zu können, wenn eben auch meist mit einer deutlichen Verzögerung. Zeitnah passiert sowas nur, wenn man besondere Aufgaben hat die man anderes nicht sinnvoll lösen kann oder eben wie bei Konsolen, sowieso an fixe HW gebunden ist und dann für eine neue Version dieser HW etwas bringen muss was deren neue Möglichkeiten nutzt damit man wieder neue Versionen verkaufen kann.

Würde man jetzt jegliche Hardware im Entwicklungsstand einfrieren, würde der Softwarestack noch über Jahre hinweg etliche Prozente an Performance rausholen können.

Klar, aber mit welchem Aufwand? Schon vor 30 Jahren war das Motto: Wenn ihnen die SW nicht schnell genug läuft, dann kaufen sie sich doch schnellere HW!

Heute wird bei der Software fast alles über irgendwelche Abstraktionsschichten und Hochsprachen soweit von der Hardware entkoppelt

Was aber auch den Vorteil hat, dass man dann an weniger Stellen mit Optimierungen oft viel erreichen kann.

wird man sicher wundern, was sich da noch rausholen lässt.

Nur würde dies kaum jemand bezahlen wollen, bzw. eben nur bei wenigen Anwendungen wo es wirklich viel mehr Geld sparen kann, als man reinstecken muss (z.B. bei HPC) oder wo keine den Aufwand des Entwicklers entsprechend entlohnen muss, also z.B. bei Open Source oder im Akademischen Bereich.

Da gibt es dann in der SQL-Tabelle einen entsprechenden Lock auf die Zeile/Spalte und fertig. Das wird nicht auf CPU-Level gesetzt.

Wenn Du meist das ein Lock auf einer Tabelle nicht auch ein entsprechende Gegenstück auf der CPU Ebene wie z.B. einen Mutex bewirkt, dann hast Du Dich gerade geoutet von SW Entwicklung nicht wirklich Ahnung zu haben.

 

[ampre]

Ich frage mich ob ein Mesh für eine CPU eigentlich günstig ist. Bei einer GPU ist das klar wegen den vielen parallelen Prozessen. Aber bei einer CPU die hauptsächlich Seriell Daten verarbeitet? Da sollte kaum Interaktion zwischen den Kernen Statt finden.

 

[Holt]

Dark Soul, dies sagt Dir auch auch nicht, welche der Kerne Nachbar am Ringbus sind. Die Kerne eines CCX könnte die SW so vielleicht erkennen, aber sie müsste dazu angepasst werden und die passiert eben nur selten und wenn, nicht selten nur sehr verzögert. Wie weit die Fabric wirklich eine Crossbar ist, ist eine gute Frage, zumindest ist dort nicht jeder CPU Kern einzeln angebunden, sondern wohl nur jeder CCX und dann wäre es auch mit der reinen Crossbar vorbei, wenn zwei oder wie bei Eypc gar vier Dies zusammengebunden werden. Dies dürfte wohl ähnlich wie es für Duial-CPU System passieren soll, dann über die gleiche Verbindungen gehen die auch die PCIe Lanes treiben und damit wäre dann jeder Die nicht viel anderes als ein einzelner Verbindungspunkt an der Crossbar des anderen, nur mit noch höhere Latenz.

Andernfalls wären sehr viel Verbindungen zwischen den Dies nötig und jede erhöht wieder die Leistungsaufnahme. Die Latenz zwischen den Kernen der unterschiedlichen Dies von ThreadRipper wird einen Hinweis wie es gelöst ist, aber ich würde da eine gegenüber den Kernen unterschiedlicher CCX eines Dies nochmal erhöhte Latenz vermuten.

Ergänzung (16. Juni 2017)

Aber bei einer CPU die hauptsächlich Seriell Daten verarbeitet? Da sollte kaum Interaktion zwischen den Kernen Statt finden.

Gerade bei CPUs ist im Vergleich zu GPUs viel Interaktion zwischen den Kernen nötig, wobei das eben von der SW abhängt. Wenn wirklich nur seriell Daten abgearbeitet werden, also nur ein Thread läuft der die CPU auslastet, dann weniger aber in der Praxis trotzdem meist schon deswegen, weil die Scheduler der Betriebssystemen diesen Thread meist regelmäßig auf andere Kerne verschieben und damit die Cacheinhalte ebenfalls verschoben werden müssen. Gerade bei CPUs ist so eine latenzarme Verbindung der Kerne untereinander wie es das Mesh verspricht, also sinnvoll.

 

[MK one]

Wie der Artikel schon sagte , der Ring Bus kam in die Jahre und war am Limit also musste was neues her ... .
Ob das jetzt unbedingt schneller / besser ist wird sich noch erweisen , fakt jedoch ist das sich Dies von der Größe einer 16 Kern CPU eine höhere Ausschussquote haben als 2 8 Kern Dies .

Amd s Data Fabric ist , im Gegensatz zu Intel , jedoch nicht auf die CPU beschränkt man kann ebenso eine GPU einbinden , ende Dezember wird man ja erleben wie gut das dann funktioniert bei Ravenridge , wenn auch erst nur im Note und Ultrabook Bereich .

AMD s Ansatz hat Potenzial , sobald PCIe 4.0 in den CPU s Einzug hält verdoppelt sich nicht nur die Bandbreite , sondern auch die Geschwindigkeit und verringert ( halbiert ? ) damit die Latenz des Data Fabric .

 

[oldmanhunting]

Zwei Firmen und 2 verschiedene Ansätze um ein Problem zu lösen. Testberichten werden uns hoffentlich Antworten geben, ob wir Anwender einen spürbaren Unterschied merken.
Hätte aber jetzt nicht gedacht, dass der doppelte Ringbus von Intel schon limitiert und etwas Neues her muß.

Klar kann man zwei 8 Kerne Dies billiger herstellen als einen 16 Kerne Die. Das ist ja auch der Ansatz von AMD, mit einem Die alles von 4 Core bis 16 Core zu realisieren. Ob billiger auch besser sein wird, werden wir erst wissen, wenn wir unabhängige Benchmarcks sehen. Die Frage ist dann, um wieviel ist Intel mit seinem Ansatz schneller und lohnt sich der Aufpreis dafür?
Da AMD bei seinem 16 Kerner nichts anderes einsetzt als zwei Ryzen 8 Kerner bekommen wir eine erste Antwort, wenn wir den SLX 8 Kerner mit dem Ryzen 8 Kerner vergleichen. Sozusagen Mesh gegen Data Fabric.

 

[HardRockDude]

@Holt
Ich könnte mir vorstellen, dass zum Kennenlernen der Nachbarn und der jeweiligen Distanzen/Lastenverhältnisse ein bisschen von der Netzwerktechnik abgekupfert wird, sprich konkret von Link-State- und Distanzvektoralgorithmen.

 

[Holt]

Ob das jetzt unbedingt schneller / besser ist wird sich noch erweisen

Sonst hätte Intel das wohl kaum eingeführt, die Frage ist eher, bei wie vielen Kerne es wie viel besser ist, ob also auch die Skylake-X mit 8 oder 10 Kernen schon einen Vorteil gegenüber den Broadwell-E mit gleich vielen Kernen haben werden oder der erst bei den CPUs mit deutlich mehr Kernen zum Tragen kommt.

Amd s Data Fabric ist , im Gegensatz zu Intel , jedoch nicht auf die CPU beschränkt man kann ebenso eine GPU einbinden , ende Dezember wird man ja erleben wie gut das dann funktioniert bei Ravenridge

Das muss aber auch nicht automatisch ein Vorteil gegenüber der Anbindung sein wie Intel für seine iGPUs verwendet, der Vorteil liegt wohl eher in der generell besseren GPU von AMD.

Übrigens: Vor dem Komma steht gewöhnlich kein Leerzeichen.

AMD s Ansatz hat Potenzial , sobald PCIe 4.0 in den CPU s Einzug hält verdoppelt sich nicht nur die Bandbreite , sondern auch die Geschwindigkeit und verringert ( halbiert ? ) damit die Latenz des Data Fabric .

Was hat die Fabric von AMD mit PCIe zu tun, außer dass sie die PCIe Lanes bereitstellt? AMD kann intern auch schon längst eine andere Frequenz als für die PCIe Lanes wählen, hat aber den Takt der Fabric an den des RAM angebunden, warum auch immer. Der Test dazu bei Tomshardware zeigt ja deutlich den Einfluss des RAM Taktes auf die Inter CCX Verbindungen, die ja über die Fabric laufen.

Ob billiger auch besser sein wird, werden wir erst wissen, wenn wir unabhängige Benchmarcks sehen. Die Frage ist dann, um wieviel ist Intel mit seinem Ansatz schneller und lohnt sich der Aufpreis dafür?

Eben und da dürfte es nicht schwer werden zu raten wie es ausgehen wird: Immer wenn die Kerne jeder für sich auf einem Teil der Daten arbeiten, wird der ThreadRipper gut bis sehr gut abschneiden, was die Ergebnisse z.B. von Cinebench auf RYZEN ja auch zeigen. Wird aber viel Kommunikation zwischen den Threads nötig, was bei Spielen typischerweise der Fall ist, wird ThreadRipper noch schlecher als RYZEN abschneiden sofern das Spiel nicht darauf optimiert ist, da eben bei mehr CCX auch mehr Kommunikation zwischen den CCX anfallen wird. Das ergibt sich schon aus der Tatsache, dass eben bei RYZEN nur zwei CCX vorhanden sind, statistisch sind also 50% aller Kerne auf dem gleichen CCX, bei ThreadRipper mit seinen 4 CCX aber nur 25%. Dazu dürfte die Verbindung über zwei Dies hinweg eher langsamer sein als die auf dem gleichen Die und dann müssen da noch Daten vom PCIe- und Memorycontroller rüber....

Es wird also sehr von der Anwendung abhängen, mehr noch als schon bei RYZEN, welche CPU beim Duell zwischen ThreadRipper und Skylake-X jeweils die Nase vorne hat.

Ergänzung (16. Juni 2017)

Übrigens zum Thema Corssbar:

Although AMD hasn't confirmed, we suspect that the Infinity Fabric is a single pathway.
...
Repeated tests on our stock Ryzen 5 1600X revealed more run-to-run variance, so these numbers are the average of two test sessions.

Und zu PCIe 4.0:

Wenn der Takt der Infinity Fabric schon heute nichts mit dem der PCIe Lanes zu tun hat und weit darunter liegt, warum sollte das bei PCIe 4.0 anderes werden?

 

[cookie_dent]

Trotz aller Vorurteile hat die Ryzen Architektur in vielen Anwendungen ja bereits gezeigt das sie den Intel Mehrkernern ganz gut Paroli bieten kann. In der Regel können diese Intel´s Sechs- und Achtkernen auf Augenhöhe begegnen.

https://www.computerbase.de/2017-03/amd-ryzen-1800x-1700x-1700-test/3/#diagramm-gesamtrating-anwendungen-windows

Ob die gute Multithreading Leistung vom Bussystem abhänging ist entzieht sich meiner Kenntnis, so tief stecke ich in der Materie nicht drin.

Mich würde der direkte Vergleich von Ringbus gegen Mesh mehr interessieren als der Vergleich mit AMD, denn nur so könnte man eine genauere Aussage darüber machen wie viel ein Mehrleistung moderneres Bussystem wirklich bringt.
Wenn Skylake x schon über Mesh verfügen sollte, wäre der perfekte Leistungsvergleich ja gegeben, denn an der generellen Architektur hat Intel ja noch nicht gravierendd geschraubt.

 

[Roche]

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.

Ja, aber WANN, ist die Frage.

Es ist unbestreitbar, dass AMD mit seinen Ryzen und bald auch Threadripper CPUs, Intel dazu zwingt, auch endlich mal wieder ordentlich eins drauf zu setzen und dem Kunden eben nicht immer nur kleinste Effizienz- und Leistungssteigerungen zu einem Wucherpreis zu verkaufen.

 

[G3cko]

Man müsste erst einmal schauen ob Intel das Mesh beliebig auf mehrere DIEs so wie bei AMD auseinander ziehen kann. Solange dürfte AMD einen guten Vorteil haben. Mit popeliegen 250mm2 kommt man spielend auf 1000mm2. Ob Intel da mitgeht glaube ich nicht.

Ein weiterer Punkt ist, dass die fabric ja nicht nur CPUs sondern auch GPUs anbindet. Ob das über ein mesh wie bei Intel sinnvoll wäre kann ich nicht beurteilen. Man wird sich wohl was da du gedacht haben.

 

[HominiLupus]

In der Welt dicker Server und High Performance Computing gibt es keine Spezialfälle. Es finden sich in der Regel immer Abnehmer

Das nicht aber es gibt keinen Markt (der Martkanteil dieser dicken Server und HPC muss man fast mit der Lupe suchen) trotzdem Kosten. Wenn also Intel für alle Brot+Butter 6-8 Kerner teure Meshes fabben muss nur damit die teuren aber kaum verkauften 18Kerner gut dastehen ist es in der Summe in Minusgeschäft. So was in der Art 20% Mehrkosten um 5% mehr Performance zu bekommen ist nicht immer ein guter Tausch. Oder nutzen die 6-10 Kerner trotzdem noch den Ringbus? Ist ja ein anderes Die.

AMD geht hingegen einen anderen Weg: die fassen 4 Kerne zusammen und machen dann Interconnect für diese 4, Intel hat für jeden Kern einen Interconnect zu den anderen Kernen, der aber vielleicht mehrere Stationen durchlaufen muss: jede Station mehr Latenz.

Was wären denn übergroße Anwendungsfälle von denen die Intel Herangehensweise profitiert? Kennt jemand Benchmarks die diese Unterschiede dann zeigen, als 18 "enger gekoppelte Kerne via Mesh" hier und "4 Kerne schnell gekoppelt und dann losere Kupplung von solchen 4Kern Modulen" da?

 

[ptysiu]

Ich finde den Ansatz von Intel aus mathematischer Sicht sehr spannend und wie bereits ausgeführt diametral zum Ansatz von AMD. Im Prinzip ist Intel zu einer Punkt zu Punkt Verbindung gewechselt, anstatt einen kleinen Bus um die Kerne zu jagen. Jeder darf einsteigen und aussteigen wo er will, aber es werden immer alle Haltestellen angefahren. Als ein Bus nicht reichte, hat man zwei eingeführt und später sogar einen Busbahnhof. Natürlich führt das zu Verzögerungen und ist jetzt anscheinend an seine Grenzen gestoßen.
Idealerweise wäre natürlich eine direkte bidirektionale Verbindung zwischen jedem Core, aber den Verschaltungsaufwand wächst ja bei exponentiell (2 Kerne= 2 Verbindungen, 4 Kerne = 12 Verbindungen, 6 Kerne = 24 Verbindungen usw.). Von daher nicht sinnvoll / praktikabel. es sei denn jemand schafft es die Mathematik zu überlisten. Spannend ist auch wie sie das interne Routing gelöst haben, denn jetzt führen ja mehrere Wege von einem Core zum anderen.
Ich bin auf der Ergebnis gespannt, und inwieweit die wesentlich kürzeren Latenzen auswirken. Auch wenn es erst mal nur für den Serverbereich angedacht ist werden wir es mit wachsender Kernzahl bestimmt auch im Consumerbereich sehen.

 

[pipip]

Das mit dem Mash könnte ein Problem werden für Intel. Das Mesh macht den Chip wahrscheinlich sehr schnell ABER: So ein Mesh ist sehr komplex und dürfte bei so einem großen Chip die Ausbeute erheblich Senken.

AMD mit Ihren CCX Design werden zwar nicht die Leistungskrone damit erringen. Aber dafür könnten die Chips gut um die Hälfte billiger sein als die Chips von Intel. 4 kleine Chips auf einem Interposer sind weitaus besser als 1 Megachip.

Mal sehen was als nächstes kommt. Es bleibt ja nur noch übrig jeden Core mit jedem andern zu Verbinden. Das würde die Die Size dann aber sprengen.

Der Vergleich Mesh gegen AMDs Fabric Bus ist auch ein bisschen aus den Kontext gezogen. Man sollte nicht vergessen, dass AMD die Technologie auch für GPUs nützten will und ebenso auch gemischt performen soll. "APU".
Auch hier muss Mesh dann zeigen, wie gut es im Vergleich zu AMD's Lösung ist.
Ebenso ist der Fabric von AMD nicht dumm. AMD hat ja oft genug erwähnt, dass im Vergleich zum Vorgänger (HyperTransport) noch sehr viele weitere Protokolle dazugekommen sind.
Der nächste Schritt für bessere Kommunikation zwischen den CCX (egal ob jetzt CPU, GPU, Chipsatz) wird sicherlich auch ein Multiplikator und andere Technologien sein. Wir haben bisher auch nur die 1Gen von Fabric gesehen.