Informationen zu Naples-Prozessoren mit 16 und 32 Kernen (Update)

BTT:
Dieser Bench dürfte einem 16C/32T ziemlich gut schmecken, weil hier der 6900k auch heftig dropt. Glaubt man nicht, ist aber so. Hier haben 4C/8T schon lange die Segel gestrichen.

hit-4k-ft1800kvs6900k8oxoc.png
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ob solche Gerüchte irgendwas "klären" darf bezweifelt werden. 16-cores sieht für mich eher nach Server aus, weniger nach Desktop. Auch wenn canar das als "Ryzen" tituliert.
 
Woher kommt das Märchen mit der CCX Kommunikation?

Es ist nur eine Theorie, aber aktuell die Schlüssigste.
Bevor du wieder irgendwelche Youtube Videos postest, welche 0 Zusammenhang mit Naples, will ich nur anmerken:

Ich habe hier eine 3930K Workstation und einen Ryzen 1700X in Betrieb. In gewissen Anwendungen ist der 1700x doppelt so schnell, aber überall wo man eine starke Abhängigkeit zwischen den Threads hat, ist die CPU sogar langsamer als der 3930K.
 
Aber bitte nicht mit AVX512, weil da ist Ryzen langsamer, und da war schon von vorn herein klar.
 
Wenn eine App dem Ryzen nicht schmeckt dann soll man es bitte nicht erwähnen da sowieso klar, aber wenn ein 6900K dropt und das nicht wirklich schlechter als ein Ryzen, dann ist das eine Sensation wert. Ernsthaft? Warum darf man das eine aber das andere nicht? Der Hitmanbench hat doch schon wieder einmal nichts mit dem Thread zu tun. Ich sehe da noch nicht mal einen Vorteil einer CPU. 1mal unter 10Fps gilt für alle nicht Spielbar.
 
Mal schauen was da kommt. Wenn AMD Geld verdienen will, müssen sie mindestens zwei Sockel unterstützen. Man wird aber schauen müssen, was AMD wirklich liefern wird. Wenn das nur zusammengesetzte Ryzen Dice sind, dann relativiert sich das ganze doch sehr stark. Ryzen R7 ist wirklich gut, aber meine Erfahrungen mit AMD Opterons sind ziemlich schlecht. Die Speicherbandbreite macht sich nämlich bei vielen Anwendungen bemerkbar. D.h. es macht definitiv einen Unterschied, ob die CPU 2xDual Channel oder ein natives Quad Channel Interface hat. Das fällt nicht so sehr im Desktop Betrieb auf, aber wenn man anfängt die Kisten als Server zu quälen wird das zu einem Problem. Und das Programmieren macht es auch nicht leichter.

Die Opteron 6100 hatten immer ein Problem mit dem IO gehabt. Die Opteron 6200 waren etwas fixer, aber die Xeon 5600 haben sie immer beim IO klar auf die Plätze verwiesen, und das ganze mit Offloading und RDMA fähigen Infinibandkarten.
 
AMD muss die Latenz, angezeigt durch obiges Schaubild, reduzieren.
Genau da liegt der Hase im Pfeffer, aber das ist eben der Preis des Konzeptes mit den CCX, die erlauben dafür sehr einfach mehr Kerne zu realisieren.
Die Cores wie ein Multi CPU Sockel System zu behandeln würde Vorteile wie auch Nachteile bedeuten.
Klar, das hatte ich ja geschrieben, denn dann würde man zwar die Wechsel der Threads zwischen den CCX vermeiden, aber gerade viele bei Heimanwendern eingesetzte SW würde nur einen CCX nutzen, die anderen 8 Kerne wären dann nur mit einem zweiten Programm sinnvoll zu nutzen, welches eben parallel läuft. Das kommt bei Heimanwendern aber eher selten vor, daher hat AMD darauf wohl auch verzichtet und deklariert alle Keine als zu einem Node gehörend.
DDR4 4000+ könnte die Kommunikation deutlich beschleunigen.
Aber eben weil der Takt der Fabric am RAM Takt hängt, da hätte man die Teiler der Taktraten unabhängig voneinander gestalten müssen um für die Fabric immer einen hohen Takt realisieren zu können. Man kann nur raten wieso dies nicht gemacht wurde, aber ich denke wird hier man beim ersten Update der Architektur dann auch Änderungen sehen, zumal DDR4 4000 ja wohl schon gar nicht möglich ist und RYZEN generell nur geringe RAM Takte erlaubt, zumal wenn man mehr RAM verbaut und daher Dual-Rank RAM nimmt (Single Rank gibt es nur bis 8GB pro Riegel) oder gar beide RAM Slots nutzt.

Mittlerweile kann ich meinen Ram mit DDR3 3200 betreiben und kann somit das Problem ein wenig abfedern.
Die Gamingleistung geht mit schnellem Ram deutlich nach oben.
Weit mehr als bei Intel CPUs und bei einer CPU mit L3 Cache zu erwarten wäre, hier dürfte klar der Vorteil durch den damit auch höheren Takt der Fabric kommen.
Also erstmal ist die prozentuale Auslastung egal, Grafikkarten und Prozessoren haben da bei idealer Nutzung der Cores im optimalen Fall immer 99%.
Das beide nahe bei 100% liegen ist unwahrscheinlich, dann hätte man die CPU und GPU Performance perfekt ausbalanziert, aber in der Realität wird eher einer immer nahe 100% sein und der andere deutlich darunter, da eben immer entweder die CPU oder die GPU die fps limitert.
Im Zweiten Video ist auch kein Battefield1, ich denke was in deiner Signatur steht, stimmt nicht.
Fanboygebrabbel erster Güte.
Deshalb ignoriert man solche Leute auch, denn von denen kommen nur Fake News und "alternative Fakten", Sachlichkeit oder gar Wissen zu erwarten wäre Fehl am Platz. So z.B. als Kommentar zum i7-3930K (Einführungsdatum: Q4'11) von blubb0r87:
Aber bitte nicht mit AVX512, weil da ist Ryzen langsamer, und da war schon von vorn herein klar.
Dabei reicht ein Blick auf wikipedia:
Der alte i7-3930K hat nicht mal AVX2 welche RYZEN immerhin hat, geschweigen denn AVX-512, welches RYZEN gar nicht unterstützt, da also nicht nur langsamer ist, sondern es nicht bietet! Aber da kaum jemand einen passenden "Knights Corner" Xeon Phi oder gar den noch gar nicht käuflichen (google und andere große Jungs haben den schon) Syklake Xeon E5/E7 Zuhause haben dürfte, war der Kommentar nur sinnfrei und unpassend.
Mal schauen was da kommt. Wenn AMD Geld verdienen will, müssen sie mindestens zwei Sockel unterstützen.
Zwei Sockel waren schon länger klar, den AM4 für den Heimanwender und den große SR3 für die Napels Server CPUs mit bis zu 32 Kernen. Es war aber auch klar, dass dazwischen eine große Lücke klafft die ebenfalls früher oder später gefüllt werden dürfte und wohl eher früher als später auch gefüllt werden wird.
Man wird aber schauen müssen, was AMD wirklich liefern wird. Wenn das nur zusammengesetzte Ryzen Dice sind, dann relativiert sich das ganze doch sehr stark.
Alle Gerüchte deuten stark in diese Richtung, zumal ja wohl selbst die Napels 32 Kerner einfach nur aus 4 Dies der 8 Kern RYZEN CPUs bestehen werden, da wird man dann keinen nativen 16 Kern Die extra für den mittleren Sockel entwickeln, zumal AMD Resourcen sowieso beschränkt sind und es ja offensichtlich gleich in Konzept des Dies eingebaut wurde, diesen auch mit anderen zu verbinden und dann als MCM zu vermarkten. Die Kostenvorteile sind halt gewaltig, wenn man mit einem Die vom 4 Kerner bis zur 32 Kern CPU alles realisieren kann, während bei Intel alleine 3 verschiedene Dies für den S.2011-3 entwickelt, getestet und gefertigt werden müssen, aber während bei AMD bis zu 300 Leute dafür im Einsatz waren, dürften bei Intel ähnlich viele nur für einen neuen Netzwerkchip beschäftigt werden. :banana:
es macht definitiv einen Unterschied, ob die CPU 2xDual Channel oder ein natives Quad Channel Interface hat. Das fällt nicht so sehr im Desktop Betrieb auf, aber wenn man anfängt die Kisten als Server zu quälen wird das zu einem Problem.
Im Desktop ist es klar, da kommt es meist darauf an, dass eine Anwendung schnell läuft, im Server hängt es sehr von der jeweiligen Anwendung ab, die muss für AMDs RYZEN CPUs eben NUMA aware sein, nur weil die CCX als mehrere NUMA Nodes konfiguriert werden, vermutlich werden dies nicht einmal die beiden Dies des 16 Kernes sein, sondern weil eben typsicherweise SW die NUMA aware ist die einzelnen Kerne mit Aufgaben auslastet wo diese weitgehend unabhängig voneinander an einem Teil der Daten arbeiten und wenig Kommunikation unter ihnen erforderlich ist. Eben genau was die Schokoladenseite von RYZEN ist.
Und das Programmieren macht es auch nicht leichter.
Es hängt von der Natur der Aufgabe ab, ob es leicht, schwer oder gar unsinnig ist. Wenn die Aufgabe erfordert das die Kerne ständig interagieren müssen, dann kann ich bei NUMA nur die Kerne eines Nodes nutzen, sonst bremsen die zusätzlichen Kerne des/der anderen Nodes die Ausführung nur aus. Man kann nicht jede Aufgabe so zerlegen, das man auf den Kernen jedes NUMA Nodes sinnvoll Berechnungen anstellen kann, denn sinnvoll ist das nur, wenn es auch so viel unabhängig von anderen Dingen zu berechnen gibt, dass dies den Zeitverlust der Kommunikation zwischen den Nodes auch überkompensiert.

Da könnte man bei RYZEN vielleicht feintunen, wenn die CCX als eigene NUMA Nodes deklariert wären, weil die Nodes untereinander schneller angebunden sind und wohl selbst die CCX unterschiedlicher Dies der MCM CPUs dann noch weniger Latenz als die CPUs echter Multi-CPU Sockel Systeme haben dürften, aber dafür müsste man dann erstmal wissen, welcher Kern nun zu welchem CCX gehört, aber die werden ja eben nicht als zu unterschiedlichen NUMA Node gehören deklariert, der Entwickler müsste dies aufgrund der CPU Bezeichnung wissen. Bei kommerzieller SW wird das daher wohl keiner machen, den Aufwand sowas zu Pflegen bindet sich doch keiner wegen der paar Systeme ans Bein.

Die Opteron 6100 hatten immer ein Problem mit dem IO gehabt. Die Opteron 6200 waren etwas fixer, aber die Xeon 5600 haben sie immer beim IO klar auf die Plätze verwiesen, und das ganze mit Offloading und RDMA fähigen Infinibandkarten.
Damals war ja meine ich die PCIe Lanes noch nicht direkt in der CPU sondern wie bei AM3 noch in der Northbridge. Aber ja, die MCM CPUs auf Basis von RYZEN wie Napels werden natürlich bei der PCIe Performance immer dann unter der Latenz der Anbindung leiden, wenn die SW auf einem Kern eines Dies läuft, aber die HW an PCIe von einem anderen Die hängt. Selbst Intel S.2011-3 CPUs haben bei schnellen PCIe SSDs bei 4k QD1 Nachteile gegenüber den kleinen S. 1151 4 Kernern, denn da muss alles über die Doppelringe und auch wenn die Bandbreite von denen sehr hoch ist, die Latenz ist größer und vor allem auch nicht einmal für alle Kerne gleich.

Es ist eben ein Nachteil vieler Kerne in einer CPU, die Kommunikation unter ihnen wird halt sehr komplex und aufwendig, so aufwendig, dass man eben einfachere Lösungen als die direkte Anbindung jedes Kerns an jeden anderen finden muss um den Aufwand und damit auch die Leistungsaufnahme im Griff zu behalten und damit entstehen Latenzen und ggf. auch Flaschenhälse. Intel soll ja bei den großen Skylake Xeons die Doppelrings durch etwas neueres, besseres ersetzt haben, bin mal gespannt was das ist und wie sich das verhält, aber auch bei Intel gab es schon Überlegungen die großen Vielkern CPUs künftig als MCM auch mehreren kleinen Dies statt aus einen sehr teuer zu fertigendem großen Die zu bauen. Nachdem AMD bei den IPC zumindest mal aufgeholt hat, dürfte man bei Intel nun aber darauf bedacht sein den Vorteil den man hat sobald viel Kommunikation zwischen den Kernen nötig ist, nicht aus der Hand zu geben und AMD dürfte alles daran geben auch in der Hinsicht zu Intel aufzuschließen. Wie weit dies gelingt und wie weit es das Konzept überhaupt erlauben wird, müssen wir abwarten, aber im Moment ist die Sache jedenfalls eindeutig so, dass man entsprechend der Nutzung eben abwägen muss, welche CPU besser passt.
 
Gibt für den vernünftigen Unternehmer mit größeren Datenbanken keine Alternative zu AMD.
 
Wie viele Node meldet ein RYZEN System? Wenn es einer ist, liegt die Schuld wenn die Threads ständig zwischen den Kernern verschiedener CCX verschoben werden nicht bei Microsoft, sondern beim Hersteller des Boards bzw. BIOS!

Kann es sein dass du da irgendwas missverstehst?
NUMA bedeutet in diesem Zusammenhang das Zusammenspiel zwischen Speicher/Speicheranbindung und CPU Cores. Bei Ryzen 7 ist das ein NUMA Node. Ein "Satz" von Cores mit einer Speicheranbindung.

Ein Microsoft Windows unterscheidet im übrigen zwischen SMP und NUMA... SMP ist quasi klassisches Multiprozessoring, genau so wie bspw. ein stino multi-Core Prozessor mit einer RAM Anbindung.
Das "Problem" von Ryzen ist, dass es als SMP gehandelt wird, aber mit gleich über alle Recheneinheiten funktioniert... Mit NUMA hat das perse erstmal weniger zu tun.

Im Desktop ist es klar, da kommt es meist darauf an, dass eine Anwendung schnell läuft, im Server hängt es sehr von der jeweiligen Anwendung ab, die muss für AMDs RYZEN CPUs eben NUMA aware sein, nur weil die CCX als mehrere NUMA Nodes konfiguriert werden, vermutlich werden dies nicht einmal die beiden Dies des 16 Kernes sein, sondern weil eben typsicherweise SW die NUMA aware ist die einzelnen Kerne mit Aufgaben auslastet wo diese weitgehend unabhängig voneinander an einem Teil der Daten arbeiten und wenig Kommunikation unter ihnen erforderlich ist. Eben genau was die Schokoladenseite von RYZEN ist.

NUMA awere Software ist selten, im Desktop Bereich quasi gar nicht anzufinden und im Serverbereich auch eher selten... Das liegt einfach daran, es besteht heute einfach abseits vom HPC Markt quasi gar kein Bedarf danach. Die Masse der Software kommt von der Stange. Und die Masse der Software wird auf VMs betrieben. Und diese VMs laufen zu "vielen" auf irgendwelchen Single/Dual NUMA Node Blechen. Es reichen maximal 2x VMs um potentiell eine Dual CPU Maschine mit 2x NUMA Nodes voll auszufahren. Und DAS ist wohl in der Praxis selten anzutreffen. Da rechen wir eher über 10-30 VMs pro "Node"...

Leider hat sogut wie keiner der privaten User verstanden, was das Problem an NUMA überhaupt ist. Alle sehen se nur die Cores und das SI und freuen sich ein Loch in den A... Die Enttäuschung kommt dann am Ende mit den Benches :fresse:

Es hängt von der Natur der Aufgabe ab, ob es leicht, schwer oder gar unsinnig ist. Wenn die Aufgabe erfordert das die Kerne ständig interagieren müssen, dann kann ich bei NUMA nur die Kerne eines Nodes nutzen, sonst bremsen die zusätzlichen Kerne des/der anderen Nodes die Ausführung nur aus. Man kann nicht jede Aufgabe so zerlegen, das man auf den Kernen jedes NUMA Nodes sinnvoll Berechnungen anstellen kann, denn sinnvoll ist das nur, wenn es auch so viel unabhängig von anderen Dingen zu berechnen gibt, dass dies den Zeitverlust der Kommunikation zwischen den Nodes auch überkompensiert.
Das ist Unsinn... Kerne interagieren nicht, da Software nicht in "Kernen" gehandelt wird. Software handelt mit Threads. Und wie diese Threads interagieren, entscheidet idR der Programmierer bzw. durch konkrete Umsetzungen des Programmierers die Software selbst, weil/wenn sie dynamisch mit Threads arbeitet -> was gängige Praxis ist.

Gibt für den vernünftigen Unternehmer mit größeren Datenbanken keine Alternative zu AMD.

Kannst du mal mit diesem Quatsch aufhören?
Ich sehe kein einziges AMD Serverprodukt am Markt im Moment was auch nur ansatzweise diese Aussage untermauern würde... Und was kommen wird? Das wird sich zeigen...
Was ich aber sehe ist, dass es heute schon ein 8P zu je 24C Broadwell-E System zu kaufen gibt -> und "vernünftige Unternehmer mit größeren Datenbanken" bei AMD im Moment absolut gar keine Alternative dazu haben, wenn man GANZ oben im Regal einsteigen _muss_... Das wird sich mit Naples auch nicht ändern, da bei 64C/128T schluss ist
 
Da machen auch die Gerüchte zuletzt Sinn, dass Intel geplante 2017er Produkte canceln könnte. Einen KBL-X für LGA 2066 wird niemanden vom Hocker hauen, der bereits KBL für LGA 1151 besitzt, und auch noch übertaktet hat. Und SKL-X mit maximal 10 Kernen dürfte kaum Land gegen einen 16-Kern Ryzen (R9 19xx?) sehen.


Und ich dachte AM4 hält Jahre :lol:
Lass doch endlich mal deine sinnfreie Trollerei stecken. Das braucht hier niemand. Oder schalte zumindest mal dein Gehirn für 2 Sekunden ein. AM4 ist eine Mainstream-Plattform, und die wird uns auch noch ein Stückchen erhalten bleiben. Hier geht es um eine Enthusiasten-Plattform, die parallel zu AM4 läuft. Ähnlich wie das bei Intel mit LGA 1151 und 2011/2066 ist.
 
Zuletzt bearbeitet:
Es ging mir nur darum zu zeigen, dass AMD auch nichts zu verschenken hat.
Auf der "normalen" AM4 Plattform werden halt die Mainstream CPUs laufen und mit der aktuellen Architektur wird man da auf 8/16 Core/Threads limitiert sein. D.h. marginale IPC Verbesserungen und ggf. ein paar hundert MHz mehr Takt über die Jahre.
Der Traum von in 2-3 Jahren billig auf 16 Cores aufrüsten ist mit der AM44 Plattform wohl definitiv gestorben.
 
Da machen auch die Gerüchte zuletzt Sinn, dass Intel geplante 2017er Produkte canceln könnte. Einen KBL-X für LGA 2066 wird niemanden vom Hocker hauen, der bereits KBL für LGA 1151 besitzt, und auch noch übertaktet hat.

Mir solls recht sein. D*mme Leute müssen ihr Geld verprassen bis sie keins mehr haben.
Die Ghz/IPC-Keule wird viele Lemmingen wieder dahin treiben.
 
Zuletzt bearbeitet:
Der Traum von in 2-3 Jahren billig auf 16 Cores aufrüsten ist mit der AM44 Plattform wohl definitiv gestorben.
Wieso sollte da irgendwas gestorben sein? Eine Plattform ist nicht auf eine bestimmte Anzahl an Kernen limitiert. Ich könnte mir folgendes Szenario vorstellen:

2017 (14nm): AM4 bis zu 8 Kerne, AM44 bis zu 16 Kerne
2019 (7nm): AM4 bis zu 12/16 Kerne, AM44 bis zu 24/32 Kerne

Limitiert ist eine Plattform eher auf andere Faktoren, wie zB I/O. AM4 ist maximal Dual-Channel. Und das wird auch so bleiben. Wer also Quad-Channel braucht, wird damit nicht glücklich werden. Egal ob heute oder in zwei Jahren.
 
Kann es sein dass du da irgendwas missverstehst?
NUMA bedeutet in diesem Zusammenhang das Zusammenspiel zwischen Speicher/Speicheranbindung und CPU Cores. Bei Ryzen 7 ist das ein NUMA Node. Ein "Satz" von Cores mit einer Speicheranbindung.
Missverstanden hast nur Du und zwar alles, denn natürlich ist ein 8 Kerner RYZEN nicht ein klassischer NUMA 2 Node, aber halbwegs schon, weil NUMA nämlich auch bedeutet, dass die Kommunikation zwischen den Nodes eben viel langsamer ist als zwischen Kernen des gleichen Nodes und genau das ist bei RYZEN wegen der CCX ja auch gegeben, unabhängig vom gemeinsamen RAM Interface und bei den MCM CPUs wie Naples wird des noch deutlicher der Fall sein, weil da jedes Die 2 eigene RAM Kanäle verwaltet.

Da so eine Architektur neu ist, kann man dafür keine passende SW Unterstützung finden, NUMA passt aber am Besten zu dem Problem. Letztlich wäre die Konsequenz für die SW auch die gleiche, nämlich entweder nur auf den Kernen eines "Nodes" aka CCX zu laufen oder eben die größere Latenz bei der Kommunikation zwischen den Kernen andere CCX in Kauf zu nehmen, einen dritten Weg gibt es nicht.
Das ist Unsinn... Kerne interagieren nicht, da Software nicht in "Kernen" gehandelt wird. Software handelt mit Threads. Und wie diese Threads interagieren, entscheidet idR der Programmierer bzw. durch konkrete Umsetzungen des Programmierers die Software selbst, weil/wenn sie dynamisch mit Threads arbeitet -> was gängige Praxis ist.
Unsinn? Wenn der Programmierer einer die Threads seiner SW kommunizieren oder sich Synchronisieren lässt und diese Threads auf unterschiedlichen Kernen laufen, wie soll das dann bitte gehen, wenn nicht über eine Kommunikation zwischen den Kernen auf Hardwareebene? SW ist immer nur die Ansteuerung der Kerne, diese müssen aber alles ausführen was die SW vorgibt! Über gängige Programmierpraxis musst Du mir nichts erzählen, aber hast Du jemals Programmiere mit massivem Multithreading für Server entwickelt und solche Programme dann auch auf Performance hin optimiert? Wohl kaum, oder?

Kannst du mal mit diesem Quatsch aufhören?
Werft ihn raus, von dem kommt nur sowas, dabei hat der bestimmt noch nie gesehen was eine Oracle License für eine 32 Kern CPU kostet :eek:
 
Missverstanden hast nur Du und zwar alles, denn natürlich ist ein 8 Kerner RYZEN nicht ein klassischer NUMA 2 Node, aber halbwegs schon, weil NUMA nämlich auch bedeutet, dass die Kommunikation zwischen den Nodes eben viel langsamer ist als zwischen Kernen des gleichen Nodes und genau das ist bei RYZEN wegen der CCX ja auch gegeben, unabhängig vom gemeinsamen RAM Interface und bei den MCM CPUs wie Naples wird des noch deutlicher der Fall sein, weil da jedes Die 2 eigene RAM Kanäle verwaltet.

NUMA definiert NICHT die Geschwindigkeit zwischen irgendwelchen Nodes oder Cores... NUMA heist wörtlich: "Non-uniform Memory Architecture"
Die Geschwindigkeit, mit der die Nodes verbunden sind, ist dabei völlig egal. Es kann auch ein Interface benutzt werden, was genau so schnell (oder schneller) als der Interconnect zwischen den Cores eines Nodes ist -> und es ist/bleibt deswegen immernoch NUMA. (hier sehe ich übrigens deinen Denkfehler ;))
Es geht dabei viel eher um Speicher- Zugriffe auf Speicher, um Adressbereiche und dergleichen. Wie das im Detail funktioniert, findest sich zu Hauf im Netz, das hier auszudiskutieren geht arg weit OT...

Da so eine Architektur neu ist, kann man dafür keine passende SW Unterstützung finden, NUMA passt aber am Besten zu dem Problem. Letztlich wäre die Konsequenz für die SW auch die gleiche, nämlich entweder nur auf den Kernen eines "Nodes" aka CCX zu laufen oder eben die größere Latenz bei der Kommunikation zwischen den Kernen andere CCX in Kauf zu nehmen, einen dritten Weg gibt es nicht.
Nur ist es nicht neu... Neu ist bestenfalls, dass darum so eine Welle gemacht wird...
Ein Core2Quad verwendete einen ähnlichen Aufbau um dir mal ein Beispiel zu bringen.
2x Core "Cluster" mit einer Anzahl an Cores. Ein MCM Design. Pro "Chip" unter dem Deckel ein shared Cache (in dem Fall L2), einen ebenso lahmen Interconnect, ein gemeinsam genutztes SI mit globalem Adressraum für den gesamten Bereich. Wo siehst du hier einen Unterschied!? All das trifft ziemlich genau auch auf Ryzen DIEs zu. Nur das dort mit dem Ryzen 7 kein MCM verwendet wurde, sondern man zwei CCX in einen DIE gegossen hat sowie es kein shared L2 Cache pro CCX ist sondern ein shared L3 Cache und dieser damit eine Stufe höher ansetzt... Und die NB mit dem SI nicht mehr außerhalb der CPU untergebracht ist, sondern shared an beiden CCXen dran hängt. Am Grundaufbau ändert das aber nix.


Ja, Unsinn ;)
Dein Erklärungsversuch wirkt auf mich gerade wie wenn der Kindergärtner dem Bäcker versucht zu erklären, wie man Brötchen bäckt... Nix für ungut. Aber die Details können wir gern ausdiskutieren, ist hier im Thread klar OT.
Nur soviel, auch auf der Hardwareebene "interagieren die Kerne" nicht untereinander. Schau dir bitte dazu mal an, wie ein Prozessor funktioniert. Ein einziger Kern bekommt von den anderen perse erstmal überhaupt nix mit. Muss er auch gar nicht... Es findet in der Art einfach keine "Kommunikation" statt wie du es dir vielleicht vorstellst...

PS: und nein, ich brauch keine "Programme mit massivem Multithreading für Server entwickeln" um das Grundproblem des Multithreadings in der Programmierung zu verstehen... Im Vergleich zu Jemanden, der mit Programmierung nix am Hut hat, reicht mir das ;)

EDIT: das Verständnis zum Multithreading setzt aus meiner Sicht übrigens idR auch erst dann ein, wenn man selbst mal vor dem Optimierungsproblem gestanden hat und man sich gezwungen sah, einfach mal die verschiedenen Ansätze und Möglichkeiten durchgespielt hat... Du wirst staunen, was da alles möglich ist bzw. was bei vollbrachten Denkfehlern im Softwaredesign Prozess da für Potential verschenkt wird...
 
Zuletzt bearbeitet:
Das es nicht NUMA ist, habe ich schon mehrfach geschrieben, ebenso aber das das Verhalten eben dem von NUMA Node am nächsten kommt und die Konsequenzen für die SW letztlich die für die Kerne der CCX die Gleichen wie bei NUMA Nodes wären, egal wie das RAM angebunden ist. Man kann übrigens auch bei NUMA auf RAM zugreifen welches an einer anderen CPU hängt, nur geht das eben langsamer, wie alles was zwischen den Nodes passiert langsamer ist als wenn es auf der lokalen CPU wäre, eben genau wie zwischen den CCX der RYZEN CPUs, selbst wenn diese auf dem gleichen Die sind.

Im übrigens muss ich nicht staunen was möglich ist wenn man Optimierungsproblems auf Rechner, auch gerade auch NUMA Systemen ausführt, ich habe es oft genau getan. Daher weiß ich auch, dass es da Grenzen gibt. Da Du sowas nie gemacht hast, ist mir klar, sonst wüsstest Du auch was hier steht:
SMP hat also keine Einfluss auf den Task Scheduler, man kann SMP auch nicht wie bei NUMA mit GetNumaNodeProcessorMask abfragen welche Kerne zusammengehören. Für Windows und die SW ist daher ein RYZEN 8 Kerner genau wie ein i7-6900K ein nativer 8 Kerner mit 8 gleichberechtigten Kernen und die einzige bisher vorgesehen Möglichkeit Kerne zu gruppieren wäre die CCX eben als getrennte NUMA Node zu deklarieren, auch wenn sie wie schon oft von mir betont, eben keine echten NUMA Nodes sind. Dann würde aber für die SW genau das greifen was nötig ist um die hohen Latenzen der Verbindung zwischen den CCX zu vermeiden, auch wenn das halt nichts mit dem RAM Interface zu tun hat.

Das NUMA bedeutet, dass die Kommunikation zwischen den Nodes eben viel langsamer ist als zwischen Kernen des gleichen Nodes, bleibt absolut richtig, (langsam ist nicht nur Bandbreite, sondern kann auch Latenz sein oder eben beides) denn NUMA Architekturen sind klassischerweise Multi-CPU Systeme und da sind die Links zwischen den CPU niemals so schnell wie die Verbindung der Kernen auf einem Die. Das "NUMA für Non-uniform Memory Architecture" steht ist mir auch klar, dies ändert aber nichts an den sonstigen Konequenzen die mit solchen Architekturen verbunden sind und daher auch nichts daran, dass die gleichen Lösungen auch für andere Architekturen anwendbar sind, die die gleichen Eigenschaften aufweisen, auch wenn der Grund dafür ein andere als das RAM Interface ist.

Damit ist die Diskussion darüber für mich auch beendet, es ist sinnlos mit jemandem darüber zu Diskutieren der praktisch nie etwas damit zu tun hatte, nie HPC Anwendungen entwickelt hat die auf Mulitmillionen Dollar Systemen laufen wo jedes Prozent an Optimierung echt viel Geld für eingesparte HW bedeutet und dessen Lösung sich am Ende gegenüber den Wettbewerbern mehr als nur sehen lassen kann, weil sie mit einem Bruchteil der HW auskommt. Mache Die also nicht selbst vor das Du die Grundproblem des Multithreadings in der Programmierung verstanden hättest, wenn Dir nicht einmal klar ist, dass die Kommunikation und Synchronisation zwischen den Threads der SW dann nicht auch zu eben diesem Dingen zwischen den Kernen führt auf denen die ausgeführt werden.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh