Notiz Prozessorgerüchte: AMD Matisse mit 12 Kernen im UserBenchmark

[MK one]

Ja, das hab ich so verstanden, nur nicht, was es mit der Memory-Latency zu tun hat. Es sei denn, die meinen noch den L3. Ansonsten dürften alle Kerne auf einem Die die gleiche Latenz zum Arbeitsspeicher haben.

Für die unterschiedliche Latenz sollte eigentlich nur die Die zu Die Kommunikation von Bedeutung sein. Damit ja nur bei TR und Epic.

Ich habe mir die Konfiguration beim Userbench genauer angeschaut , hier müssen sich die zwei 6 C Die s ein einziges 4 GB Ram Modul teilen , normalerweise sollte ein 8C Die einen Channel haben denke ich mal , zumindest wenn man Rome betrachtet ( 8 Die s / 8 channel ) , wenn man eine Erkenntniss aus dem Userbench ziehen kann , dann das selbst mit nur einem Channel 12 Kerne zu laufen scheinen und das das I/O Die das irgendwie hinbiegt , dürfte Latenz bzw Wartezeiten kosten denke ich mal , im Post # 73 hab ich mir Gedanken gemacht warum man so eine Konfig gewählt hat .

 

[C.J.]

Könnte es sogar sein, dass das ES nur mit 1,3Ghz RAM-Takt lief? Oben rechts steht beim ES "1,3Ghz" beim RAM. Auf reddit hat jemand mit seinem 2700X die 3,6Ghz Takt und 2666Mhz@CL19 nachgestellt und bei dem steht an der selben Stelle "2,7Ghz". Das würde zumindest die schlechten Multicore-Scores im Vergleich zum 2700X erklären, denn wenn das IF am RAM-Takt hängt, ist Datenaustausch natürlich ein krasser Flaschenhals.

https://www.userbenchmark.com/UserRun/14087903
https://www.userbenchmark.com/UserRun/14076820

Es scheint aber tatsächlich kein Zen+ zu sein wegen der Float Scores. Ich musste bei der Meldung zuerst an einen ähnlichen Leak von Zen 1 denken, wo sich nach hin- und herrechnen exakt exakt Sandy-Bridge-IPC für den vermeintlichen Zen ergab. Später kam raus, dass mit einem Sandy gebencht wurde und er nur als Zen ausgegeben wurde . Deswegen dachte ich zuerst, dass die Benches vielleicht von einem 1920X stammen.

 

[Ned Flanders]

@MK one

Jede Wette, was du siehst ist virtualisierte Hardware. Das ist eine VM Umgebung der 500gb Disk, 4gb RAM und der rest zugewiesen wurde. 1280x1024 Auflöung? 6.1gb von 4gb belegt (dynamisch erweiterter RAM der VM) etc pp. 2666MHz ECC CL19. Das ist einfach ein ROME ES. auf dem eine virtuelle Maschine läuft und auf der ist der Userbench durchgegangen.

Das macht halt leider die ganzen Messungen relativ wertlos.

 

[JohnVescoya]

Ja, das hab ich so verstanden, nur nicht, was es mit der Memory-Latency zu tun hat. Es sei denn, die meinen noch den L3. Ansonsten dürften alle Kerne auf einem Die die gleiche Latenz zum Arbeitsspeicher haben.

Für die unterschiedliche Latenz sollte eigentlich nur die Die zu Die Kommunikation von Bedeutung sein. Damit ja nur bei TR und Epic.

Meinst du damit die derzeitige Ryzen / Epycs / TR oder die zukünftigen Generationen?

"Ansonsten dürften alle Kerne auf einem Die die gleiche Latenz zum Arbeitsspeicher haben."

-> Nope, nicht bei der derzeitigen Konfig. Sieht man deutlich in Benchmarks. Kommt drauf an, auf welche Daten zugegriffen wird (Daten von Thread 0 mit Thread 4 zu zu greifen hat eine niedrigere Latenz als von 0 auf 8, auch wenn alle im gleichen Die, aber nicht im gleichen CCX liegen - es kommt drauf an, auf was zugegriffen wird).

https://www.pcper.com/files/review/2017-06-16/latency-pingtimes.png

Hier in der Grafik zu sehen:

Von 0 auf 1 ist die Latenz am niedrigsten (ist ja logisch, ist ja der gleiche Kern, nur eben der andere Thread). Von 0 auf 2 bis 7 ist immer noch sehr schnell. Und von 0 auf 8 bis 15 ist dann deutlich langsamer, weil alles einmal über den IF muss.

Alles im gleichen Die, das aus zwei CCX besteht.

 

[Ozmog]

normalerweise sollte ein 8C Die einen Channel haben denke ich mal

Eigentlich nicht. Denn genau das macht ja den Controllerchip so interessant. Die Speicherkanäle, ob nun 2 für AM4, 4 für TR oder 8 für Rome, sind für alle gleichermaßen da.
Daher sind dann auch die Latenzen gleich, weil dann kein Umweg mehr gemacht werden muss, wenn mehr Speicher gebraucht wird. Ansonsten hätte man wieder Probleme, wenn der Speicherkanal ausgelastet ist, oder dessen Speicher nicht für die Prozesse ausreicht. Wer will denn jetzt noch Single-RAM auf 8-Kerne

Das Speicher Interface wird auf dem Controllerchip wohl genauso am IF hängen, während alle Dice mit dem IF gleichermaßen verbunden sind. Somit können über einem Die Prozesse ausgeführt werden, die den vollen Zugriff auf den gesamten Speicher ohne Umwege erhalten können. Zuvor ist es ja nur über den Umweg auf die anderen Dice möglich, weshalb die Latenzen unterschiedlich sind. Die eigenen zwei Kanäle sind schnell und die restlichen 6 langsamer über die Die-zu-Die-Kommunikation.

Ergänzung (24. Januar 2019)

Nope, nicht bei der derzeitigen Konfig. Sieht man deutlich in Benchmarks. Kommt drauf an, auf welche Daten zugegriffen wird (Daten von Thread 0 mit Thread 4 zu zu greifen hat eine niedrigere Latenz als von 0 auf 8, auch wenn alle im gleichen Die, aber nicht im gleichen CCX liegen - es kommt drauf an, auf was zugegriffen wird).

Das ist dann aber die Latenz bei der Kommunikation zwischen den Kernen. Nicht die Latenz zwischen Kern und Arbeitsspeicher.

Der Speicherkontroller hängt am IF, genau wie die CCX, damit kann jeder CCX auf dem Die gleichermaßen mit dem Speicherinterface kommunizieren und damit auch jeder Kern.

 

[MK one]

@MK one

Jede Wette, was du siehst ist virtualisierte Hardware. Das ist eine VM Umgebung der 500gb Disk, 4gb RAM und der rest zugewiesen wurde. 1280x1024 Auflöung? 6.1gb von 4gb belegt (dynamisch erweiterter RAM der VM) etc pp. 2666MHz ECC CL19. Das ist einfach ein ROME ES. auf dem eine virtuelle Maschine läuft und auf der ist der Userbench durchgegangen.

Das macht halt leider die ganzen Messungen relativ wertlos.

möglich , ich kenne mich mit VM s nicht so aus , jedoch nehmen wir die HDD, diese ist tatsächlich eine 500 GB HDD
https://www.amazon.de/Samsung-SpinPoint-HD502HJ-interne-Festplatte/dp/B002J65AHQ
wäre nur ein Teil der Ressourcen zugewiesen worden wäre die Hardware nicht exakt erkannt worden , meiner Meinung nach ...

gehen wir zur GraKa , die stammt von 2013 ...
https://www.gamestar.de/artikel/amd...is-leistungs-sieger-bis-150-euro,3010456.html

davon abgesehen würde ich nicht Virtualisierungssoftware verwenden um zu sehen ob der ES den Userbench ohne zu murren durchläuft , es sei denn ich wollte die virtualisierungsfunktionen testen . Dafür ist es noch nen bisschen früh .
Worin ich dir als solches zustimme ist , die Ergebnisse sind wertlos , da nicht eine herkömmliche Konfiguration verwendet wurde .

wenn wir den Code betrachten 2D3212BGMCWH2_37/34_N , steht das D eindeutig für Desktop das BG für die 105W TDP Klasse ( bisher Zen+ /2700x , sehr wahrscheinlich das der 12 Kerner dort auch eingestuft wird )

 

[JohnVescoya]

Das ist dann aber die Latenz bei der Kommunikation zwischen den Kernen. Nicht die Latenz zwischen Kern und Arbeitsspeicher.

Der Speicherkontroller hängt am IF, genau wie die CCX, damit kann jeder CCX auf dem Die gleichermaßen mit dem Speicherinterface kommunizieren und damit auch jeder Ker

Stimmt. Hatte Kartoffeln auf den Augen. Bei einem Die ist die Latenz zum Ram für alle Kerne gleich. Erst ab zwei oder erst recht vier Dies ändert sich das. (bei 4 Dies insbesondere deshalb weil dann nur noch zwei Dies direkt am MC hängen und alle Ram Zugriffe des nicht am MC-Die einmal durch den IF und dann komplett durch das am MC hängende Die müssen)

Latenz zwischen den Kernen dürfte gleich inkonsistent bleiben, so lange AMD bei einer 2 x CCX Konfig pro Die bleibt und nicht auf einen Ringbus wechselt (Mesh wäre die schlechteste und daher unwahrscheinlichste Lösung).

Oder habe ich das verpennt und man weiß schon wie das gelöst wird?

 

[HerrRossi]

Die einzige Frage wird sein: kauft man den 12 Kerner oder doch direkt den 16 Kerner

 

[Ned Flanders]

Je nach vm, kannst du Hardware ids an das gast system schicken wie es dir beliebt.

 

[Gortha]

@Ned, wie und woher kommt die phänomenale SC Fließkommaleistung?

Das passt einfach nicht zu nem Hoax.

 

[Ozmog]

Latenz zwischen den Kernen dürfte gleich inkonsistent bleiben, so lange AMD bei einer 2 x CCX Konfig pro Die bleibt

Genau, und es kommt dann noch die Latenz zwischen den Dice bei den 12- und 16-Kern-Ryzen dazu. Also vom Prinzip her drei unterschiedliche Latenzen bei der Kommunikation zwischen den Kernen.

Ringbus ist Intel-Technik, dahin wird sicher nicht gewechselt. Es bleibt im jeden Fall bei IF und höchstwahrscheinlich bei zwei CCX pro Die. Die Kommunikation zwischen Die und Controller ist ja auch IF

 

[MK one]

Je nach vm, kannst du Hardware ids an das gast system schicken wie es dir beliebt.

bleibt aber der Code :
wenn wir den Code betrachten 2D3212BGMCWH2_37/34_N , steht das D eindeutig für Desktop das BG für die 105W TDP Klasse ( bisher Zen+ /2700x , sehr wahrscheinlich das der 12 Kerner dort auch eingestuft wird )

nehmen wir an das ist kein Fake , dann ist es auf keinen Fall ein EPYC Rome

gegen eine VM spricht meiner Meinung auch

[IMG]https://www.userbenchmark.com/resources/img/generic/ram/hynix.jpg[/IMG]
Hynix HMA851U6JJR6N-VK 1x4GB

1 of 4 slots used
4GB DIMM DDR4 clocked @ 1333 MHz

da steht eindeutig , einer von 4 Slots ( = Dualchannel ) besetzt

@ über mir : Es ist der IF2 , doppelte Datenrate , doppelter Takt ( schätz ich mal , analog PCIe 4.0 )

 

[user2357]

@Ozmog Bliebe die Latenz beim Zugriff auf den L3 des benachbarten Dies, wenn sich im IO-Chip nicht noch nen L4 befindet. Allerdings ist ein L4 durch die Verdopplung des L3 auf 32MB gegebüber dem Zen/Zen+ Design eher unwahrscheinlich, oder?
Edit: ah, warste schneller mit #91

 

[Faust2011]

Das wird man schon aus dem Grund nicht schaffen, weil die Treadripper Plattform ja noch mehr bietet als nur CPUs mit vielen Kernen.

Hallo @Roche , darauf bin ich bereits eingegangen und habe meine persönliche Erfahrung mit der HEDT-Plattform bzgl. CPU-Cores, PCIe-Lanes und Quad-Channel-RAM geschrieben. Ich zitiere mich selbst nochmals aus diesem Thread:

Ich habe hier seit knapp 4 1/2 Jahren ein Intel HEDT-System. Auf den Quad Channel und die 40 Lanes in meinem Fall kann ich pfeifen. Mein Kaufgrund waren damals insbesondere eben die Cores/Threads, denn die läppischen 4 im Mainstream wollte ich mir nicht antun. Ich denke, das ist auch weiterhin der Kaufgrund #1.

Zum RAM: Beim Quad-Channel konnte ich zusehen, wie im Mainstream mit jeder Iteration von Intel das RAM-OC besser funktioniert hat und die Dual-Channels an meinen spezifikationskonformen Quad-Channel vorbeigezogen sind

Zu den Lanes: Die hatte ich mir gegönnt, um mein Crossfire-System eine richtige Basis zu geben. Heutzutage ist das auch hinfällig. Und auch da bin ich der Meinung, dass ich keine 2, 3 oder gar 4 PCIe-SSDs einbauen muss.

 

[Ned Flanders]

@MK one

Du kannst auch mit Intel CPU einen AMD String deiner Wahl senden lassen und umgekehrt. Mir wärs auch völlig wurscht obs ein Rome oder ein Matisse ist, nur ist das halt alles so unzuverlässig. Man weiss nicht was die anderen VMs machen oder das Host Sys während der Bench läuft etc. Auch die L3 Latenz in der Latenz Leiter ist sehr strange, suggeriert sie das der L3 einen höheren Ping hat als der RAM etc...

Abhaken, weiter gehen... Kann sein, kann nicht sein, völlig wertlose info aus meiner Sicht.

 

[MK one]

Richtig , so oder so , wirklich verwertbare Infos werden nicht geliefert , wenn s kein Fake war / ist , ist das auch so beabsichtigt ....

 

[JohnVescoya]

Genau, und es kommt dann noch die Latenz zwischen den Dice bei den 12- und 16-Kern-Ryzen dazu. Also vom Prinzip her drei unterschiedliche Latenzen bei der Kommunikation zwischen den Kernen.

Inter Core Latenzen dürften dann so ausfallen:

(logische Cores sind gemeint)

Core 0 auf 1 -> extrem gering da selber physischer Core (Schätzung: 25 ns)
Core 0 auf 2 -> immer noch sehr gering, da alles im gleichen CCX (Schätzung: <40 ns)
Core 0 auf 8 -> höher, da: Core 0 -> IF -> Core 9 (Schätzung <100ns)
Core 0 auf 16 -> enorm hoch, da: Core 0 -> IF -> IO -> IF -> Core 16 (Schätzung >250 ns)

Die Schätzungen sind einfach pi x Daumen von mir völlig ohne sonstiges Hintergrundwissen geraten, angesichts aktueller Latenzen und erwarteten Verbesserungen durch die kleinere Fertigung und besseren IF. Also nagel mich nicht drauf fest.

Wenn das wirklich so kommt, dann werden nur die 1- Chiplet CPUs wirklich gamingtauglich sein, da bei allen anderen bei Cross-Die-Zugriffen über mehr als 8 physische Cores bzw 16 logische Cores hinweg die Latenzen zu brutal hoch sind und der Scheduler von Windows da garantiert Scheiße baut Heißt: Vorteile durch mehr Kerne werden durch Nachteile bei der Latenz aufgefressen. Reine Schätzung von mir.

(bin dennoch bisher sehr von Zen 2 überzeugt bzw auf das Endergebnis gespannt und glaube, dass es echt gut wird. Nur der Glaube an gamingtaugliche 16 Kerner ohne jegliche Nachteile halte ich für übertriebenes Wunschdenken).

 

[MK one]

hmm , glaube ich nicht , ich könnte mir zusätzliche IF 2 Crossbars zwischen den 2 Dies vorstellen unter Umgehung des I/O , schliesslich will Core 0 mit Core 16 direkt kommunizieren in deinem Beispiel und keine I/O Geschäfte erledigen

Beim Zugriff auf den Ram ist es anders als bisher , da gilt für alle Cores : Compute Die -> IF2 -> I/O ( IMC ) -> RAM

 

[JohnVescoya]

hmm , glaube ich nicht , ich könnte mir zusatzliche IF 2 Crossbars zwischen den 2 Dies vorstellen unter Umgehung des I/O , schliesslich will Core 0 mit Core 16 direkt kommunizieren in deimem Beispiel und keine I/O Geschäfte erledigen

Ich ging bisher davon aus, dass es keine Cross-Die-IF geben kann, weil alles über den IO-Chip laufen muss...

Zeigt mal wieder wie wenig wir bisher wissen Oder wie wenig Ahnung ich habe

 

[MK one]

zumindest auf dem Next Horizon Event , was primär sich zwar auf Epyc Rome bezog , war von einer verbesserten I/O Latenz die Rede

mehr IPC

2 X FPU , 2 X AVX2 ( 2 x 256 Bit statt 2 X 128 Bit )

und verringerte I/O Latency