Drewkev schrieb:
Du hast zwar alle vier Änderungen zitiert, aber ok.
Weil das (fast) alles in die gleiche Sparte reinspielt:
Also schön aufgedröselt:
Formeln:
Code:
effektiveFrequenz = PrefetchingFaktor x interne Taktfrequenz Formel A
Speichertransferrate = effektiveFrequenz x Busbreite (in Byte!) Formel B
Latenz (in ns) = 2 x Latenzzahl / effektiveFrequenz Formel C
1.
32-bit Sub-Channels, doppelte Burst Länge, 2 statt 4 Banks pro Bank Group
Die größe des Channels war bei DDR4 64bit. Jetzt (bei DDR5) gibt es aber zum einen eine Aufteilung in 2 Subchannels und zum anderen eine 'Halbierung' der Breite vgl. zum einen großen Channel vorher. Da wir aber jetzt 2 Subchannels haben, bleibt die Breite pro Modul gleich. Bis hierhin wäre der Prefetching Faktor immer noch der gleiche.
Da ist dann aber das Problem:
x86 CPUs erwarten eine minimale Zugriffsgröße von 64byte.
(die Zugriffsgröße ergib sich aus BurstLänge x BusBreite. Die Burstlänge bei DDR4 war 8, bei DDR5 dann 16 s. ff.)
Durch die Halbierung der Breite beider Channels (die am Ende auch einzeln angesteuert werden sollen - sonst verdoppelt sich unsere effektive Frequenz nämlich nicht), ist das (die 64 byte minimale Zugriffsgröße) aber nicht mehr gegeben. Daher wird die Burst-Length/BurstLänge verdoppelt.
(Daten werden in 'bursts' aka 'Schüben' geliefert).
Der Prozessor ist 'zufrieden', da er wieder 64 byte minimale Zugriffslänge hat, und wir müssen nix weiter an der Busbreite ändern.
Unser 32 bit breiter Bus kann also jetzt pro Burst die gleiche Menge an Daten hindurchliefern, wie ein 64 bit Bus.
Das alles bringt aber noch nichts wirklich, wenn man immer noch die gleiche Anzahl an Bank Groups dahinter (hinter dem Interface) stehen hat (Der Prozessor adressiert immer eine bzw. mehrere Bank Groups parallel, wenn er einen Speicherzugriff durchführt und lässt sich dann deren Inhalt (der enthaltenen RAM-Banks) geben. Bleibt die Anzahl der Bank Groups gleich, kann er auch nur diese Anzahl ansprechen. Da nützt uns unser schön aufgebohrtes Interface aber dann nix.) Daher muss&wird logischerweise die Anzahl der Bank Groups verdoppelt (Anmerkung: Anzahl der Banks pro Group bleibt gleich (4), nur die Anzahl der Bank Groups verdoppelt sich bei DDR5 von 4 auf 8, bzw. ja, es gab bei DDR4 anfangs noch die Option für 2 Banks pro BG, aber typisch waren letzthin 4 Banks pro BG).
Am Ende erhalten wir also (bezogen auf den Durchsatz) 2 volle Channels, wo vorher nur einer war.
Und das wird in der Berechnung der Latenz bzw. der effektiven Taktrate durch den verdoppelten Prefetching-Faktor abgedeckt.
2.
In gewisser Weise ist das ein Punkt, allerdings mit einen großem Aber. Denn:
Ja, innerhalb von DDR5 (also vgl. Refresh Same-Bank vs Refresh All-Bank) ergeben sich Performance-Vorteile von irgendwas zwischen 6-9% sowie eine Halbierung des Beitrags der durch den Refresh hinzukommenden(!) Latenz (Es handelt sich bei beiden Messdaten um kein Spiel/reale Anwendung oder so, sondern Herstellerinterne Benchmarks, die reine Geschwindigkeitsunterschiede feststellen!). Aber!: Diese Funktion wurde überhaupt erst notwendig, durch die Verdopplung der Bank Groups (mehr Bank Groups pro Refresh -> längere Refresh-Zeit). Im Vergleich zu DDR4 (mit der halben Anzahl an Bank Groups) dürfte sich das Ausnivellieren. Unterschiede (falls überhaupt vorhanden) bei realen Anwendungen&Spielen dürften so oder so im Bereich der Messungenauigkeit verschwinden.
Ich denke schlussendlich, dass man sehr wohl die ganz gewöhnliche Fromel (C) verwenden kann, um Latenzen/Latenzunterschiede auch (bis dato) über verschiedene Generationen von DDR Ram hinweg zu bestimmen.
Ich verstehe aber vielleicht woher das Denken kommt, dass DDR5 mehr Sachen anders macht, als es letzlich der Fall ist. Viele Techseiten nehmen halt das Pressematerial (aka Marketingmaterial), hinterfragen es kaum und posten das dann, ohne sich was bei zu denken.
Der Hersteller versucht natürlich alles als einzelne Merkmale hinzustellen, um eine möglichst lange Liste an Verbesserungen da stehen zu haben
Selbst hardwaretimes, die oftmals mehr als die gewöhnlichen Infos bieten, haben in ihren Artikeln zu DDR5 (jedenfalls die, in die ich jetzt mal kurz reingeschaut habe) viel von diesen Doppelnennungen & sogar faktisch falsche Informationen drin, die aus dem zusammenwerfen des Pressematerials von Ram-Herstellern zustande kommen.
(Dafür hatten sie (Hardwaretimes) mal echt gute Deep dives für GPU-Architekturen. Wo viele Seiten steif und fest behaupteten, dass RDNA2 ausschließlich Vektoreinheiten besitzt->onlyVectorBasedALUs, was so aber falsch ist - es gibt tatsächlich 2 skalare Einheiten pro ComputeUnit; Ist zwar deutlich weniger, als bei Nvidia, aber ist in jedem Falle vorhanden -, hatte Hardwaretimes das mal korrekt dargestellt (ich meine jedenfalls, dass die das gewesen wären))
Drewkev schrieb:
Die CAS Latenz ist zwar bei letzterem höher, aber in Benchmarks gleichauf mit 3600 CL16 bei bis zu doppeltem Datendurchsatz. Darauf habe ich mit meiner Aussage abgezielt.
Was dann halt schlussendlich Spiele, Anwendungen & Benchmarks bevorzugen (doppelte Speicherbandbreite (DDR5)/leicht niedrigere Latenz (DDR4)), ist vom Programm abhängig und teils sehr unterschiedlich.
Selbst bei Spielen, wo das zwar i.A. die Latenz ist, kommt es aber dennoch drauf an.
Auch im Gaming Test zu Alderlake hier auf CB bevorzugt ~1/3-1/2 der Spiele den DDR4 (hängen also noch stärker an der Latenz). Der andere Teil zieht auch einen Nutzen aus dem Plus an Speicherbandbreite und präferiert daher DDR5 oder hat gar keine Präferenz.
Das ist ja das schöne: Je nachdem, was man braucht, kann man aktuell entweder das eine, oder das andere wählen. Und in ein paar Quartalen bis Jahren wird DDR5 auch bei der Latenz komplett überholen.
