top of page

Special Terms für ÜbersetzerDDR4 DDR4 Pages ("Rows")

(Special Terms Übersetzer)

Wir bemühen uns in unserem Fach um ständige Weiterbildung und möchten das gerne in Form von d Materialien hier auch anderen zugänglich machen.

Besondere Dokumentenformen fordern den Übersetzer auf besondere Weise heraus. Wofür steht der Begriff "DDR4 Pages" in Verbindung mit "Rows" im Feld Virtueller Speicher und Elektronik. Der Versuch einer Definition über Sprach- und Ländergrenzen hinweg.

WAS GENAU MEINT "PAGES" UND "ROWS"?

Der Begriff "Pages" ist uns im Zusammenhang mit DDR4-Speicherbausteinen begegnet. Wie der Begriff auch schon anklingen lässt, handelt es sich dabei allerdings nicht um ein physisch vorhandenes Teil des Bausteins, sondern einen virtuellen Bestandteil. Folgenden Text dazu stellen wir zunächst in Englisch, dann in der Übersetzung daneben dar. Der Text entstammt der Internetseite https://news.ycombinator.com/item?id=29222098 

WER WIR SIND

Die "medias ohg verlag und produktion" erstellt Übersetzungen aus den Sprachen Norwegisch, Dänisch, Isländisch, Altnordisch, Schwedisch und Englisch in die deutsche Sprache, und bearbeitet Aufträge im Einzelauftrag oder für Übersetzungsagenturen in aller Welt.


Neben der Übersetzungstätigkeit steht die Validierung im Vordergrund unserer Tätigkeit, also die Bewertung von Übersetzungen nach ihrer Verständlichkeit und Praxistauglichkeit im Zertifizierungsprozess.

Aber auch besondere Bereiche, die Erstellung von Untertiteln für Videos und Filme, Synchronsprechen und das sogenannte Voice-Over (unterlegter Kommentar) werden von uns ausgeführt. Besonders hier kommt uns unsere schauspielerische Tätigkeit zu Gute.​

DDR4 pages ("rows") are 8kiB, with reads/writes being 64B bursts into the "row"buffer.

 

 

 

(For a full DIMM; the following goes a bit more into detail and doesn't strictly assume full 64 data bit (+ optional ECC) wide channels.)

Each bank has a single "row" buffer into which a page has to be loaded ("activate" command) before reading/writing into that page, and it has to be written back ("precharged") before a new page can be loaded or an internal bank refresh can be triggered.

 

"row" buffer locality is relatively important for energy efficiency, and can account for about a 2x factor in the DRAM's power consumption. Each rank has 4 bank groups of 4 banks each, with the frequency of "activate" commands to banks in the same group being restricted more severely than to separate bank groups. A rank is just a set of chips who's command/address lines are in parallel, and who's data lines are combined to get up to the typical 64/72 bits of a channel. A single chip is just 4, 8, or 16bit wide. A channel can have typically between IIRC 1 and 12 ranks, which are selected with separate chip select lines the controller uses to select which rank the contents of the command/address bus are meant for.

Also, "activate" and "precharge" take about as long (most JEDEC standard timings have literally the same number is cycles for these 3 timings (also known as the "primary" timings)) as the delay between selecting the "column" in a "row" buffer, and the corresponding data bits flowing over the data bus (for reads and writes there may iirc be a one-cycle difference due to sequencing and data buffers between the DDR data bus and the serdes that adapts the nominal 8-long bursts at DDR speeds to parallel accesses to the "row" buffer).

With JEDEC timings for e.g. DDR4-3200AA being 22-22-22 CL-tRCD-tRP ("column" address-to-data delay; "row"-to-"column" address delay; "precharge"-to-"activate" delay), and the burst length being 4 DDR cycles, this is far from random access.

In fact, within a bank, and even neglecting limits on activate frequency (as I'm too lazy to figure out if you can hit them when using just a single bank), with assumed-infinite many "rows" and thus zero "row" locality for random accesses, as well as perfect pipelining and ignoring the relatively rare "precharge"/"activate" pairs at the end of a 1024-columns-wide "row":

Streaming accesses would take 4 cycles per read/write of a 64B cacheline (assuming a 64bit (72 with normal SECDED ECC) DIMM; is less bits, the cacheline would be narrower), archiving 3200 Mbit/s per data pin. Random accesses would take 22+22+22=66 cycles per read/write, archiving 193 ³¹/₃₃ Mbit/s per data pin.

So random accesses are just 6 ²/₃₃ % efficient in the worst case and assuming simplified pathological conditions. In practice, you have 16 banks to schedule your request queue over, and often have multiple ranks (AFAIK typically one rank per 4/8/16GiB on client (max 4 per channel on client, 2 optimal, with 1 having not enough banks and 3-4 limiting clock speeds due to limited transmitter power) and low-capacity servers; one rank per 16-32GiB on high-capacity servers).

There is a slight delay penalty for switching between ranks, iirc most notable when reading from multiple ones directly in sequence or possibly when reading from one and subsequently writing to another (both are pretty bad, but I don't recall which one typically has more stall cycles between transmissions; iirc it's like around 3 cycles (=6 bits due to DDR; close to one wasted burst)).


 

yxhuvud on Nov 15, 2021 [–]


> DDR4 pages ("rows") are 8kiB

Wait, are the underlying hardware access size for memory bigger than the default Linux page size (4kb)? Wouldn't that introduce needless inefficiencies?

Can false sharing happen between different pages if they happen to be in the same row?

 

rasz on Nov 15, 2021 | parent | next [–]


Its internal implementation detail, invisible to the CPU.

https://faculty-web.msoe.edu/johnsontimoj/EE4980/files4980/m...

diagrams on pages 4-7.

 

dragontamer on Nov 15, 2021 | parent | prev | next [–]


Not really. Pages are about virtual memory and not about physical memory.

In practice, the only thing DDR4 banks do is make prefetching an important strategy, thus making sequential performance for DDR4 incredible.

A fact already known to high performance programmers. Accessing byte 65 after byte 64 is much more efficient than accessing byte 9001.

 

namibj on Nov 17, 2021 | parent | prev [–]


What you don't want is things accessed together residing in different rows of the same bank. Things being on the same row is a good thing.

 

yxhuvud on Nov 20, 2021 | root | parent [–]

 

Even for false sharing? That is, the problem when two unrelated atomics are allocated in the same page but accessed frequently from different threads, causing the memory to be thrashing between two different L1 cache lines.

earbeiten.

DDR4-Seiten ("rows") sind 8kiB groß, wobei die einzelnen Lese-/Schreibvorgänge jeweils 64B groß sind, und als Bursts in den "row"-Puffer geschrieben bzw. aus ihm gelesen werden).

(Obenstehendes gilt aber nur für ein komplettes DIMM; die folgenden Ausführungen gehen etwas mehr ins Detail und gehen nicht unbedingt von einem vollen 64 Datenbit (+ optionalem ECC- Breitbandkanälen) aus.

 

Jede Bank hat einen einzelnen "Row"-Puffer, in den eine Page (Seite) geladen werden muss (was durch den "activate"-Befehl geschieht), bevor in diese Seite Lese-/Schreibvorgänge erfolgen können.  Und dieser "Row"-Puffer muss dann auch erst wieder zurückgeschrieben werden ("precharged"), bevor eine neue Seite geladen werden kann, oder bevor eine interne Bank-Aktualisierung ausgelöst werden kann.


Die "Zeilen"-Pufferlokalität ist für die Energieeffizienz relativ wichtig und kann etwa einen Faktor von 2 für den Stromverbrauch des DRAM ausmachen. Jeder Rang hat 4 Bankgruppen mit je 4 Bänken, wobei die Häufigkeit von "Aktivierungs"-Befehlen für Bänke in derselben Gruppe stärker eingeschränkt ist als für separate Bankgruppen. Ein Rang ist lediglich eine Gruppe von Chips, deren Befehls-/Adressleitungen parallel geschaltet sind und deren Datenleitungen kombiniert sind, um die typischen 64/72 Bits eines Kanals zu erreichen. Ein einzelner Chip ist nur 4, 8 oder 16 Bit breit. Ein Kanal kann typischerweise zwischen 1 und 12 Ranks haben, die mit separaten Chip-Select-Leitungen ausgewählt werden, mit denen der Controller auswählt, für welchen Rank der Inhalt des Befehls-/Adressbusses bestimmt ist.

Außerdem dauern "Aktivieren" und "Vorladen" ungefähr so lange (die meisten JEDEC-Standard-Timings haben buchstäblich die gleiche Anzahl von Zyklen für diese drei Timings (auch bekannt als die "primären" Timings)) wie die Verzögerung zwischen der Auswahl der "Spalte" in einem "Zeilen"-Puffer, und den entsprechenden Datenbits, die über den Datenbus fließen (für Lese- und Schreibvorgänge kann es iirc einen Unterschied von einem Zyklus geben, der auf die Sequenzierung und die Datenpuffer zwischen dem DDR-Datenbus und den Serden zurückzuführen ist, die die nominalen 8-langen Bursts bei DDR-Geschwindigkeiten an parallele Zugriffe auf den "Zeilen"-Puffer anpassen).

Da die JEDEC-Timings für z. B. DDR4-3200AA 22-22-22 CL-tRCD-tRP (Verzögerung von der "Spalte" bis zu den Daten; Verzögerung von der "Zeile" bis zur "Spalte"; Verzögerung von der "Vorladung" bis zur "Aktivierung") betragen und die Burst-Länge 4 DDR-Zyklen beträgt, ist dies alles andere als ein zufälliger Zugriff.

Innerhalb einer Bank und sogar unter Vernachlässigung der Grenzen für die Aktivierungshäufigkeit (ich bin zu faul, um herauszufinden, ob man sie bei der Verwendung einer einzigen Bank erreichen kann), bei angenommenen unendlich vielen "Reihen" und somit null "Reihen"-Lokalität für zufällige Zugriffe sowie bei perfektem Pipelining und unter Vernachlässigung der relativ seltenen "precharge"/"activate"-Paare am Ende einer 1024 Spalten breiten "Reihe":

Streaming-Zugriffe würden 4 Zyklen pro Lese-/Schreibvorgang einer 64B-Cacheline benötigen (unter der Annahme eines 64bit (72 mit normalem SECDED ECC) DIMM; bei weniger Bits wäre die Cacheline schmaler), wobei 3200 Mbit/s pro Datenpin archiviert würden. Zufällige Zugriffe würden 22+22+22=66 Zyklen pro Lese-/Schreibvorgang dauern, wobei 193 ³¹/₃₃ Mbit/s pro Datenpin archiviert würden.

Zufallszugriffe sind also im ungünstigsten Fall und unter vereinfachten pathologischen Bedingungen nur 6 ²/₃₃ % effizient. In der Praxis hat man 16 Bänke, auf die man seine Anfragewarteschlange verteilen kann, und oft mehrere Ranks (AFAIK typischerweise ein Rank pro 4/8/16GiB auf dem Client (max. 4 pro Kanal auf dem Client, 2 optimal, wobei 1 nicht genügend Bänke hat und 3-4 die Taktgeschwindigkeit aufgrund der begrenzten Sendeleistung einschränken) und Servern mit geringer Kapazität; ein Rank pro 16-32GiB auf Servern mit hoher Kapazität).

Es gibt eine leichte Verzögerung beim Umschalten zwischen den Ranks, iirc am bemerkenswertesten beim Lesen von mehreren Ranks direkt hintereinander oder möglicherweise beim Lesen von einem und anschließendem Schreiben auf einen anderen (beides ist ziemlich schlecht, aber ich erinnere mich nicht daran, welches typischerweise mehr Blockierzyklen zwischen den Übertragungen hat; iirc sind es etwa 3 Zyklen (=6 Bits aufgrund von DDR; fast ein verschwendeter Burst)). 

bottom of page