AMD stellte 12 EPYC-Prozessoren mit bis zu 32 Kernen offiziell vor

[mr.dude]

was die IPC angeht, bin ich nicht ganz so optimistisch. Bei einer völlig neuen Architektur wie Zen, wird man aber sicher so 5-7% rausholen können. Siehe Vishera auf Bulldozer.

Ich sprach ja von 2 Generationen. Von Bulldozer auf Steamroller waren es ~15%. Aber da hatte AMD eh mehr mit Fehlerbeseitigung zu tun. Da bin ich bei Zen schon etwas optimistischer. Und wie gesagt, Lisa Su selbst sprach von einer Reihe recht einfacher Kernverbesserungen.

Mir scheint es eher so zu sein, dass hier massenweise nicht verstanden wird, was AMD an Folien gezeigt hat. Siehe AMD's EPYC Server CPU - Sizing Up Servers: Intel's Skylake-SP Xeon versus AMD's EPYC 7000 - The Server CPU Battle of the Decade?, hier sieht man am zweiten Bild (dick mit Naples überschrieben), dass jede CPU aus vier NUMA-Knoten besteht, die via Infinity Fabric verbunden sind.

Erstmal kann ich auf den Folien kein Wort über NUMA lesen. Und selbst wenn es dastehen würde, das würde deine Aussagen wie "ein Dualsocket Epyc System verhält sich logisch wie ein Octosocket System" trotzdem nicht richtig machen. Stichwort Kohärenz.

Die Infinity Fabric ist nichts anders als eine überarbeitete Version von HyperTransport und das war und ist vergleichbar zu QPI bzw. UPI wie es Intel nun nennt.

Nein. IF ist zB protokollunabhängig, das sind die anderen nicht.

Hinsichtlich des STREAM-Benchmarks: also der "original"-Benchmark wird mit OpenMP parallelisiert. Und wenn ich mir den Quellcode ansehe, sieht das für mich (als C+OpenMP-Laien) doch sehr danach aus, als ob der auch sehr gut über Numa-Nodes skaliert, da der verwendete Speicher auch auf der jeweiligen NUMA-Node alloziert werden kann/wird (vgl. hier: http://prace.it4i.cz/sites/prace.it4i.cz/files/files/advancedopenmptutorial_2.pdf#page=6). D.h. der Benchmark ist eben eine dieser Anwendungen, wo das mit dem NUMA ganz gut funktioniert und ich weiß nicht, was mr.dude damit beweisen will...

Nichts. Ich sagte lediglich, dass die bei EPYC gemessene Speicherbandbreite nicht mit einer Dual-Channel Anbindung, wie von jdl behauptet, machbar wäre. Ich frage mich eher, was du mit deinem OpenMP Link beweisen willst. Für meine Aussage hat dieser keine Relevanz.

 

[flxmmr]

Nichts. Ich sagte lediglich, dass die bei EPYC gemessene Speicherbandbreite nicht mit einer Dual-Channel Anbindung, wie von jdl behauptet, machbar wäre. Ich frage mich eher, was du mit deinem OpenMP Link beweisen willst. Für meine Aussage hat dieser keine Relevanz.

Nunja, da der STREAM-Benchmark (wie du in den Links und im Quellcode problemlos nachschauen kannst) offensichtlich die Speicherbandbreiten aller NUMA-Nodes aggregiert, weiß ich nicht, wie du aus diesem Gesamt-Ergebnis des Benchmarks ableiten willst, dass ein einzelnes Modul/NUMA-Node (wenn es einzeln rechnet) ebenso die volle "xyz"-Channel-Anbindung bekommt, wie alle NUMA-Nodes/Module zusammen. Übrigens sieht man bei anandtech recht schön, was jdl meint: Memory Subsystem: Bandwidth - Sizing Up Servers: Intels EPYC 7000 - The Server CPU Battle of the Decade? – alle Threads auf einem NUMA-Node führt eben zu einer Bandbreite, die so gar nicht dem Octa-Channel entspricht, verteilt man auf 2 Nodes, steigt die Bandbreite dann plötzlich auf das doppelte...

 

[mr.dude]

Nunja, da der STREAM-Benchmark (wie du in den Links und im Quellcode problemlos nachschauen kannst) offensichtlich die Speicherbandbreiten aller NUMA-Nodes aggregiert, weiß ich nicht, wie du aus diesem Gesamt-Ergebnis des Benchmarks ableiten willst, dass ein einzelnes Modul/NUMA-Node (wenn es einzeln rechnet) ebenso die volle "xyz"-Channel-Anbindung bekommt, wie alle NUMA-Nodes/Module zusammen.

NUMA ist doch völlig irrelevant in diesem Kontext. Auch NUMA kann die Hardwarefähigkeiten nicht aushebeln. Anandtech hat die Speicherbandbreite mit verschiedenen Threadanzahlen und Sockelzuweisungen getestet, zB 8 Threads auf einer CPU / einem Sockel. Ergebnis, bis zu fast 100 GB/sec. Nochmal, wie willst du das mit einem Dual-Channel SI erreichen? Antwort, geht nicht mit DDR4.

alle Threads auf einem NUMA-Node führt eben zu einer Bandbreite, die so gar nicht dem Octa-Channel entspricht

Doch, tut sie. Dir ist anscheinend nur nicht klar, was ein NUMA Node bei EPYC ist. Siehe Beitrag von unl34shed. Ist aber auch nicht wichtig für die Diskussion. jdl sprach nicht von NUMA Nodes, sondern von "Zen CPUs" und dass die alle nur Dual-Channel hätten. Was im Fall von EPYC glatt gelogen ist, wo jede CPU 8 Speicherkanäle besitzt.


Das kuriose ist ja, gewisse Leute wollen hier implizieren, dass AMDs IF Designs nachteilig ist und nicht so gut angebunden ist wie Intels Mesh. Dabei zeigen Tests, dass AMD bei wenigen Threads sogar klare Vorteile hat, siehe AT:

1 Thread
EPYC 7601 DDR4-2400: 27490 MB/sec
Xeon 8176 DDR4-2666: 12224 MB/sec

2 Threads
EPYC 7601 DDR4-2400: 27663 MB/sec
Xeon 8176 DDR4-2666: 14313 MB/sec

Der einzige Bandbreitenvorteil, den Intel hier durch das monolithische Design hat, wenn zB 4-8 Lastthreads anliegen, die sich auf ein einziges Die bei AMD verteilen. Solch ein Verhalten wäre aber völlig untypisch, erst recht bei Servern mit so vielen Kernen. Solche Probleme werden vom OS Scheduler geregelt. Für die Praxis also ziemlich irrelevant.

 

[jdl]

Ansonsten: Die Verbindungen zwischen einzelnen Knoten/Dies sind bei AMD etwas besser ausgebaut, als bei aktuellen Intel-Generationen, wo man das Mesh im Kern hat (das ist per se def. nicht schlechter?!) und dann UPI (mit rund 20 GB/s?, aber 2 davon für Dual-Socket-Systeme?!) zwischen den Sockeln hat – bei AMD ist zwischen den 8er-Dies im Package jew. 40GB/s Transfer und jedes Die hat dann in Mehr-Sockelsystemen noch auf dem zweiten Sockel einen "direkten" Nachbarn (mit jew. 40GB/s Transfer). Und woraus schließen die Experten hier jetzt eigentlich, dass AMD besser sein muss/wird (für jeden Workload) und dass das nicht im Verhalten bisherigen NUMA-Nodes entspricht – weil die Latenzzeit niedriger ist, als bisher und man mehr Nodes hat?

Die Xeon Gold und Platinum haben 10,4GT/s über die UPI Links und davon deren drei (Gold 5100 zwei). Die Silver und schlechter sind langsamer haben nur 9,6GT/s und zwei UPI Links. Wenn sich das noch so errechnet wie bei QPI ergäbe das 3x41,6 GByte/s und 2x38,4GByte/s, jeweils bidirectional und Rohdaten. AMD schafft beim Epyc on die 42,6GByte/s pro InfinityFabric Connection bidirectional und Rohdaten, für die Koppelung der Sockel ist es geringfügig weniger.

Hinsichtlich des STREAM-Benchmarks: also der "original"-Benchmark wird mit OpenMP parallelisiert. Und wenn ich mir den Quellcode ansehe, sieht das für mich (als C+OpenMP-Laien) doch sehr danach aus, als ob der auch sehr gut über Numa-Nodes skaliert, da der verwendete Speicher auch auf der jeweiligen NUMA-Node alloziert werden kann/wird

Und dadurch wird gerade der Idealfall abgebildet und nicht das worst case Szenario. Interessant wird es doch erst dann, wenn die NUMA-Knoten miteinander kommunizieren müssen.

- - - Updated - - -

NUMA ist doch völlig irrelevant in diesem Kontext.

Dann schau Dir nochmal die Tabelle bei Anandtech an http://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12. Die Werte für 8 Threads sprechen eine sehr deutliche Sprache! 32703MB/s für 8 Threads auf einem NUMA-Knoten und 98747MB/s für 8 Threads auf verschiedenen NUMA-Knoten. Das ist genau der NUMA-Effekt wie man ihn auch bei anderen Plattformen sieht.

 

[flxmmr]

NUMA ist doch völlig irrelevant in diesem Kontext. Auch NUMA kann die Hardwarefähigkeiten nicht aushebeln.

nur bringt die ganze Hardware nix, wenn man die Software nicht für NUMA programmiert (nur damit kann man die voll nutzen...) – merkst du was?!

Nein:

Das kuriose ist ja, gewisse Leute wollen hier implizieren, dass AMDs IF Designs nachteilig ist und nicht so gut angebunden ist wie Intels Mesh. Dabei zeigen Tests, dass AMD bei wenigen Threads sogar klare Vorteile hat, siehe AT:

Der einzige Bandbreitenvorteil, den Intel hier durch das monolithische Design hat, wenn zB 4-8 Lastthreads anliegen, die sich auf ein einziges Die bei AMD verteilen. Solch ein Verhalten wäre aber völlig untypisch, erst recht bei Servern mit so vielen Kernen. Solche Probleme werden vom OS Scheduler geregelt. Für die Praxis also ziemlich irrelevant.

- bei Intel kann man bis zu 30 Kerne auslasten, ohne sich um die unterschiedliche Speicheranbindung der (für das letzte Prozent Performance vmtl. auch...) jeweiligen Kerne zu bekümmern.
- wenn die 4-8 Lastthreads des EPYC einfach einen geteilten Speicherpool verwenden und sich nicht drum kümmern an welche NUMA-Node der Speicher angebunden ist, so kann es auch mit der IF zu recht interessanten Problemen kommen (etwas so wie heute bei Dual-Socketsystemen auch...). Da bringt dann die aggregierte Bandbreite der jeweiligen Nodes auch nix mehr.
- ich weiß nicht, seit wann der OS-Scheduler für das Speichermanagement auf NUMA-Nodes zuständig ist!? Offensichtlich ist dir das Problem nicht im Ansatz bewusst.

 

[jdl]

- ich weiß nicht, seit wann der OS-Scheduler für das Speichermanagement auf NUMA-Nodes zuständig ist!?

NUMA Systeme kennen zwei Standard policies der Speicherzuteilung - thread locale und interleaved (das lässt tief im BIOS/UEFI konfigurieren). Üblich ist die erste Policy, wenn man vom OS Speicher anfordert, bekommt man wegen des Memory Overcomitments sofort eine Rückmeldung, das der Speicher bereitstünde. Physikalisch wird der Speicher aber erst beim ersten Schreiben auf den allozierten Speicher angelegt. Hierbei ist entscheidend auf welchem Core der Thread läuft und welche Policy verwendet wird. Ist es die thread locale Policy, dann wird der Speicher auf demselben NUMA-Knoten physikalisch alloziert. Wenn man diese Policy als Standard implizit voraussetzt, kann man Speicher auf bestimmten NUMA-Knoten allozieren, in dem man die Threads auf bestimmten Cores laufen lässt und den Speicher von diesen Threads beschreiben lässt. Nichts anderes passiert im Stream Benchmark, Anandtech hat dazu mit Hilfe des Linux numactl Programms die Threads an Cores fest gebunden. Wenn man das nicht macht, dann werden immer wieder Threads vom Scheduler auf andere Cores verteilt. Worst Case wäre, wenn dies gerade während einer größeren Allokation geschieht und dann Teile der Felder auf verschiedenen Knoten lägen.

Da ich bisher nur HPC auf *I*X Systemen gemacht habe, kann ich nicht sagen wie man es unter Windows löst außer man würde die hwloc Library verwenden. Der Linux Weg wäre, mit Hilfe eines System Befehls die Threads an die Cores zu binden und dann die libnuma zu nutzen, um den Speicher explizit auf den betreffenden NUMA-Knoten anzufordern.

Nachtrag:
Dann ist man nicht mehr darauf angewiesen, dass man auf implizite Vorgaben setzt. Man hat so die direkte Kontrolle was das Programm macht.

 

[mr.dude]

Dann schau Dir nochmal die Tabelle bei Anandtech an Memory Subsystem: Bandwidth - Sizing Up Servers: Intel's Skylake-SP Xeon versus AMD's EPYC 7000 - The Server CPU Battle of the Decade?. Die Werte für 8 Threads sprechen eine sehr deutliche Sprache! 32703MB/s für 8 Threads auf einem NUMA-Knoten und 98747MB/s für 8 Threads auf verschiedenen NUMA-Knoten. Das ist genau der NUMA-Effekt wie man ihn auch bei anderen Plattformen sieht.

Nein, das hat mit NUMA überhaupt nichts zu tun. Das ist schlichtweg das Hardwaredesign. Irgendwie habe ich das Gefühl, einige können Hardware nicht von NUMA unterscheiden.


Hier gibt's ein Video zu EPYC, wo AMD auch nochmal klarmacht, dass EPYC so designed ist, dass es sich wie ein monolithisches Design verhält, und nicht wie behauptet wie ein typisches 4P System. Möglich machen es doppelt so hohe Bandbreite wie benötigt On-Die und Overprovisioning. Ab 03:30 etwa:

https://www.youtube.com/watch?v=W5IhEit6NqY

nur bringt die ganze Hardware nix, wenn man die Software nicht für NUMA programmiert (nur damit kann man die voll nutzen...)

Man muss auch nicht für NUMA programmieren, um die Möglichkeiten einer EPYC CPU auszureizen. Siehe Video.

- bei Intel kann man bis zu 30 Kerne auslasten, ohne sich um die unterschiedliche Speicheranbindung der (für das letzte Prozent Performance vmtl. auch...) jeweiligen Kerne zu bekümmern.

Nein. Es sind bei Intel 28 Kerne. Und bei AMD sind es 32 Kerne.

- wenn die 4-8 Lastthreads des EPYC einfach einen geteilten Speicherpool verwenden und sich nicht drum kümmern an welche NUMA-Node der Speicher angebunden ist, so kann es auch mit der IF zu recht interessanten Problemen kommen (etwas so wie heute bei Dual-Socketsystemen auch...). Da bringt dann die aggregierte Bandbreite der jeweiligen Nodes auch nix mehr.

Nein. Bitte erstmal mit IF beschäftigen und wie es funktioniert und nicht immer so allgemeinen Quark runterleiern, der fürs Thema belanglos ist.

- ich weiß nicht, seit wann der OS-Scheduler für das Speichermanagement auf NUMA-Nodes zuständig ist!? Offensichtlich ist dir das Problem nicht im Ansatz bewusst.

Es ging auch nicht ums NUMA Speichermanagement, sondern um die Bandbreite pro Thread. Offensichtlich ist dir das Problem nicht im Ansatz bewusst.

 

[flxmmr]

Effektiv erzählt der doch, dass das IF so viel Bandbreite hat, dass man damit die klassischen Probleme mit non-NUMA-Software (hinsichtlich Bandbreite/Latenz) einfach erschlagen kann. Das ist natürlich schön, allerdings weiß noch niemand so genau, ob das für non-Benchmark-Anwendungen wirklich so gut skaliert...
Hinsichtlich der Bandbreite pro Thread hast du in der Theorie von AMD damit durchaus recht, wenn das so klappt, wie angepriesen, sollte man ja über die IF auf den Speicher aller Nodes/Module schnell zugreifen können (dann eben auch mit "Octo-Channel"-Bandbreite). Leider sieht man in den realen Benchmarks (bspw. Anandtech) diese Bandbreite aber nur, wenn die Threads alle auf unterschiedlichen Modulen laufen... → anscheinend ist das IF doch nicht die Lösung aller non-NUMA-Probleme – auch nicht im Benchmark. Vllt. sieht das in Anwendungen besser aus, aber das werden dann die Leute entscheiden, die diese Anwendungen auch in einer Größenordnung fahren, dass nicht nur das aktuell günstigste Package des OEM/Systemhauses eine Rolle spielt, sondern tatsächlich die CPU-Leistung. Nicht ich, nicht du .

 

[jdl]

Nein, das hat mit NUMA überhaupt nichts zu tun.

Die Screenshots unter Linux sind sehr eindeutig (es ist ein NUMA System), und unter Linux kann AMD besser die CPUs in das OS integrieren als dies unter Windows der Fall ist. Erst mit einem größerem Update von Windows wird es wahrscheinlich die notwendigen Änderungen geben.

Hier gibt's ein Video zu EPYC, wo AMD auch nochmal klarmacht, dass EPYC so designed ist, dass es sich wie ein monolithisches Design verhält, und nicht wie behauptet wie ein typisches 4P System.

In diesem Video wird gefragt, ob Threadripper unter Windows als NUMA-System erscheint, und das wird verneint. Bitte auf die exakte Formulierung achten.

 

[[HOT]]

NUMA? So ein Schwachsinn. Sowohl SummitRidge (2 Module) als auch Threadripper (4 Module) als auch Epyc (8 Module) werden als ein Prozessor erkannt und verhalten sich auch so. Das hat rein gar nichts mit NUMA zu tun. Reines Bashing in meinen Augen. Das sind einfach gemeshte Module, nur dass sie nicht auf einem Die monolithisch gemesht sind sondern teilweise über den Träger, das ist der einzige Unterschied. Zudem ist Infinity Fabric kein NUMA-Protokoll.

 

[mr.dude]

Hinsichtlich der Bandbreite pro Thread hast du in der Theorie von AMD damit durchaus recht, wenn das so klappt, wie angepriesen, sollte man ja über die IF auf den Speicher aller Nodes/Module schnell zugreifen können (dann eben auch mit "Octo-Channel"-Bandbreite). Leider sieht man in den realen Benchmarks (bspw. Anandtech) diese Bandbreite aber nur, wenn die Threads alle auf unterschiedlichen Modulen laufen...

Diese "realen Benchmarks" haben allerdings wenig mit der Praxis zu tun, da Anandtech die Threads festpinnt. Anandtech ging es lediglich darum, die Hardwaremöglichkeiten, bedingt durch das Design, aufzuzeigen. Wie Anwendungen in der Praxis skalieren, ist nochmal eine andere Geschichte.

In diesem Video wird gefragt, ob Threadripper unter Windows als NUMA-System erscheint, und das wird verneint. Bitte auf die exakte Formulierung achten.

Bezug zu meiner Aussage? In dem Video wird klar gesagt, "... this helps us, make the socket design behave like a single monolithic design".

Talbot erklärt auch die Unterschiede und warum sich das 4-Die Package eben nicht wie ein normales 4P System verhält. ZB die direkten Links zwischen den Dies, was Transfers mit lediglich einem Hop ermöglicht. Socket zu Socket Transfers benötigen zwei Hops, so wie bei Intel, AFAIK. Und so wie ich ihn verstehe, kann quasi ein Die die Bandbreite eines anderen Dies über den entsprechenden Link mitbenutzen, wenn Bedarf besteht. Bei doppelter IF Bandbreite im Vergleich zu einem Speicherkanal könnte einem Die theoretisch die Bandbreite von 4 Speicherkanälen zur Verfügung gestellt werden. Selbst wenn das in der Praxis nie erreicht wird, es ermöglicht Anwendungen trotzdem zu skalieren, auch ohne NUMA-aware Software und unabhängig davon, wie Lastthreads verteilt werden. Genau das was auch Talbot sagt.

 

[flxmmr]

"realer Benchmark" = STREAM? Und genau da sieht man, dass 4x2 (oder 4) Speicherkanäle auf 4 Module verteilte bei non-Numa-Applikationen auf einer NUMA-Node eben doch nur so gut sein werden, wie 1x2/4... Und bis AMD irgendeine Möglichkeit bietet, dass Anwendungen auf einer Node dann transparent über das IF alle 8 Speicherkanäle nutzen können, wird noch Zeit vergehen, einfach so läuft das wohl eher nicht (sonst wäre es beim STREAM wohl erkennber) . (Die Frage ist: braucht man das überhaupt für irgendeine Anwendung?)

Ein anderer Punkt ist, ob das IF (mit nominell nicht sooo viel größerer Bandbreite, als UPI, wenn jdl Recht hat) in realen Anwendungsfällen für non-NUMA-Applikationen die bisher bestehenden Nachteile auslöscht. Das weiß man bis jetzt nicht, das zeigt wohl kein klassischer Benchmark, bei dem am Ende eine Nummer steht und die Leute in den Rechenzentren werden das schön für sich selbst herausfinden.

 

[mr.dude]

Und bis AMD irgendeine Möglichkeit bietet, dass Anwendungen auf einer Node dann transparent über das IF alle 8 Speicherkanäle nutzen können ...

Was irgendwie Unsinn wäre, sofern du mit Node ein Die meinst. 8 Kanäle für 8 Kerne bzw 1 Kanal pro Kern wäre Overkill. So eine Möglichkeit brauchst du gar nicht. Aber theoretisch besteht die Möglichkeit ja jetzt schon. Schliesslich sind alle Dies mit jeweils einem Link direkt miteinander verbunden. Limitierender Faktor ist hierbei die IF Bandbreite.

 

[pumuckel]

.... es beginnt

Supermicro H11DSi-NT retail Preisvergleich Geizhals Deutschland

 

[butcher1de]

Gerade bei Winfuture gefunden Project 47: AMD liefert Petaflops-Supercomputer in Serie aus - WinFuture.de sehr schön.

 

[butcher1de]

https://www.heise.de/newsticker/meldung/Cray-CS500-Supercomputer-Cluster-mit-AMD-Epyc-7000-4026972.html Sehr gut ! Glückwunsch an AMD.