C.J. schrieb:
Die Taktraten finde ich ehrlich gesagt relativ underwhelming. Bei 280W TDP 2,4Ghz auf 64 Kerne bedeutet das kein Fortschritt gegenüber Zen 3 und 7nm:
Nur dass es in dem Bereich, in dem diese CPUs verwendet werden, nicht unbedingt auf mehr Takt ankommt, sondern auf ein paar weitere Faktoren, die AMD mit Zen 4 angegangen ist und dazu zählt auch der IOD und speziell das Speicherinterface, dass von 8-Channels auf 12-Channels anwächst.
C.J. schrieb:
Wenn man bedenkt, dass der IPC-Gewinn diesmal geringer ausfällt (angeblich <10%) und Zen 4 eher über die Taktraten kommen soll (>=5,5Ghz im Desktop), dann ist das ein Effizienzgewinn von <10% bei Genoa gegenüber Milan.
Die IPC hat AMD bereits im Mittel um 9 % (sie sagen 8 - 10 %). Im Desktop-Bereich und im Workstation-Bereich wird Zen4 über den Takt kommen, nur wie erwähnt, ist der Takt im Serverbereich nicht der entscheidende Punkt!
Ich hab jetzt schon einige Epycs mit 48 und 64 Kernen im Betrieb gesehen und kann aus Erfahrungen im Bereich Datenbanken (klassische "SQL" sowie auch NoSQL in Form von klassischem Key-Value als auch "Solr") sagen, dass die Probleme mit diesen Monstern nicht die Leistung der Kerne sind, die sind schnell genug, sondern dass die Kerne in entsprechenden Lastszenarien quasi an der Bandbreite verhungern und man einiges an Hirnschmalz in die SQL-Konfigurationen legen muss und es teilweise besser ist statt einen 48 oder 64 Kerner, einen 2 × 32 zu wählen, weil dann jeder Kern entsprechend mehr Bandbreite hat.
Je nach Szenario werden die großen Modelle alleine durch das breitere SI zulegen können an Leistung in bestimmten Szenarien.
C.J. schrieb:
Entsprechend sind auch 96 Kerne auf 360W nicht so krass, wenn der Takt noch weiter sinkt (2,0 bis 2,15Ghz).
Klar, die 2,0 - 2,15 GHz wirken hier erst mal wenig, aber im Serverbereich - in dem man solche CPUs einsetzt - braucht man nicht viele schnelle Kerne, sondern einfach viele Kerne, weil man viele parallele Tasks hat, die bearbeitet werden. In vielen Szenarien benötigst du dazu aber auch entweder sehr viel Cache - Epyc 0003X - oder entsprechend Bandbreite durch ein großes SI.
Selbst wenn die 96 Kerne bei 3 GHz laufen würden, würden sie in den meisten Fällen einfach an Daten verhungern.
C.J. schrieb:
Also entweder ist Zen 4 nicht gut gelungen oder die Zahlen sind einfach falsch oder der Base Clock muss anders interpretiert werden, z.B. weil AMD doch auf single-cycle AVX512 setzt und die Taktraten dann der Baseclock für volle AVX512-Last ist.
Es muss weder das eine (nicht gut gelungen) noch das andere (die Zahlen sind einfach falsch) zutreffen. AVX-512 ist aktuell nur VNNI sowie BFloat16 bestätigt, alles Weitere werden wir sehen. Man kann aber davon ausgehen - was etwas durch die Gerüchteküche geistert - das AMD bei Zen 4 erst mal die neuen Register ins Registerfile einpflegt (32 statt 16) und vorerst entweder "2 Durchläufe" pro ALU macht oder beide ALUs wieder miteinander verschaltet.
Gerade AVX-512 kann auch wieder richtig Bandbreite benötigen und ja es kommt DDR5. Man wird hier aber auch erneut abwarten müssen was kommt.
C.J. schrieb:
Die realen Taktraten könnten dann deutlich höher liegen, so wie bei Intel mit AVX512-Last vs "normale" Last.
Natürlich können die Taktraten höher liegen, nur hat AMD aktuell für AVX-Lasten kein Offset angeben und man wird auch hier warten müssen, ob AMD für AVX512 ein Offset definiert oder nicht.
Das ändert aber alles nichts daran, dass Takt das kleinste Problem der Epycs ist, sondern dass die 48er, die 64er und die 96er ganz andere Sorgen haben und diese Prozessoren nach Bandbreite gieren. In den meisten Tests wird das leider aber nicht deutlich. Epycs werden oft genau den ähnlichen Tests unterzogen, wie man sie auch hier findet: allgemein über SPECx, Kompression, Rendering und Videotranscoding und CAD. In SPEC kommen verschiedene kryptografische als auch mathematische Funktionen zum Tragen, auch aus dem wissenschaftlichen Bereich. Wenn es etwas besser wird, kommt noch Compiling als auch die ganzen mathematischen und kryptografischen Tests aus SPEC noch mal über Pyhton, R und Co vor. Und das ist auch das Bild, dass viele hier von den Prozessoren haben und die die meisten für wichtig halten.
Wenn man mal viel Glück hat, kommen nginx, Apache, SQL, PHP mal als Testszenarien vor, oft dann aber eher in der Form, dass man mit sehr einfachen Konstrukten die möglichen Requests ermittelt. Gerade in diesen Bereichen ist es aber schwer wirklich gute Tests zu fahren, weil da vieles auch von der Komplexität der Skripte, Datenbanken und Co ankommt. Da wird dann oft eher mit sehr einfachen Szenarien vorgegaukelt, dass man entsprechende Tests fährt, die am Ende oft aber 0 Aussagekraft haben.
Gerade Datenbanken sind eigentlich die Hölle, da hier viel von der Konfiguration abhängt und eine Einstellung sich auch schnell mal nicht nur um den Faktor 2, sondern auch mal um den Faktor 10 auswirken kann. Die meisten Tester - selbst auf den richtig guten Seiten - fahren aber diese Tests mit den "Standardkonfigurationen" und zeichnen da mal schnell auch vollkommen falsche Bilder von Prozessoren. Oder die Lasten sind falsch gewählt für den Benchmark. Wenn ich sehe, dass manche Hardware-Seiten bei SQL-Benchmarks und Co, mit Tabellen mit ein paar tausend Datensätzen arbeiten, bekomme ich oft ein Lachanfall. Wir reden bei uns von Tabellen, die in der Regel Einträge im mittleren bis hohen 6-stelligen Bereich haben und gewisse Tabellen sind auch im Bereich von 7 - 8 Stellen, da wird es dann erst lustig und ein großer Prozessor kann zeigen, was er kann.
Genauso mit Datenbanken, die speziell auf das Suchen von Inhalten ausgelegt sind (Solr, ElasticSearch (was ja auch solr ist, irgendwie) haben ganz andere Anforderungen, als das, was in den meisten Tests abgebildet wird und auch hier kann sich vieles auswirken.
Klar, es ist verständlich, dass man jedem Prozessor unter den gleichen Bedienungen testen will, aber es gibt Bereiche, in denen das so nicht möglich ist, weil das Bild, dass dann vermittelt wird, vollkommen falsch ist.
mibbio schrieb:
Auch ist bei Servern auch der Takt (oder eine Taktsteigerung) so relevant, wie beim Desktop-/Gaming-PC.
Hast du an der Stelle ein "nicht" vergessen?
C.J. schrieb:
Schon, aber das ändert ja nichts daran, dass der Verbrauch bei gleicher Kernzahl und Takt stagniert bzw. bei gleichem Verbrauch und Kernzahl der Takt nicht hochgeht bzw. man bei gleichem Verbrauch nicht mehr gleichgetaktete Kerne unterbekommt (je nachdem aus welcher Sichtweise man das betrachtet).
Vollkommen irrelevant, ob der Verbrauch bei gleichem Takt stagniert oder der Takt beim gleichen Verbrauch nicht hochgeht. Entscheidend ist, was am Ende durch die ganzen Änderungen herauskommt.
Eine CPU im Server gewinnt oft an ganz anderen Stellen an Leistung, als durch mehr "IPC" oder mehr Takt. Da spielt die Infrastruktur auch gerne mal eine Rolle.
