ETI1120 schrieb:
Wie hieß es so schön in den Unilabors. Wer misst misst Mist. Wer viel misst misst viel Mist.
Was hat die Phrasendrescherei mit dem Thema zutun?
Fakt ist dass Zen5 sehr wohl von Latenzverbesserungen profitiert. Das kann man leicht selber mit DRAM timings ausprobieren. Der Aida Latenzfix ist kein Hinweis dass Zen5 aufgrund des großen Caches und ROBs eh schon weitgehend Latenzunabhängig operiert. Und das war deine ursprüngliche Aussage, nämlich dass eine latenzärmere Anbindung zwischen I/O Die nichts bringt. Ich denke es ist sehr wahrscheinlich dass Zen6 genau dort ansetzen wird, denn der IFOP Interconnect hat sich nun seit Zen2 nicht verändert.
ETI1120 schrieb:
Und? Epyc Packaging ist auch BEOL bzw. post-Fab (das ist was relevant ist).
Zen5 ist auch post-fab . Selbst Mi300A ist post-fab, denn nur die XCDs sind hybrid gebondet, der HBM und die I/O DIEs haben auch wieder µbumps.
ETI1120 schrieb:
Die MI300A hat ganz andere Anforderungen an die Bandbreite als eine EPYC CPU. Und weil es eben andere Anforderungen sind, kommen andere Lösungen heraus.
Das ist ein Zirkelschluss, kein Argument. Und es ignoriert auch den eigentlichen Punkt der Diskussion den
@stefan92x angesprochen hat: Dass man durch 3d Packaging bessere Latenzen erreichen kann als mit dem bisherigen Infinity-fabric on Package.
Es ist naheliegen dass Radeon Instinct stacked silicon verwendet weil das eine Vorraussetzung für die Benutzung von HBM ist. Mi-300A verwendet das allerdings auch für den i/o DIE. Die Diskussion ging nicht darum ob Epyc HBM braucht (was in AVX512 Edgecases sicher auch interessant wäre, also ein Mi-300AAA it nur CPU DIEs und HBM). Sondern es ging um die Anbindung des IO-DIEs.
Deine ursprüngliche Aussage war dass es technisch nicht möglich ist bei Epyc den i/o DIE über 3D oder 2.5D statt über das Flipchip Package anzubinden. Jetzt ruderst du zurück und behauptest du hättest lediglich gesagt dass es finanziell nicht sinnvoll wäre. Ich frage nur wo du das wissen her nimmst, da es sich imo nicht deckt mit dem Indusrietrend.
ETI1120 schrieb:
Die MI300A/X hat im Gegensatz zur MI250X keine Siliziumbrücken mehr, sondern wieder einen Siliziuminterposer. Warum wohl?
Weil man nicht nur den HBM mit dem jeweiligen DIE verbindet, sondern auch die DIEs untereinander. Die Fläche an Brücken nähert sich dann eh einem interposer an.
ETI1120 schrieb:
Zen 5 wurde nicht als Kern fürs Gamings entworfen. Es gibt Aufgaben bei denen Zen 5 deutlich stärker als beim Gaming zulegt.
Die eigentliche Frage ist, was muss gemacht werden um das breitere Design von Zen 5 besser auszulasten. Die bestehende Software neu komplieren, oder neue Software schreiben.
Das muss nicht unbedingt mit Zen5 alleine zutun haben. Ein Teil der architekturellen Änderungen hat AMD schon vorrausschauend für Zen6, Zen7 gemacht. Das Potential könnte also erst in künftigen CPU-Generationen gehoben werden. Lisa hat mal durchscheinen lassen dass AMDs teams anscheinend nach einer art continuous delivery modell arbeiten und daher wenig anfällig für Verzögerungen sind. Natürlich gibt es noch fertigungstechnische Verzögerungen, aber bei der Architektur kommt halt rein was bis dahin fertig und getestet ist. Angeblich hat das Managemend bei Strix point eine Ausnahme gemacht weil man unbedingt noch eine neuere NPU version rein haben wollte, wodurch der Chip den OEMs erst verspätet zur Verfügung stand.
Hier ein paar Aussagen von Mike Clark aus dem Interview von Gerorge Cozma, die ein wenig aufschluss darüber geben wieso wir bei Zen5 wimöglich nicht die vollen Vorteile des breiteren Cores sehen:
danach gefragt wieso Zen5 kein NOP Fusion mehr unterstützt was man mit Zen4 erst eingeführt hatte:
Zen 5 is sort of a foundational change to get to that 8-wide dispatch and 6 ALUs. We’re now going to try to optimize that pinch point of the architecture to get more and more out of it and so you know as we move forward, no op fusion is likely to come back as a good leverage of that eight wide dispatch. But for the first generation, we didn’t want to bite off the complexity.
Und über die 4 -> 6 Integer Alus:
Yeah, as we think of Zen 5 we needed a new foundation for more compute to drive future workloads that continue to stay on this cadence of double digit IPC per generation. So you know we have been at the original Zen was 4-wide [dispatch and] 6 ALU’s and we had done a lot of innovation to really you know leverage all those resources [in] Zen, Zen 2, Zen 3, Zen 4. But we really we’re not to be able to keep that up, so we really needed to reset that foundation of a wider unit, more ALUs, more multiplies, more branch units, and then be able to leverage that like we did with the originals then to provide innovation going forward. [...] and you’ll see the actual foundational lift play out in the future on Zen 6 even though it was really Zen 5 that set the table for that and let software innovate.
ETI1120 schrieb:
Über diesen Punkt sind wir bei CPUs schon sehr lange hinaus. Die einfachen Tricks sind schon vor 20 Jahren ausgegangen.
habe den Dchreibfehler für dich gefixt:
"Über diesen Punkt sind wir bei
X86 CPUs schon sehr lange hinaus. Die einfachen Tricks sind schon vor 20 Jahren ausgegangen."
ETI1120 schrieb:
Mal ein kleines bisschen über den Tellerand hinausschauen, ...
Den Wunsch gebe ich gerne auch zurück 🤲