Ryzen hat keine 16MB L3-Cache ;-)
- Ersteller Flodul
- Erstellt am
So sieht das aus:
Wieso sollte ich das? Die Threads würden jeweils ihr eigenes Working-Set beanspruchen wenn ich den Test mehrfach parallel laufen ließe und es würde Cache-Thrashing stattfinden, d.h. die Threads würden sich ihre Inhalte gegenseitig aus dem Cache werfen.
Und wenn ich jeweils nur eine Instanz auf jeweils unterschiedlichen Kernen laufen ließe, dann wär das Ergebnis das selbe.
Dreh und wende es wie Du willst; die IF ist einfach Käse.
Code:
Logical Processor to Cache Map:
**-------------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64
**-------------- Instruction Cache 0, Level 1, 64 KB, Assoc 4, LineSize 64
**-------------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64
********-------- Unified Cache 1, Level 3, 8 MB, Assoc 16, LineSize 64
--**------------ Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64
--**------------ Instruction Cache 1, Level 1, 64 KB, Assoc 4, LineSize 64
--**------------ Unified Cache 2, Level 2, 512 KB, Assoc 8, LineSize 64
----**---------- Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64
----**---------- Instruction Cache 2, Level 1, 64 KB, Assoc 4, LineSize 64
----**---------- Unified Cache 3, Level 2, 512 KB, Assoc 8, LineSize 64
------**-------- Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64
------**-------- Instruction Cache 3, Level 1, 64 KB, Assoc 4, LineSize 64
------**-------- Unified Cache 4, Level 2, 512 KB, Assoc 8, LineSize 64
--------**------ Data Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64
--------**------ Instruction Cache 4, Level 1, 64 KB, Assoc 4, LineSize 64
--------**------ Unified Cache 5, Level 2, 512 KB, Assoc 8, LineSize 64
--------******** Unified Cache 6, Level 3, 8 MB, Assoc 16, LineSize 64
----------**---- Data Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64
----------**---- Instruction Cache 5, Level 1, 64 KB, Assoc 4, LineSize 64
----------**---- Unified Cache 7, Level 2, 512 KB, Assoc 8, LineSize 64
------------**-- Data Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64
------------**-- Instruction Cache 6, Level 1, 64 KB, Assoc 4, LineSize 64
------------**-- Unified Cache 8, Level 2, 512 KB, Assoc 8, LineSize 64
--------------** Data Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64
--------------** Instruction Cache 7, Level 1, 64 KB, Assoc 4, LineSize 64
--------------** Unified Cache 9, Level 2, 512 KB, Assoc 8, LineSize 64Wieso sollte ich das? Die Threads würden jeweils ihr eigenes Working-Set beanspruchen wenn ich den Test mehrfach parallel laufen ließe und es würde Cache-Thrashing stattfinden, d.h. die Threads würden sich ihre Inhalte gegenseitig aus dem Cache werfen.
Und wenn ich jeweils nur eine Instanz auf jeweils unterschiedlichen Kernen laufen ließe, dann wär das Ergebnis das selbe.
Dreh und wende es wie Du willst; die IF ist einfach Käse.
Zuletzt bearbeitet:
WindHund
Grand Admiral Special
@Flodul
Oge, ich ging von einem pointer aus, was du auch schon geschrieben hast.
Es werden praktisch keine Daten mehr kopiert sondern der "Zeiger" verlinkt in den entsprechenden Adressbereich.
Hier gibt es weitere Infos vom IF: https://www.hardwareluxx.de/index.p...ric-anbindung-der-epyc-serverprozessoren.html
Aber das sind mir schon bekannte Infos, oder siehst du dort noch was neues?
MfG
Oge, ich ging von einem pointer aus, was du auch schon geschrieben hast.
Es werden praktisch keine Daten mehr kopiert sondern der "Zeiger" verlinkt in den entsprechenden Adressbereich.
Hier gibt es weitere Infos vom IF: https://www.hardwareluxx.de/index.p...ric-anbindung-der-epyc-serverprozessoren.html
Aber das sind mir schon bekannte Infos, oder siehst du dort noch was neues?
MfG
Ach, die Architektur ist mir egal. Mich interessieren Messwerte.
WindHund
Grand Admiral Special
lol, sind die wenigstens aktuell kalibriert, deine Messmittel?
Das kann ich aber durchaus nachvollziehen!
Wie wäre es mit zwei Instanzen? (0-4 & 5-7)
P.S. Der L3 SnoopFilter (Bereich im L3 Cache) verhindert Cache-Thrashing: http://www.realworldtech.com/bulldozer/3/
Der Mess-Thread läuft mit ziemlich hoher Priorität. Da dürften nur noch Interrupts und DPCs dazwischenfunken. Deren Effekt ist vernachlässigbar.
Sehe ich keinen Sinn drin.
Ein Snoop-Filter hat mit Cache-Thrashing genau garnichts zu tun. Er limitiert nur den Scope eines Snoops.
Zuletzt bearbeitet:
WindHund
Grand Admiral Special
Ok, dann darfst du dich weiterhin über deine schlechte Ergebnisse aufregen...
Geht es dir nur um die Single Thread Latenz?
Latenz ist immer single-threaded weil es um die Zeit geht bis die Daten im Kern verwertbar sind.
Alle Benchmarks wie z.B. die in Sandra messen single-threaded.
Man könnte multi-threaded nur zwei Dinge beobachten: das Pipelining der Caches, d.h. wenn N Workingsets kleiner als die Größe einer geteilten Cache-Ebene sind, dass man dann nicht die N-fache Latenz hat, sondern eine zwischen der N-fachen und der einfachen. Und, dass beim Überschreiten der Größe dieser N Working-Sets die Threads sich gegenseitig thrashen und die Peformance unter Umständen auf das Niveau des RAMs einbricht. Aber beide Dinge wären ein anderes Thema.
Ich hab übrigens noch einen Benchmark geschrieben der misst wie lange es dauert, damit eine Cachezeile vom L1-Cache eines Kernes in einen anderen kommt, was relevant ist wenn Threads Daten austauschen. In einem CCX geht das so mit ca 150 Takten. Zwischen den CCXen liegt die Performance bei ca. 550 Takten; das zeigt mal wieder, dass die IF Murks ist. Das zeigt sich z.B. in dem Benchmark der weiter oben angeführten französischen Seite, wo eine 4+0-Konfiguration in Battlefield 1 25% schneller ist als eine 2+2-Konfiguration.
Der Ryzen ist sicher keine schlechte CPU, aber hat eine Schwäche im Cache-Design.
Zuletzt bearbeitet:
WindHund
Grand Admiral Special
Tu dich mal mit helle53 zusammen, der hat auch schon Cache Hirarchien untersucht... http://abload.de/img/corepairingatlohn_idluturo.jpg
Das Programm ist von ihm.
Nutzt du eigentlich die UEFI Energieoptionen sowie die vom OS?
Oder alle Energieoptionen disabled?
Nix disabled, aber die Latenz von vier Takten beim L1-Cache zeigt mir, dass der Kern schon bei der kleinsten Blockgröße am Anfang des Tests auf Maximal-Takt hochgedreht hat.
Ich kann dir schon architekturbedingt nicht weiter helfen, da kein AMD64 vorhanden. Als Freund des experimentellen Nachweises halte ich eine solche Messung trotzdem für interessant. Man kann ja nicht einfach hergehen und eine Messgröße im groben Raster (1,2,4,8,16,32) abtasten, und steif und fest behaupten, dass es sich bei 5 MB so verhalten muss, wie bei den gemessenen 8 MB. Wir haben die Dinger nicht mitentwickelt und wissen, wie es drinnen funktioniert, sondern versuchen durch solche nützlichen Tests wie dem von dir zu verstehen, was man bei der Programmierung beachten muss.
Beim alten Sockel F Opteron ergänzten sich die Caches übrigens auch nicht. Wenn aber zwei Kerne auf unterschiedlichen Knoten schreibend auf den gleichen Speicherbereich (bzw. eng benachbart) zugreifen, kann es schon sein, dass jeder Kern vor jeder Schreibaktion erst einmal beim andern NUMA-Knoten fragen muss, ob der bei Ihm vorliegende Cache-Zustand noch der aktuelle ist, oder ob dort üben was geändert worden ist. Da kann man die lustigsten Sachen erleben (bzw. unlustig).
Beim Übergang vom K10 X4 zum K10 X6 kamen dann die Snoop-Filter, die zwar Single-Threaded etwas Geschwindigkeit gekostet haben (weil weniger L3 Cache), Multithreaded im Quadsockel-System aber manchmal echt viel gebracht haben.
Tut's auch nicht, aber die Grenzen auf denen ich getestet habe liegen auf den Grenzen in denen Caches partitioniert sind. Cache-Sets sind nun mal immer eine Zweier-Potenz groß um performant zu sein.
Erstens ist das eine völlig andere Thematik.
Und zweitens fragt ein Cache nicht einen anderen ob etwas geändert wurde. Wenn etwas geändert wurde, dann hat die Cachezeile an dem Kern wo das geändert wurde in den Zustand modified gewechselt und der Cache ist der einzige der dieses Datenwort enthält. Also wird in deinem Szenario von einer CPU gefragt welche CPU denn eine aktuellere Kopie des Speicherblocks hat als er im RAM steht.
Hmmm...also erstmal vorab. Ich bin kein Programmierer und kein Hardwarearchitekt. Das folgende ist also ggf. Laienhafte Spekulation - falls ich daneben liege kein Problem. Aber nur mal meine Gedanken als Denkanstoß:
Betrachten wir erstmal diese Liste:
So wie es hier ausgegeben wird würde ich die Cachesituation so interpretieren als das 4-Kerne jeweils ein 8MB-Segment zusammen haben.
Also Core0-4 L3-1 mit 8MB ("lokalisiert" an Kern1). Die anderen Kerne aus Block 0-4 greifen dann wohl über Core1 auf den Cache zu ?
Der Ryzen besteht aus 2x4 Kernen vom Layout her. Ergo würde das Sinn ergeben dass jeder 4-Kern block 8MB L3 cache hat. Dieser Block wird irgendwie mit "shared Access" arbeiten wobei ggf. die "Steuerung" des ganzen der Kern1 macht ?
=> Es sind eigentlich 2x8 MB-Blöcke und der Interconnect des ganzen läuft über die IF.
Erwarten würde ich daher dass er bei >8MB dramatisch langsamer wird...
1. Aus der obigen Liste würde ich daher erwarten dass bei >32kb was passiert weil der Instruction cache zu ist.
Als nächstes würde ich erwarten dass der L2 cache bis 512kB arbeitet..:
Der nächste schritt wäre wenn nun der L3 dran ist, welche ja 8MB pro CCX ist...
Die Sonderbarkeit könnte aber das "Interleaving" innerhalb eines CCX sein ? Evtl. sind das nochmal 2x4MB Blöcke ? die zwischen jeweils 2 Kernen sitzen?
Kern1 --- Cache Block1----Kern2
|**********************|
Kern3----Cache Block2----Kern4
(Die *zeichen sind Abstandshalter zur Darstellung und haben KEINE sonstige Bedeutung)
Die -Zeichen und |Zeichen sind die Verbindungen die Daten-Transportieren.
Evtl gibt es auch noch eine "Brücke direkt zwischen den Caches, würde aber vielleicht erklären warum es genau doppelt so lange dauert um 4MB zu addressieren...mit 1 Fetch kann nur aus 1 Block parallel gelesen werden...um in den zweiten Block zu kommen brauchts 1 extra Runde ?
Weiter ist ja dann der 2.8MB L3 cache auf dem anderen CCX zu finden...das würde ich so verstehen dass man da dann über die IF zugreift und diese läuft mit dem RAM-Takt.
Mal sehen wie ihr experten das seht.
Betrachten wir erstmal diese Liste:
****Rest gekürzt - der rest ist identisch mit Core5-7.
So wie es hier ausgegeben wird würde ich die Cachesituation so interpretieren als das 4-Kerne jeweils ein 8MB-Segment zusammen haben.
Also Core0-4 L3-1 mit 8MB ("lokalisiert" an Kern1). Die anderen Kerne aus Block 0-4 greifen dann wohl über Core1 auf den Cache zu ?
Der Ryzen besteht aus 2x4 Kernen vom Layout her. Ergo würde das Sinn ergeben dass jeder 4-Kern block 8MB L3 cache hat. Dieser Block wird irgendwie mit "shared Access" arbeiten wobei ggf. die "Steuerung" des ganzen der Kern1 macht ?
=> Es sind eigentlich 2x8 MB-Blöcke und der Interconnect des ganzen läuft über die IF.
Erwarten würde ich daher dass er bei >8MB dramatisch langsamer wird...
1. Aus der obigen Liste würde ich daher erwarten dass bei >32kb was passiert weil der Instruction cache zu ist.
--------------- Check alle <32KB sind gleich schnell (L1 Cache)
Als nächstes würde ich erwarten dass der L2 cache bis 512kB arbeitet..:
---------------- Check...Latenz =4x L1 ?
Der nächste schritt wäre wenn nun der L3 dran ist, welche ja 8MB pro CCX ist...
--------------Check...50% langsamer als der L2
Die Sonderbarkeit könnte aber das "Interleaving" innerhalb eines CCX sein ? Evtl. sind das nochmal 2x4MB Blöcke ? die zwischen jeweils 2 Kernen sitzen?
Kern1 --- Cache Block1----Kern2
|**********************|
Kern3----Cache Block2----Kern4
(Die *zeichen sind Abstandshalter zur Darstellung und haben KEINE sonstige Bedeutung)
Die -Zeichen und |Zeichen sind die Verbindungen die Daten-Transportieren.
Evtl gibt es auch noch eine "Brücke direkt zwischen den Caches, würde aber vielleicht erklären warum es genau doppelt so lange dauert um 4MB zu addressieren...mit 1 Fetch kann nur aus 1 Block parallel gelesen werden...um in den zweiten Block zu kommen brauchts 1 extra Runde ?
Weiter ist ja dann der 2.8MB L3 cache auf dem anderen CCX zu finden...das würde ich so verstehen dass man da dann über die IF zugreift und diese läuft mit dem RAM-Takt.
-----Check...cross-CCX-Latenz = RAM-Latenz
Mal sehen wie ihr experten das seht.
Zuletzt bearbeitet:
bschicht86
Redaktion
☆☆☆☆☆☆
Ich bin zwar kein Experte, aber ich würd wohl auch wie andere gern den Bereich zwischen 4 und 8 MB genauer aufschlüsseln wollen, z.b. wenn möglich in 512k-Sequenzen. Dann wär man sicher, ob es nicht 2x4MB (untereinander immer noch schnell angebunden) oder doch andere "Anomailen" (Als unwarscheinliches Bsp HT3.0 mit der 1MB-Reservierung)
Wenn dagegen das mit den 2x4 MB pro 2 Kerne zutrifft, dann wär es für AMD durchaus einfach, irgendwann 6-Kern-CCX aufzulegen, wie z.B. für den geplanten 48-Kern-Naples.
Wenn dagegen das mit den 2x4 MB pro 2 Kerne zutrifft, dann wär es für AMD durchaus einfach, irgendwann 6-Kern-CCX aufzulegen, wie z.B. für den geplanten 48-Kern-Naples.
Genau.
Ist ja auch so; guck dir die Werte an.
I-Cache ist sowieso schwierig zu messen, erst recht mit sowas wie einem uOp-Cache.
Nur weil der x fach so groß ist heißt das nicht, dass der die x-fache Latenz hat.
Wenn die interleaved wären, dann wäre die Latenz von 4MB auf 8MB konstant.
Ich nehme an, dass das Pesudo-LRU-Replacement zwischen den beiden Hälften so ist, dass erst die Kern-nähere Hälfte benutzt wird und dann die entferntere, und deswegen die Latenz von 4MB auf 8MB so ansteigt.
Mein Benchmark macht Pointer-Chasing, da wird überhauptnichts parallel gelesen; ansonsten wär die Latenz nicht messbar.
Ich habe einen anderen Benchmark geschrieben der misst wie lange es dauert damit eine Cachezeile von einem Kern in einem CCX zu einem anderen Kern in einem anderen CCX zu übertragen. Das dauert so ca. 550 Takte. Das ist so schlecht, dass man annehmen könnte, AMD hat das so gemacht, dass eine Cachezeile per-se erstmal von einem CCX ins RAM zurückgeschrieben und wieder von einem anderen CCX von dort gelesen wird. Könnte sein, muss aber nicht.
Zuletzt bearbeitet:
WindHund
Grand Admiral Special
Lesen und schreiben beim RAM geht doch schon seit dem FX Zeitgleich, nennt sich unganged Dual Channel (2x 72Bit mit ECC).
Von AMD gab es bezüglich Fabric noch die Unterteilung in Control Fabric und Data Fabric:
Ja - dann stimmt ja im wesentlichen alles was ich gesagt habe mit deinen Resultaten gut überein.
Bleibt eigentlich nur die "anomalie" bei 4MB.
Ich glaub nicht dass die Entfernung hier eine wesentliche Rolle spielt - die Abstände sind da viel zu kurz und wenn der Kommunikationsweg direkt ist dann spielt das für die Latenz nicht so eine Rolle ob das nun 5mm oder 6mm Distanz sind.
Meiner laienhaften Einschätzung nach muss es dann eher so sein dass die Kommunikation hier erst einen "umweg" machen muss über einen anderen Schalter. Was eigentlich nur Sinn macht wenn quasi Jeder Kern (oder zumindest jedes Kern-Paar) hier einen "eigenen" L3-Cache hat. Der dann wieder hierarchisch mit allen anderen Kernen des CCX, und dann weiter hierarchisch Cross-CCX genutzt wird.
Inwiefern das die Performance nun einbremst kann ich schwer beurteilen. Vermutlich ist aber so ein Ansatz bei Multi-Threading bzw. All-Core Nutzung dann wieder im Vorteil da die Daten Lokal auf dem jeweiligen Kerncache gelagert werden ?
Wieviel Takte dauert es denn eine Cachezeile innerhalb eines CCX zu übertragen ? Oder sind das genau die Zahlen oben ?
Bleibt eigentlich nur die "anomalie" bei 4MB.
Ich glaub nicht dass die Entfernung hier eine wesentliche Rolle spielt - die Abstände sind da viel zu kurz und wenn der Kommunikationsweg direkt ist dann spielt das für die Latenz nicht so eine Rolle ob das nun 5mm oder 6mm Distanz sind.
Meiner laienhaften Einschätzung nach muss es dann eher so sein dass die Kommunikation hier erst einen "umweg" machen muss über einen anderen Schalter. Was eigentlich nur Sinn macht wenn quasi Jeder Kern (oder zumindest jedes Kern-Paar) hier einen "eigenen" L3-Cache hat. Der dann wieder hierarchisch mit allen anderen Kernen des CCX, und dann weiter hierarchisch Cross-CCX genutzt wird.
Inwiefern das die Performance nun einbremst kann ich schwer beurteilen. Vermutlich ist aber so ein Ansatz bei Multi-Threading bzw. All-Core Nutzung dann wieder im Vorteil da die Daten Lokal auf dem jeweiligen Kerncache gelagert werden ?
Wieviel Takte dauert es denn eine Cachezeile innerhalb eines CCX zu übertragen ? Oder sind das genau die Zahlen oben ?
Sind die Ergebnisse eigentlich mit jenen der CPUID-Software "Cache latency" [1] vergleichbar?
[1] - http://download.cpuid.com/misc/latency.zip
[1] - http://download.cpuid.com/misc/latency.zip
Die Datenleitungen sind nur einmal da. Aber sicher kann ein nächster Lese-/Schreib-vorgang initiiert werden während der Burst eines vorangegangenen läuft. Das hat nichts mit FX zu tun, sondern ist generell so seit es SDRAM gibt.
--- Update ---
Ca. 150 Takt, also fast ein Viertel.
--- Update ---
Von L1 und L2 ja, von L3 nicht. Und dieses Tool misst noch einen nicht vorhandenen L4-Cache; seltsames Ding.
WindHund
Grand Admiral Special
Hoppela, den unganged Mode gibt es schon seit dem Phenom 1 aber beim FX ist er auch noch aktuell.
128Bit IMC der in 2x 64Bit aufgeteilt wird so das zwei Instanzen zeitgleich lesen und schreiben können.
Natürlich nur wenn die Ergebnise nicht aufeinander abhängig sind...
Kein Kommentar zu der verlinkten Grafik der Infinity Fabric?
1. Testlauf:
L1 = 32KB, Latenz 4 Zyklen
L2 = 8192KB, Latenz 24 Zyklen =6xL1
2. Testlauf:
L1 = 32KB, Latenz 3 Zyklen
L2 = 4096KB, Latenz 18 Zyklen =6xL1
L3 = 8192KB, Latenz 52 Zyklen =14xL1 bzw ~3xL2 ?
Wie kann es sein dass so ein Tool einmal 2 Caches und einmal 3 Caches findet ?
Btw. die Cachegrößen korrelieren doch sehr gut mit den Werten hier von Flodul ?
Floduls Test findet ja:
L1 = 32KB, Latenz ~4 Zyklen
L2 = 512KB, Latenz ~16 Zyklen = x4 L1
L3' = 4096KB, Latenz ~24 Zyklen = x6 L1
L3'' = 8192KB, Latenz ~48 Zyklen = x12 L1
L4 = System RAM bzw. Infinity Fabric >8192KB, Latenz = 167 Zyklen ~ 42x L1
EDIT keine Ahnung wie man hier die gefundenen 550 Zyklen reininterpretieren kann für den Cross-CCX Code.
Zuletzt bearbeitet:
Hoppela, den unganged Mode gibt es schon seit dem Phenom 1 aber beim FX ist er auch noch aktuell.
Es geht mir nicht um die unganged Mode, sondern darum, dass SDRAM pipelined arbeiten kann.
Es geht mir nicht um die Latenz eines Transfers vom Speicher in einen Kern, sondern von einem Kern in einem CCX zu einem anderen Kern in einem anderen CCX. Das ist extrem tricky zu messen, und es würde mich wundern wenn es vor mir jemand gemessen hat.
Zuletzt bearbeitet:
@SPINA: Vielen Dank für die zwei Durchläufe. Das Ergebnis ist in der Tat interessant. Vergleicht man die eigentlichen Messergebnisse beider Testläufe miteinander, so fällt insbesondere in der Zeile 8192 eine deutliche Diskrepanz auf.
Durchlauf 1: 8192 x 128,256,512: 025, 121, 058 (<- unlogisch)
Durchlauf 2: 8192 x 128,256,512: 035, 047, 074
Ich nehme an, der Rechner hatte während des Tests absolut nichts zu tun (Browser aus, Internet aus, ...)?
Sofern die unterschiedlichen Ergebnisse reproduzierbar sind, könnte man versuchen das latency-Programm auf bestimmten Kernen starten zu lassen. Wie das geht, steht hier im Eröffnungspost:
http://stackoverflow.com/questions/2976600/start-affinity-equivalent-in-net
Mal so am Rande noch ein Gedanke bezüglich AMD Ryzen vs. Intel Core-i... :
Was vergleichen wir hier eigentlich? Bei den Core-i Prozessoren gibt es zwei "Arten" von L3-Cache-Designs. Die Doppelkern und Vierkernprozessoren haben meines Wissens einen kleinen L3-Cache, der auf schnelles Ansprechen optimiert ist. Dafür ist der nicht wirklich skalierbar, bei 8 MB ist Schluss.
Die großen Core-i ab 6 Kernen haben separierte L3-Cache-Segmente, die per Ringbus vernetzt sind. Die sind langsamer, insbesondere bei den richtig fetten Dies, aber recht gut skalierbar (auf Kosten der Latenz).
AMD kann sich scheinbar keine zwei Dies für Ryzen leisten, statt dessen werden aus einem mittelgroßen Die durch Abschalten von Kernen normale Desktop-Prozessoren und durch das Zusammenschalten von mehreren Dies richtige Server-CPUs gefertigt. Die Cache-Architektur richtet sich scheinbar nach dem Maximalausbau mit vier Dies pro Sockel und zwei Sockeln.
Da ist es wenig verwunderlich, wenn diese sehr universell einsetzbare Cache-Struktur hinter den auf die jeweiligen Prozessor maßgeschneiderter Strukturen bei Intel zurück fällt.
Durchlauf 1: 8192 x 128,256,512: 025, 121, 058 (<- unlogisch)
Durchlauf 2: 8192 x 128,256,512: 035, 047, 074
Ich nehme an, der Rechner hatte während des Tests absolut nichts zu tun (Browser aus, Internet aus, ...)?
Sofern die unterschiedlichen Ergebnisse reproduzierbar sind, könnte man versuchen das latency-Programm auf bestimmten Kernen starten zu lassen. Wie das geht, steht hier im Eröffnungspost:
http://stackoverflow.com/questions/2976600/start-affinity-equivalent-in-net
Mal so am Rande noch ein Gedanke bezüglich AMD Ryzen vs. Intel Core-i... :
Was vergleichen wir hier eigentlich? Bei den Core-i Prozessoren gibt es zwei "Arten" von L3-Cache-Designs. Die Doppelkern und Vierkernprozessoren haben meines Wissens einen kleinen L3-Cache, der auf schnelles Ansprechen optimiert ist. Dafür ist der nicht wirklich skalierbar, bei 8 MB ist Schluss.
Die großen Core-i ab 6 Kernen haben separierte L3-Cache-Segmente, die per Ringbus vernetzt sind. Die sind langsamer, insbesondere bei den richtig fetten Dies, aber recht gut skalierbar (auf Kosten der Latenz).
AMD kann sich scheinbar keine zwei Dies für Ryzen leisten, statt dessen werden aus einem mittelgroßen Die durch Abschalten von Kernen normale Desktop-Prozessoren und durch das Zusammenschalten von mehreren Dies richtige Server-CPUs gefertigt. Die Cache-Architektur richtet sich scheinbar nach dem Maximalausbau mit vier Dies pro Sockel und zwei Sockeln.
Da ist es wenig verwunderlich, wenn diese sehr universell einsetzbare Cache-Struktur hinter den auf die jeweiligen Prozessor maßgeschneiderter Strukturen bei Intel zurück fällt.
Es liefen nur die notwendigen Systemprozesse im Hintergrund. Allerdings waren Stromsparmechanismen in Kraft, die das Ergebnis durchaus verfälscht haben können. Zwar war das Profil "Höchstleistung" als Energiesparplan ausgewählt, aber ich habe das Profil so angepasst, dass Cool'n'Quiet nicht außer Kraft gesetzt wird. Jedenfalls fiel das Ergebnis inkonsistent und nicht reproduzierbar aus. Die zwei Durchläufe waren eine Auswahl.
WindHund
Grand Admiral Special
@SPINA
Das Latency von CPUID ist relativ alt, dennoch hat es sich bewährt über die Jahre.
Bei SIV64X ist es auch implementiert, dort lassen sich auch die Kerne/Module auswählen: http://abload.de/img/siv64x_cache_lattek8ok9.jpg
Zudem findet sich dort noch ein interessanter Test: "Memory Areas" nach dem klicken auf "Speed" wird ein Datentransfer durch Virtual Maschines erzeugt.
Bei mir sind in 15 Sekunden 28 GByte voll und werden gehalten: http://abload.de/img/siv64x_mem_areaswarir.jpg
Das Latency von CPUID ist relativ alt, dennoch hat es sich bewährt über die Jahre.
Bei SIV64X ist es auch implementiert, dort lassen sich auch die Kerne/Module auswählen: http://abload.de/img/siv64x_cache_lattek8ok9.jpg
Zudem findet sich dort noch ein interessanter Test: "Memory Areas" nach dem klicken auf "Speed" wird ein Datentransfer durch Virtual Maschines erzeugt.
Bei mir sind in 15 Sekunden 28 GByte voll und werden gehalten: http://abload.de/img/siv64x_mem_areaswarir.jpg
Ähnliche Themen
