mikrocontroller.net

Forum: PC Hard- und Software Double channel RAM speed


Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin werte Anwesenden,

ich habe mir die Zeit ein wenig mit einem RAM Geschwindigkeitstest 
vertrieben und etwas Ungewöhnliches festgestellt.
Verbaut in einem core i5 System sind zwei 4GB Speicher DDR3-1333.
Die Bänke sind korrekt belegt!
Die Erwartungshaltung war das sich in etwa die avisierte 'Dual Rate' 
Geschwindigkeit einstellt.

Das Testprogramm nutzt C für Berechnungen und Darstellung, die 
Zeitmessung wird mittels mundgeblasener Assemblerfunktionen 
durchgeführt.

Beim linearen Lesen eines korrekt ausgerichteten 1GiB Speicherbereiches 
stellen sich erwartungsgemäß die ca. 21.2 GB/s ein. Der 'Dual Channel' 
Mode scheint also zu greifen.

Beim linearen Schreiben dieses Speicherbereiches mit einer nahezu 
identischen Assemblerfunktion bei der nur movq (pRam), %r9 gegen movq 
%r9, (pRam) getauscht wurde, stellt sich jedoch nur die halbe 
Geschwindigkeit (10.6 GB/s) ein.


FRAGE: Ist der 'Dual Channel' Mode nur bei Lesevorgängen aktiv?
Hat jemand eine Erklärung?

Ach ja, 64bit Debian GNU/Linux System

#   Chip        Modul       Mem    I/O     Eff     Rate   Rate
#                           clk    clk     clk   Single   Dual
#                           MHz    MHz     MHz     GB/s   GB/s
#   DDR3-1333   PC3-10600   166    666    1333     10,6   21,2
#   DDR3-1600   PC3-12800   200    800    1600     12,8   25,6
#
#   Source: https://de.wikipedia.org/wiki/DDR-SDRAM#DDR3-SDRAM

norbert@Entwicklung:~/source/testarea$ make Memspeed && ./Memspeed 
gcc -c -Wall -Wextra -pedantic -std=c11 -Os -o Memspeed.o Memspeed.c
gcc -c -Wall -Wextra -pedantic -std=c11 -O0 -fverbose-asm -o assemblerfunctions.o assemblerfunctions.S
gcc -Wl,--gc-sections -o Memspeed Memspeed.o assemblerfunctions.o
objdump -d -M motorola -S assemblerfunctions.o > assemblerfunctions.lst
strip Memspeed
ls -l Memspeed
-rwxr-x--- 1 norbert norbert 17360 Aug  9 14:02 Memspeed

Readspeed:
[   161590580]    21.26 GB/s (tsc based)
[   160432252]    21.42 GB/s (tsc based)
[   161857096]    21.23 GB/s (tsc based)
[   161606158]    21.26 GB/s (tsc based)
[   161181721]    21.32 GB/s (tsc based)
[   161021076]    21.34 GB/s (tsc based)
[   161154556]    21.32 GB/s (tsc based)
[   160926652]    21.35 GB/s (tsc based)
[   160661614]    21.39 GB/s (tsc based)
[   160569907]    21.40 GB/s (tsc based)
Usedtime:      0.504592 s (per iteration)
Bytes written: 10737418240  (10 GiB)
Speed:         21.28 GB/s   (19.82 GiB/s)

Writespeed:
[   322020040]    10.67 GB/s (tsc based)
[   322910643]    10.64 GB/s (tsc based)
[   321653569]    10.68 GB/s (tsc based)
[   322736627]    10.65 GB/s (tsc based)
[   321136953]    10.70 GB/s (tsc based)
[   321401221]    10.69 GB/s (tsc based)
[   321466218]    10.69 GB/s (tsc based)
[   322827836]    10.64 GB/s (tsc based)
[   323528069]    10.62 GB/s (tsc based)
[   322243548]    10.66 GB/s (tsc based)
Usedtime:      1.009161 s (per iteration)
Bytes written: 10737418240  (10 GiB)
Speed:         10.64 GB/s   (9.91 GiB/s)
norbert@Entwicklung:~/source/testarea$ 

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verwendet Linux beim Speicher nicht eine Copy-On-Write Strategie?

Time mal einen 2. Schreibversuch im selben Progrtamm auf denselben 
Speicherbereich. Es kann sein dass der erst während des Schreibvorgangs 
allokiert wird, was das Timing dann versaut.

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Verwendet Linux beim Speicher nicht eine Copy-On-Write Strategie?
>
> Time mal einen 2. Schreibversuch im selben Progrtamm auf denselben
> Speicherbereich. Es kann sein dass der erst während des Schreibvorgangs
> allokiert wird, was das Timing dann versaut.

Ja, das macht Linux so.
Darum allokiere ich den Speicher (1 GiB) und beschreibe ihn zuerst mit 
memset() komplett.
uint64_t * prepare(void) {
    uint64_t *p;
    cpu_set_t mask;

    CPU_ZERO(&mask);
    CPU_SET(0,&mask);
    sched_setaffinity(0, sizeof(cpu_set_t), &mask);
    nice(-10);
    p = aligned_alloc(64*KIB, GIB);
    assert(p);
    memset(p, 0, GIB);
    return p;
}
Dann erst finden die Tests statt.
Es werden dann zehn mal hintereinander jeweils ein GiB in diesen 
Speicherbereich geschrieben bzw. aus dem Bereich gelesen.

Autor: Norbert (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Heiner schrieb im Beitrag #4679636:
> Norbert schrieb:
>> Darum allokiere ich den Speicher (1 GiB) und beschreibe ihn zuerst mit
>> memset() komplett.
>
> dann ist doch alles korrekt!
>
> lg Heiner

Erklär bitte mal was du damit meinst.

Und vor allem was es mit single vs. double channel mode zu tun hat.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert schrieb:
> Erklär bitte mal was du damit meinst.

Ignorieren. Das ist ein Troll.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.