ISSCC 2024: Warum AMDs Zen-4c-Kerne sogar schneller als der große Bruder sein kann

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.003
Mit den für Cloud-Anwendungen optimierten EPYC-Prozessoren mit Codenamen Bergamo sowie einigen Ryzen-Prozessoren für das Notebook-Segment präsentierte AMD im vergangenen Jahr die Zen-4c-Kerne. In Teilen sind wir damals bereits darauf eingegangen, wie es AMD schafft, doppelt so viele Kerne auf dem CCD unterzubringen. Mit bis zu 128 Kernen spielt dies für die EPYC-Prozessoren eine wichtige Rolle, aber natürlich darf auch die Leistung keinen Schritt rückwärts machen. Eine höhere Effizienz pro Kern waren neben der größeren Kerndichte der Fokus in der Entwicklung der Zen-4c-Kerne. In den Notebooks spielt diese ebenfalls eine wichtige Rolle. Schlussendlich nutzen auch die auf Infrastruktur ausgelegten EPYC-Prozessoren alias Sienna die Zen-4c-Kerne.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Da sieht man schön dass mehr cache eben nicht immer die lösung ist.
 
Dies gilt für alle SRAM-Zellen des L1 und darunter. Der L2-Cache verwendet auch bei Zen 4 schon 6T-Zellen.
"Erkauft" sich AMD hier kleinere Fläche durch mehr Leckströme und etwas weniger Geschwindigkeit oder sind deren 6T/8T Zellen diesbezüglich sehr nah beieinander?

EDIT:
Antwort gibts auf folgender Folie.

Leckströme wird dann auch alles beim alten sein, wenn nicht noch etwas größer, aufgrund der "aggressiven" Optimierungen. Auch da hat man wohl aktiv an anderer Stelle dann gegengesteuert:


Nun würde mich interessieren, ob die Fertigung schwieriger wurde bzw. der yield geringer ist. :fresse:
 
Zuletzt bearbeitet:
Macht doch bitte Mal einen technischen Artikel für Software-Entwickler was sie tun müssen damit sich die Software auf diesen Hybrid-Architekturen überhaupt so verhält wie erwartet.

"Automatisch" wird nämlich nichts richtig ausgewählt, man muss dem Betriebssystem schon explizit erklären welcher Thread zu welchem Zeitpunkt Effizienz oder Performance bevorzugt.

Was sich über Windows, Linux und Android unterscheidet. Und je nach Programmiersprache (C, .Net, Java) noch Mal unterschiedlicher ist.

Notwendig ist es trotzdem, und es ist etwas das jetzt jeder Entwickler wirklich verstehen muss, obwohl es vor 2 Jahren noch keinerlei Relevanz hatte.
 
Zuletzt bearbeitet:
Macht doch bitte Mal einen technischen Artikel für Software-Entwickler was sie tun müssen damit sich die Software auf diesen Hybrid-Architekturen überhaupt so verhält wie erwartet.
Zen4c ist keine Hybrid Architektur, sondern verfügt nur über andere Kerne als Zen4. Von den EPYCs gibt es aktuell drei verschiedene Typen die Zen4 z.B. EPY 9654 (96 Cores; 2,4GHz; 384MB Cache), Zen4 mit 3D V-Cache EPYC 9684X (96 Cores; 2,55GHz; 1152MB Cache) und Zen4c EYPC 9754 (128 Cores; 2,25GHz; 256MB Cache).
"Automatisch" wird nämlich nichts richtig ausgewählt, man muss dem Betriebssystem schon explizit erklären welcher Thread zu welchem Zeitpunkt Effizienz oder Performance bevorzugt.
Dafür gibt es die APIs mit denen man die Thread Affinity verändern kann, so dass die Threads nur auf bestimmten Cores laufen.
 
Dafür gibt es die APIs mit denen man die Thread Affinity verändern kann
Man wäre entweder der Softwareentwickler, der kann nämlich schon ewig bei Windows mit einer Maske bestimmen auf welchen Kernen ein Thread laufen soll. Oder es ist eben eine Software des CPU Herstellers, wie bei Intel der Thread Director.
 
Dafür gibt es die APIs mit denen man die Thread Affinity verändern kann, so dass die Threads nur auf bestimmten Cores laufen.
Und das sind für den Anwendungszweck leider die komplett falschen APIs weil die es erfordern würden das man erst die Topologie des Prozessor abfragt, und dann die Aufgabe des Schedulers übernimmt, und dann auf einem Prozessor der bereits ausgelastet ist die falsche Entscheidung getroffen hat.

Klassische Affinitäten machst du nur wenn du PCIe oder Cache-Zugriffe optimieren musst, alles andere macht der Scheduler in sämtlichen Randfällen besser.

Aber danke für die Bestätigung dass hier Wissenslücken sind ;)

Unter Windows, direkt gegen die Windows-API wäre z.B. das hier die richtige Antwort gewesen: https://learn.microsoft.com/en-us/w...ocessthreadsapi-thread_power_throttling_state Das deaktiviert auf einem nicht vollständig ausgelastetem Kern Turbo-Boosts, und setzt das Scheduling auf E-Cores als "akzeptabel". Bzw. umgekehrt fordert es die Performance-Kerne und Boosts soweit wie möglich.

Während unter Linux stattdessen die Priority-Class maßgeblich ist, und die Trennung zwischen den Kern-Typen eher "fließend" ist, mit einer Präferenz für Auslastung der P-Cores mit hoch-prioren Tasks bevor E-Cores als Ausweichoption aktiv werden. Einen "ich bevorzuge E-Cores"-Hinweis gibt es da so weit ich weiß zur Zeit gar keins.

Was Linux und Windows gemeinsam haben: Der Scheduler optimiert für "Instruktionen pro Watt" - was häufig vom Last-Profil über die Zeit abhängt, und gar nicht so sehr vom "gewünschten" Kern-Typ. Tasks die sagen "ich brauche keine Echtzeit" noch nebenher auf dem P-Core laufen zu lassen, weil der ansonsten in den Sleep-State müsste lohnt sich dann häufig doch...
Zen4c ist keine Hybrid Architektur, sondern verfügt nur über andere Kerne als Zen4
Es kommen aber Mobil-CPUs mit Zen4 / Zen4c Mix. Beziehungsweise es ist davon auszugehen dass AMD spätestens ab der nächsten Serie auch hybride Epics mit anbietet - es gibt schließlich auch im Serverbereich immer einzelne Services die besonders sensibel auf Single-Score-Performance reagieren. Und für letztere ist es - falls die Performance-Kerne bereits ausgelastet sind - trotzdem noch die bessere Entscheidung auf dem "falschen" Kern zu laufen als noch länger zu warten...
 
Zuletzt bearbeitet:
Und das sind für den Anwendungszweck leider die komplett falschen APIs weil die es erfordern würden das man erst die Topologie des Prozessor abfragt, und dann die Aufgabe des Schedulers übernimmt, und dann auf einem Prozessor der bereits ausgelastet ist die falsche Entscheidung getroffen hat.
Deswegen sage ich ja, dass dies vor allem die Aufgabe des eine Software des CPU Herstellers ist hier eine Software anzubieten, ähnlich wie Intels Thread Director. Aber bei den EPYC gibt es keine Hybridmodelle, nur solche mit C und solche mit den normalen Kernen und genauso wird es auch bei den kommenden Xeons von Intel sein, da wird es auch nur Modelle mit entweder P-Kernen (Granite Rapids) oder nur mit e-Kernen (Sierra Forest) geben.
Während unter Linux stattdessen die Priority-Class maßgeblich ist
Man kann im Programmen auch unter Linux die Kern Affinität bestimmten.
Es kommen aber Mobil-CPUs mit Zen4 / Zen4c Mix.
Ja und dann muss AMD eben eine Software liefern die möglichst gut darin ist dem Task Scheduler die Hinweise zu geben welche Threads er auf welche Kerne packen sollte. Kein Softwareentwickler wird besonders große Lust verspüren die Geometrie jeder einzelnen CPUs in seinen Programmen zu berücksichtigen. Er sollte seine Software sinnvoll multithreaded aufbauen und das Betriebssystem sollte dann mit Hilfe der SW des CPU Herstellers den Rest machen.
 
Man kann im Programmen auch unter Linux die Kern Affinität bestimmten
Das hat dann aber ebenfalls genau der falschen Effekt, und erzwingt im Endeffekt sowohl niedrigere Effizienz als höhere Latenzen.

Ich bleibe bei der ursprünglichen Aussage: Als Entwickler muss man verstanden haben das hybride Architekturen der Normalfall werden, und Priosierung von Threads/Hinweise an das Betriebssystem (soweit APIs existieren) essentiell sind. Einfach nur die Deklaration der Anforderungen und relativen Prioritäten.
Ja und dann muss AMD eben eine Software liefern die möglichst gut darin ist dem Task Scheduler die Hinweise zu geben welche Threads er auf welche Kerne packen sollte.
Das funktioniert als Konzept gar nicht. Für ein paar Anwendungen kann da AMD oder ähnliche ja noch Profile erstellen. Und ein bisschen Heuristik aus welchem Thread heraus GUI oder IO-APIs aufgerufen wurden für den Rest.

Aber für alle Anwendungen die mehr als triviales Threading mit einem homogenen Threadpool macht, und kein Profil bekommen hat, funktioniert das gar nicht gut.
 
Zuletzt bearbeitet:
Das hat dann aber ebenfalls genau der falschen Effekt
Ja, aber ich habe ja auch nicht gesagt das man es machen sollte um damit die Performance auf Hybrid CPUs zu verbessern, sondern nur das es eben auch geht.
und erzwingt im Endeffekt sowohl niedrigere Effizienz als höhere Latenzen.
Keine Ahnung was Du da nun genau meinst, aber der Effekt wenn Software ihre Threads fest an bestimmte Kerne pinnt, ist eben das dieser Kern dann ggf. total ausgelastet wird wenn zwei Programm laufen die Threads haben die an die gleichen Kerne gepinnt sind, während andere Kerne vielleicht sogar Idle sind, da ja das eine Programm nichts vom anderen weiß.
Das funktioniert als Konzept gar nicht.
Das sehe ich anders.
Für ein paar Anwendungen kann da AMD oder ähnliche ja noch Profile erstellen.
Befasse dich mal mit der Funktionsweise des Intel Thread Director, keine Ahnung ob es sowas auch schon von AMD gibt, die haben ja nun gerade erst mit den paar APUs überhaupt erstmals CPU eingeführt, bei denen eben nicht alle Kerne gleich konstruiert sind.
 
Klingt sehr interessant.
Ich bin dann mal auf die praktische Umsetzung und erste "real world" Tests gespannt!
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh