Leider bekomme ich unser Testsystem imMoment nicht unter 3 GHz ;)
Schade )((

Sollte es doch (irgendwann) möglich sein, mit Mainboard XY und BIOS XZ, behaltet das bitte im Auge. Den Architekturenvergleich weiterzuführen wäre sehr aufschlussreich.
V.a. auch aufgrund der guten Vorarbeit, auf die der Test aufbauen würde.
 
Wenn auch verspätet: Bravo! Eine tolle Testserie, und zwei großartige Artikel, bei denen ich viel gelernt hab. Vielen Dank dafür! Berücksichtigt man die Umstände (der Blogeintrag liest sich wie von Stephen King) eine großartige Leistung!
 
Der Ryzen ist also vergleichbar mit zwei 4Core CPUs deren L3 Cache miteinander verbunden ist und die in einem CPU Gehäuse sitzen.

Stimmt so ungefähr.
Ich habe einen kleinen Cache-Benchmark geschrieben der die Latenz der Caches und des Hauptspeichers bei verschiedenen Blockgrößen ermittelt (siehe hier). Bei dem werden nacheinander in einer vom Prefetcher nicht vorhersagbaren Reihenfolge Cachezeilen geladen. Damit die CPUs nicht die Loads überlappen kann (Pipelining) ist in jedem Block von 64 Byte (entspricht einer Cachezeile) ein Pointer auf den jeweils nächsten Pointer in dem "nächsten" Block. Diese Technik zum Messen von Speicher-Latenz nennt man Pointer-Chasing.
Hier die Ergebnisse der Latenzmessung mit einem 1800X und DDR4-2133/CL15-Speicher:

4kB 3.9375
8kB 3.9375
16kB 3.79688
32kB 7.94531
64kB 9.07031
128kB 6.5918
256kB 11.9355
512kB 9.07471
1MB 10.9797
2MB 9.92834
4MB 13.0402
8MB 87.5207
16MB 83.616
32MB 89.7071
64MB 93.7347
128MB 113.686
256MB 108.367

Man sieht, dass von 1-4MB die Latenz ungefähr gleich bleibt, aber nicht erst bei 16MB, sondern schon bei 8MB nach oben schnellt. Das ist eine interessante Sache, denn das heißt, dass die Latenz nicht erst schon bei der Nutzung des L3-Caches im anderen CCX nach oben schnellt, sondern schon bei der Hälfte der Blockgröße.
Die Latenz ab einer Blockgröße von 8MB bewegt sich schon in der Größenordnung der Latenz des Hauptspeichers. Und die Latenz bei einer Blockgröße von 16MB zeigt, dass die CCXe mit kaum geringerer Latenz kommunizieren als die InfinityFabric mit dem RAM. Das ist Mist und ich denke, AMD sollte da nachbessern.

--- Update ---

512 MB Cache wären schön ;)

Ne, wären ziemlich sinnfrei. Die meisten Anwendungen skalieren ungefähr logarithmisch mit der Cache-Größe und irgendann ist man auf dieser Kurve über den magischen Knick hinweg und die wird bei weiterer Vergrößerung des Caches nur noch ein bisschen schneller.
Ausnahmen sind manche HPC-Anwendungen mit großem Working-Set, z.B. Wetter-/Klima-Berechnungen. Da ziehen dann CPUs wie der Xeon Phi Knights Landing der seine 16GB HBM-Speicher je nach Einstellung als L3-Cache schalten kann.

Laut der eigenen AMD-Messungen ist der L2 fast so schnell wie der L1, das ist schon sehr gut.

Is Quatsch, weder bei Durchsatz, noch Latenz. Ich hab's gemessen mit einem eigenen Latenz-Benchmark und mit einer eigenen Variante des Stream-Triad-Benchmarks.

Dort muss man dann durch intelligentere Programmierung versuchen die Daten in den jeweiligen Cacheteilen zu halten.

Das ist relativ einfach, Threads die viel miteinander austauschen auf einem CCX zu pinnen.

--- Update ---

Schon mal versucht, mit einem problematischen Spiel, die CPU-Kerne nach Start manuell im Task-Manager zuzuweisen?
Also alle Kerne und SMT-Kerne auf einem CCX-Modul (0-3 + 8-11, oder 0-7) zuweisen, und überprüfen, ob die Leistungsschwäche schwindet.
Das Betriebssystem und Grafik-Treiber, etc. kann ja auch auf dem anderen CCX Modul laufen, dh. das braucht man für den Test nicht abzuschalten.

Weißt Du denn welche Prozessor-Indizes auf welches CCX mappen?

--- Update ---

Die Frage ist dann aber , warum sollte ein Kern vom CCX0 auf den L3 Cache vom CCX1 Zugreifen müssen?
In den L3 Cache von CCX1 zu schreiben geht doch viel schneller, genau so das auslesen.
Die Entwickler nutzen dafür die "Pointer" und Queues für den RAM. ;)

Anwendungen die in dem Sinne Cache-aware sind gibt es nie und wird es nie geben.
Wenn eine Anwendung mit einem Working-Set <= 8MB hat, dann mappen die Zugriffe auf das CCX auf dem der Thread läuft. Das habe ich so ermittelt, dass mein Cache-Benchmarkt, egal auf welchen Kern ich ihn mit mit "start /affinity 0x**** benchmark" festnagle, immer bei einer Working-Set-Größe von 8MB die selbe Latenz hat.

--- Update ---

Die Ryzen Modelle sind die ersten AMD Prozessoren mit einem solchen SMT Aufbau und es ist gut möglich das diverse Spiele ins Stolpern kommen weil sie vom Betriebssystem noch nicht korrekt unterstützt werden. Bei normalen, gut parallelisierten Anwendungen geht die Problematik hingegen völlig unter weil ein Gesammtergebnis am Ende raus kommt und nicht mehrere parallel laufende Aufgaben laufen die sich gegenseitig ausbremsen können.

Die Topologie-Info die mittels CPUID ermittelt werden kann ist die selbe wie für Intel-CPUs, d.h. Windows wird bei der Ermittlung, welcher Thread auf welchen Kern mappt genauso vorgehen wie bei Intel-CPUs. D.h. wenn ich z.B. <= 8 Threads bei einer Anwendung gleichzeitig am Rennen habe, dann teilen die sich keine Cores (wenn da nicht Konkurrenz von anderen Anwendungen vorhanden ist).

--- Update ---

Frag Windows,da wird immer gut Durchgereicht und NICHT fest auf die Kerne Verteilt.

Also bei meinem Windows 10 mit Crator's Update bleibt z.B. ein einzelne gzip-Prozess auf meinem 1800X an einem Kern kleben. Wechsel finden selten statt.

--- Update ---

Ich weiß nicht mehr wo ich das gelesen hatte (Anandtech Forum?), aber irgendjemand hat in Windows ausgelesen das jeder Kern mit seinem eigenen L2 und L3 Cache erkannt wird und daher so ein Unfug veranstaltet wird.

So ähnlich legen meine Latenz-Benchmarks auch nahe. Die Zugriffs-Latenz bleibt bis zu einem Working-Set 4MB relativ konstant, steigt aber bei 8MB auf ein hohes Niveau an. Die zusätzliche CCX-Kommunikation legt bei einer weiteren Vergrößerung des Working-Sets auf 16MB nochmal ein bisschen zu.
Das legt nahe, dass der L3-Cache nicht so organisiert ist wie das verbreitete Diagramm des Ryzens nahelegt. Und zwar insofern, als sich nach meinen Daten zwei Kerne einen L3-Cache von 4MB teilen müssen und diese Gruppen wiederum in Zweier-Gruppen in einem CCX organisiert sind. Diese sind wiederum durch die InfinityFabric-Crossbar untereinander verbunden.
 
Zurück
Oben Unten