Wenn es bei Quad-Channel bleibt, müsste jeder Die einen Kanal beisteuern, was ich bei Single-Thread-Anwendungen kritisch finde. Oder habe ich da eine falsche Vorstellung?
Laut Anandtech soll es ein NUMA/UMA Zwitter werden. Also zwei DIEs jeweils sind jeweils ein NUMA Node und die anderen beiden kommen über die Fabric (inkl. der deutlich höheren Latenz)
Ob das allerdings besser ist als je DIE einen Speicherkanal zu nutzen? Für die Benches, die sich die Fans dann wieder um die Ohren klatschen ist es egal, CB und auch Blender interessiert das wenig
Musst mal jdl hier im Forum fragen, der kann dir da vllt sogar real World Szenarien benennen wo es absolut gar keine Skalierung mehr gibt trotz 100% mehr Cores, weil die fehlende Anbindung so derart zur Bremse wird...
Was macht eurer Meinung nach mehr Sinn?
Anhang anzeigen 436957
Klar das rechte!
Weil das OS (Linux/Windows) in der Lage ist, NUMA Nodes zu kennen und entsprechend die Threads sauber auf diese zu verteilen.
Nicht NUMA aware Software wird somit von einem Windows/Linux möglichst versucht auf einem NUMA Node zu halten. Erst wenn die Software erzwingt, dass mehr Threads belegt werden als ein NUMA Node bereit stellen kann oder mehr Speicher belegt wird, als ein NUMA Node aufweist, nimmt man weitere Nodes hinzu.
Das linke ist dabei hingegen problematisch, da wahrscheinlich das OS nicht sehen kann wie die Kiste intern organisiert ist und munter einfach davon ausgeht, dass dort jeder Core/Threads den gleichen Zugriff zum Speicher hat -> was aber nicht der Fall ist. Threads auf den DIEs ohne eigenes SI sind dabei langsamer. Die Skalierung wird also schlechter ausfallen.
Kann der Prozessor dazu noch in einen UMA Mode geschalten werden (wie TR1 auch), dann sieht das OS gar nix mehr und verteilt wild auf alle vier DIEs im Zweifel. Im Worst Case bedeutet das dann, vor allem bei Teillast die Cores rangezogen werden, wo selbst kein Speicherinterface vorhanden ist und damit der Traffic komplett über die Fabric läuft. Wobei ich im Moment davon ausgehe, dass es keinen reinen UMA Mode wie bei TR1 gibt...
Vier Mal Single-Channel kann ich mir nicht vorstellen. Das würde alle Anwendungen, die nur auf einem Die ablaufen ausbremsen.
Das ist der Denkfehler.
4x1 Kanal im UMA Mode wäre exakt das gleiche wie 2x2 Kanäle im UMA Mode bei TR1... Funktioniert dort ja ebenso
Das OS geht davon aus, dass es EIN Ganzheitliches Konstrukt ist. Die Hardware teilt es ihm so mit und verteilt gleichbedeutend auf alle vier Kanäle. Die Frage ist eher, ob es einen UMA Mode geben wird... Epyc kann es ja nicht
Im NUMA Mode, also mit durchgabe der Anbindung an das OS würde NUMA aware Software weiter skalieren. Und nicht NUMA aware Software nicht sonderlich schlechter als im UMA Mode funktionieren.
2x2 + 2x0 würde hingegen bedeuten, dass 50% der Threads zwingend über die Fabric müssten. 50% also zwingend langsamer angebunden wären als der Rest. Egal ob NUMA oder UMA Mode. Denn NUMA aware Software wäre weiterhin nicht in der Lage die Threads der beiden zusätzlichen DIEs zu versorgen ohne über die IF zu müssen. Und im UMA Mode müssen die Daten auch über die IF.
TR1 verliert selbst nicht so sonderlich viel Performance wenn man von 2x2 auf 2x1 Kanal geht (NUMA Mode) - zumindest wenn man nicht bandbreitenlastige Benches als Maßgabe nimmt. Verliert im Schnitt im UMA Mode aber bei Cache/Latenzlastigen Anwendungen durchaus seine 5-10%. Und das obwohl es auch lokalen Speicheraccess gibt. Hier wäre das dann noch schlimmer obwohl die IF Verbesserungen von Zen+ da klar gegen wirken.
- - - Updated - - -
Das ist offensichtlich so nicht richtig ....
???
KVR24E17D8/16 ist kein RDIMM (ECC)... Sondern UDIMM ECC.
Nur wie teuer der wohl wird? 
