Warum wird in den Speicher geschrieben wird viel langsamer voran, als es zu Lesen?

Hier ist eine einfache memset Bandbreite benchmark:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

int main()
{
    unsigned long n, r, i;
    unsigned char *p;
    clock_t c0, c1;
    double elapsed;

    n = 1000 * 1000 * 1000; /* GB */
    r = 100; /* repeat */

    p = calloc(n, 1);

    c0 = clock();

    for(i = 0; i < r; ++i) {
        memset(p, (int)i, n);
        printf("%4d/%4ld\r", p[0], r); /* "use" the result */
        fflush(stdout);
    }

    c1 = clock();

    elapsed = (c1 - c0) / (double)CLOCKS_PER_SEC;

    printf("Bandwidth = %6.3f GB/s (Giga = 10^9)\n", (double)n * r / elapsed / 1e9);

    free(p);
}

Auf meinem system (details siehe unten) mit einem DDR3-1600-Speicher-Modul Ausgänge:

Bandbreite = 4.751 GB/s (Giga = 10^9)

Ist dies 37% der theoretischen RAM-Geschwindigkeit: 1.6 GHz * 8 bytes = 12.8 GB/s

Auf der anderen Seite, hier ist ein ähnliches "Lesen" test:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

unsigned long do_xor(const unsigned long* p, unsigned long n)
{
    unsigned long i, x = 0;

    for(i = 0; i < n; ++i)
        x ^= p[i];
    return x;
}

int main()
{
    unsigned long n, r, i;
    unsigned long *p;
    clock_t c0, c1;
    double elapsed;

    n = 1000 * 1000 * 1000; /* GB */
    r = 100; /* repeat */

    p = calloc(n/sizeof(unsigned long), sizeof(unsigned long));

    c0 = clock();

    for(i = 0; i < r; ++i) {
        p[0] = do_xor(p, n / sizeof(unsigned long)); /* "use" the result */
        printf("%4ld/%4ld\r", i, r);
        fflush(stdout);
    }

    c1 = clock();

    elapsed = (c1 - c0) / (double)CLOCKS_PER_SEC;

    printf("Bandwidth = %6.3f GB/s (Giga = 10^9)\n", (double)n * r / elapsed / 1e9);

    free(p);
}

It-Ausgänge:

Bandbreite = 11.516 GB/s (Giga = 10^9)

Kann ich nah an die theoretische Grenze für die lese-performance, wie XORing eine große Auswahl, aber das schreiben scheint viel langsamer. Warum?

OS Ubuntu 14.04 AMD64 (ich kompiliere mit gcc -O3. Mit -O3 -march=native macht die lese-performance etwas schlechter, aber keinen Einfluss auf memset)

CPU Xeon E5-2630 v2

RAM Einem einzigen "16GB PC3-12800-Parity REG CL11 240-Pin DIMM" (das, Was es sagt, auf der box) ich denke, dass ein einzelnes DIMM-Modul macht die Leistung besser vorhersagbar. Ich gehe davon aus, dass mit 4 DIMMs, memset werden bis zu 4 mal schneller.

Motherboard Supermicro X9DRG-QF (Unterstützt 4-Kanal-Speicher)

Zusätzliche system: Ein laptop mit 2x 4GB DDR3-1067 RAM: Lesen und schreiben sind beide etwa 5,5 GB/s, aber beachten Sie, dass es verwendet 2 DIMMs.

P. S. ersetzen memset mit dieser version werden die Ergebnisse in genau der gleichen Leistung

void *my_memset(void *s, int c, size_t n)
{
    unsigned long i = 0;
    for(i = 0; i < n; ++i)
        ((char*)s)[i] = (char)c;
    return s;
}

printf("%4d/%4ld\r", p[0], r); in deinem Maßstab bedeutet, dass Sie wahrscheinlich Zeit, eher als alles andere. I/O ist langsam.
Nein! printf genannt wird 101 mal in ein Programm, das läuft für 20 Sekunden
Gibt es eine paging-Auftritt?
In dem code, den Sie geschrieben es sollte als das 100-fache. Es gibt keinen Grund für es zu sein in dem Teil des Codes, den Sie sind benchmarking.
Es ist gute Praxis, um die "Verwendung" der Ergebnisse Ihrer benchmark-Berechnungen, da sonst der compiler kann zu umgehen, aber die ganze Berechnung (in vielen Fällen, je nach den Besonderheiten). Außerdem bietet es "Fortschritte", so dass Sie wissen, wie lange zu warten.
Ich versuchte es auf meinem system mit und ohne printf in der Schleife. Der Unterschied war kleiner als ich erwartet hatte (3 mal). Mit, ich habe 9.644, 9.667 und 9.629, ohne bekam ich 9.740, 9.614 und 9.653
Wahrscheinlich eine Frage der cache-policy (das Prozessor-spezifisch).
Mein 2010 alte MacBook Berichte 1.937 GB/s ohne Optimierung, und 173010.381 GB/s mit Optimierung mit der gepostet code, unverändert 🙂 wahrscheinlich das memset schreibt, um eine cache-Zeile, die Sie zuerst Lesen aus dem RAM-cache, um verändert zu werden, und dann gespült, so dass jeder cache-Zeile gelesen + geschrieben und nicht nur Lesen. Die Verbleibende Differenz wird wahrscheinlich durch das Lesen von/schreiben auf nicht zusammenhängenden Orten. PowerPC hatte die Anweisungen zum löschen von cache-Zeilen, die geholfen hätten.
11.5 GB/s für XORing. Im ernst, printf ist hier vernachlässigbar. Daran habe ich nie gedacht. Ich bin überrascht, die Leute sind besessen mit es hier.
In jedem Multiprozessor-Umgebung die Aufrechterhaltung der cache-Kohärenz verursacht, schreibt langsamer als liest, insgesamt.
was ist dein compiler? Unterbindung der Optimierungen in einer trivialen benchmark ist ein interaktiver Prozess. Sie wahrscheinlich benötigen, um die "Verwendung" der Ergebnisse mehr irgendwie.
Dies ist single-threaded. Wenn Sie denken, dass Ihr Kommentar noch gilt, vielleicht poste es als Antwort?
Ich fügte hinzu, ein "Lesen" - benchmark auf die Frage.
es gibt kein swapping (verifiziert mit free-m). Das Programm ordnet 1GB auf einem system mit 16GB RAM
Ich kann nicht reproduzieren Sie Ihre timing-Unterschied auf meinem Rechner. Im Gegenteil, Ihre xor-Bank ist sogar noch ein bisschen langsamer. Hast du kompilieren mit -O3 -march=native? Auch, für die gleiche Optimierung, die klappern in der Lage ist, zur Optimierung der loop völlig aus für die memset benchmark.
Mit -O3 -march=native macht die lese-performance etwas schlechter, aber keinen Einfluss auf memset für mich (bearbeitet die Frage)
BTW, Sie sind nicht mess-schreib-performance, aber die performance Ihres memset in der C-Bibliothek (vermutlich glibc) auf Ihre Architektur.
Ich wäre daran interessiert, dass dieser benchmark beim kompilieren und ausführen auf einem PC mit FreeDOS-32 als OS. So, der overhead von der virtuellen Speicherverwaltung und paging können dadurch weitgehend vermieden werden.
CLOCKS_PER_SEC wird ganz gewiss haben Sie den falschen Wert. Moderne Prozessoren bekommen eine mehr oder weniger dynamische Uhr, es kann sehr stark variieren. Man wird Lesen müssen, um den aktuellen (!) Uhr-Wert, der unmittelbar, bevor Sie es verwenden - aber das funktioniert nur, wenn Ihr Programm ist SEHR schnell .. in der Tat, man müsste Lesen Sie den Wert nach JEDEM PROZESSOR-SCHRITT, aber das ist sehr schwer umzusetzen und würde die Ausbeute nur geringe Genauigkeit-Verbesserungen
CLOCKS_PER_SEC hat einen irreführenden Namen, aber seine (Konstanten) Wert ist definiert der C-standard. Ich bezweifle ernsthaft, dass es "falsch"ist.
Das ist ein benchmark Vergleich zwischen einem standard-library-Funktion (memset) und Ihre eigenen Funktion (do_xor), nicht zwischen Leseoperation und Schreiboperation.
Ich habe eine version mit meiner eigenen Implementierung memset
Wenn der C-library-version von memset ist wirklich gleich um die, die Sie geben, ist Ihre installation nicht bekommen, es richtig zu machen. Auf modernen Architekturen, sollte dies anspruchsvoller als die und zu kombinieren, schreibt die nachfolgenden Speicher und Dinge wie, dass. Also das kocht mehr und mehr nach unten, um ein problem mit der Konfiguration dann alles andere. Jede "Antwort" auf deine Frage wäre rein spekulativ. Vielleicht sollten Sie es schließen.
warum ist ein Buch zu schreiben, viel langsamer als das Lesen ein? har... das schreiben ist zu finden zugewiesenen Raum und notieren Sie, wo dieser Raum ist für beim Lesen. Lesen genau anschaut, dass die Platte wie ein Inhaltsverzeichnis und die Erträge auf diesen Standorten, die, wie Sie wissen, können Sie nicht zusammen in einem Stück.
Für raw-Speicher Lesegeschwindigkeit fand ich es viel genauer zu Lesen, immer 8 bytes in Schritten von 64 bytes (oder wahtever Ihre CPUS cacheline ist). Dies bewirkt, dass alle Speicher übertragen L2, mit minimaler CPU-Auslastung. Ich weiß nicht viel darüber, wie das schreiben funktioniert im detail, aber vielleicht ein ähnlicher Mechanismus kann verwendet werden, um reduzieren alle overhead.
Diese Frage scheint off-topic, denn es macht schon eine falsche Behauptung in der Frage-Titel. Es ist viel Architektur abhängig und es kann nicht immer eine eindeutige Antwort.
Es kann sicherlich sein, eine klare Antwort: nämlich, "Ihre Annahme ist falsch, es ist Architektur abhängig und hier sind einige der Faktoren, mit Nachweis". Es ist eine sinnvolle Frage, da dieser Fehleinschätzung kommen immer wieder.

InformationsquelleAutor MaxB | 2014-09-13

c hardware memory performance

Mit Ihren Programmen, die ich bekommen

(write) Bandwidth =  6.076 GB/s
(read)  Bandwidth = 10.916 GB/s

auf einen desktop (Core-i7, x86-64, GCC 4.9, GNU libc-2.19) - Maschine mit sechs 2-GB-DIMMs. (Ich habe nicht mehr Details, als dass zu hand, sorry.)

Jedoch diese Programm Berichte schreiben, die die Bandbreite der 12.209 GB/s:

#include <assert.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <emmintrin.h>

static void
nt_memset(char *buf, unsigned char val, size_t n)
{
    /* this will only work with aligned address and size */
    assert((uintptr_t)buf % sizeof(__m128i) == 0);
    assert(n % sizeof(__m128i) == 0);

    __m128i xval = _mm_set_epi8(val, val, val, val,
                                val, val, val, val,
                                val, val, val, val,
                                val, val, val, val);

    for (__m128i *p = (__m128i*)buf; p < (__m128i*)(buf + n); p++)
        _mm_stream_si128(p, xval);
    _mm_sfence();
}

/* same main() as your write test, except calling nt_memset instead of memset */

Die Magie ist alles in _mm_stream_si128 aka the machine instruction movntdq, schreibt eine 16-byte-Menge an system-RAM, unter Umgehung des cache (der offizielle jargon für diese ist "non-temporal store"). Ich denke, dass dies ziemlich schlüssig zeigt, dass der performance-Unterschied ist alles über das cache-Verhalten.

N. B. glibc 2.19 hat haben ein aufwendig von hand optimiert memset macht die Verwendung von Vektor-Anweisungen. Es wird jedoch nicht Verwendung non-temporal stores. Das ist wohl das Richtige für memset; im Allgemeinen, Sie Speicher löschen, kurz bevor Sie es verwenden, so dass Sie wollen es zu heiß in den cache. (Ich nehme an, ein noch klüger memset umsteigen zu non-temporal stores für wirklich riesig block klar, auf der Theorie, dass Sie könnte nicht wollen, dass alle, die in den cache, denn der cache ist einfach nicht so groß.)

Dump of assembler code for function memset:
=> 0x00007ffff7ab9420 <+0>:     movd   %esi,%xmm8
   0x00007ffff7ab9425 <+5>:     mov    %rdi,%rax
   0x00007ffff7ab9428 <+8>:     punpcklbw %xmm8,%xmm8
   0x00007ffff7ab942d <+13>:    punpcklwd %xmm8,%xmm8
   0x00007ffff7ab9432 <+18>:    pshufd $0x0,%xmm8,%xmm8
   0x00007ffff7ab9438 <+24>:    cmp    $0x40,%rdx
   0x00007ffff7ab943c <+28>:    ja     0x7ffff7ab9470 <memset+80>
   0x00007ffff7ab943e <+30>:    cmp    $0x10,%rdx
   0x00007ffff7ab9442 <+34>:    jbe    0x7ffff7ab94e2 <memset+194>
   0x00007ffff7ab9448 <+40>:    cmp    $0x20,%rdx
   0x00007ffff7ab944c <+44>:    movdqu %xmm8,(%rdi)
   0x00007ffff7ab9451 <+49>:    movdqu %xmm8,-0x10(%rdi,%rdx,1)
   0x00007ffff7ab9458 <+56>:    ja     0x7ffff7ab9460 <memset+64>
   0x00007ffff7ab945a <+58>:    repz retq 
   0x00007ffff7ab945c <+60>:    nopl   0x0(%rax)
   0x00007ffff7ab9460 <+64>:    movdqu %xmm8,0x10(%rdi)
   0x00007ffff7ab9466 <+70>:    movdqu %xmm8,-0x20(%rdi,%rdx,1)
   0x00007ffff7ab946d <+77>:    retq   
   0x00007ffff7ab946e <+78>:    xchg   %ax,%ax
   0x00007ffff7ab9470 <+80>:    lea    0x40(%rdi),%rcx
   0x00007ffff7ab9474 <+84>:    movdqu %xmm8,(%rdi)
   0x00007ffff7ab9479 <+89>:    and    $0xffffffffffffffc0,%rcx
   0x00007ffff7ab947d <+93>:    movdqu %xmm8,-0x10(%rdi,%rdx,1)
   0x00007ffff7ab9484 <+100>:   movdqu %xmm8,0x10(%rdi)
   0x00007ffff7ab948a <+106>:   movdqu %xmm8,-0x20(%rdi,%rdx,1)
   0x00007ffff7ab9491 <+113>:   movdqu %xmm8,0x20(%rdi)
   0x00007ffff7ab9497 <+119>:   movdqu %xmm8,-0x30(%rdi,%rdx,1)
   0x00007ffff7ab949e <+126>:   movdqu %xmm8,0x30(%rdi)
   0x00007ffff7ab94a4 <+132>:   movdqu %xmm8,-0x40(%rdi,%rdx,1)
   0x00007ffff7ab94ab <+139>:   add    %rdi,%rdx
   0x00007ffff7ab94ae <+142>:   and    $0xffffffffffffffc0,%rdx
   0x00007ffff7ab94b2 <+146>:   cmp    %rdx,%rcx
   0x00007ffff7ab94b5 <+149>:   je     0x7ffff7ab945a <memset+58>
   0x00007ffff7ab94b7 <+151>:   nopw   0x0(%rax,%rax,1)
   0x00007ffff7ab94c0 <+160>:   movdqa %xmm8,(%rcx)
   0x00007ffff7ab94c5 <+165>:   movdqa %xmm8,0x10(%rcx)
   0x00007ffff7ab94cb <+171>:   movdqa %xmm8,0x20(%rcx)
   0x00007ffff7ab94d1 <+177>:   movdqa %xmm8,0x30(%rcx)
   0x00007ffff7ab94d7 <+183>:   add    $0x40,%rcx
   0x00007ffff7ab94db <+187>:   cmp    %rcx,%rdx
   0x00007ffff7ab94de <+190>:   jne    0x7ffff7ab94c0 <memset+160>
   0x00007ffff7ab94e0 <+192>:   repz retq 
   0x00007ffff7ab94e2 <+194>:   movq   %xmm8,%rcx
   0x00007ffff7ab94e7 <+199>:   test   $0x18,%dl
   0x00007ffff7ab94ea <+202>:   jne    0x7ffff7ab950e <memset+238>
   0x00007ffff7ab94ec <+204>:   test   $0x4,%dl
   0x00007ffff7ab94ef <+207>:   jne    0x7ffff7ab9507 <memset+231>
   0x00007ffff7ab94f1 <+209>:   test   $0x1,%dl
   0x00007ffff7ab94f4 <+212>:   je     0x7ffff7ab94f8 <memset+216>
   0x00007ffff7ab94f6 <+214>:   mov    %cl,(%rdi)
   0x00007ffff7ab94f8 <+216>:   test   $0x2,%dl
   0x00007ffff7ab94fb <+219>:   je     0x7ffff7ab945a <memset+58>
   0x00007ffff7ab9501 <+225>:   mov    %cx,-0x2(%rax,%rdx,1)
   0x00007ffff7ab9506 <+230>:   retq   
   0x00007ffff7ab9507 <+231>:   mov    %ecx,(%rdi)
   0x00007ffff7ab9509 <+233>:   mov    %ecx,-0x4(%rdi,%rdx,1)
   0x00007ffff7ab950d <+237>:   retq   
   0x00007ffff7ab950e <+238>:   mov    %rcx,(%rdi)
   0x00007ffff7ab9511 <+241>:   mov    %rcx,-0x8(%rdi,%rdx,1)
   0x00007ffff7ab9516 <+246>:   retq

(Dies ist in libc.so.6, nicht das Programm selbst -- die andere person, die versucht, einen dump der Versammlung für memset scheint nur gefunden zu haben, der seine PLT-Eintrag. Der einfachste Weg, um den assembly dump für die real memset auf eine Unixy system ist

$ gdb ./a.out
(gdb) set env LD_BIND_NOW t
(gdb) b main
Breakpoint 1 at [address]
(gdb) r
Breakpoint 1, [address] in main ()
(gdb) disas memset
...

Super Antwort! Ich hatte bereits akzeptiert JarkkoL Antwort wenn Ihr auftauchte in meinem browser. Ich denke, ich werde stick mit dieser Entscheidung, da seine Antwort richtig zu sein scheint.
Ah, ich dachte, ich muss falsch gewesen, über memset, vielen Dank für das posten des korrekten Demontage. Und es ist toll zu wissen, dass der trick in der gdb!
Der Hauptgrund movnt Läden geben kann, besser schreiben-Bandbreite für große memsets ist, dass Sie sind schwach bestellt. Sie können überspringen Sie die Lesen-für-ownership Schritt beim schreiben auf eine neue cache-Zeile, denn Sie sind nicht garantiert, werden weltweit sichtbares, um mit jeder anderen oder mit Bezug zu normalen Läden. Auf CPUs mit "fast string operations" (Intel IvB und höher) rep stos verwendet, etwas schwach bestellt speichert, um die gleiche Beschleunigung haben, aber nicht der cache umgangen. So wie ich das verstehe die docs, es gibt einen store Zaun am Ende der operation, also nur speichern nicht die fahne als Teil von memset/cpy.

InformationsquelleAutor zwol

28

Den wichtigsten Unterschied in der Leistung kommt aus der caching-Politik von Ihrem PC/memory region. Wenn Sie das Lesen aus einem Speicher, und die Daten nicht im cache, muss der Speicher zuerst geholt, um den cache über den Speicher-bus, bevor Sie durchführen können Berechnungen mit den Daten. Allerdings, wenn Sie in den Speicher schreiben, gibt es verschiedene schreiben Strategien. Höchstwahrscheinlich ist Ihr system mit write-back-cache (oder genauer gesagt "write allocate"), was bedeutet, dass, wenn Sie schreiben in einem Speicherort, der nicht im cache, werden die Daten zuerst holte aus dem Speicher in den cache und irgendwann wieder zurück in den Speicher geschrieben, wenn die Daten entfernt, die aus dem cache, was bedeutet, dass round-trip-für die Daten-und 2x bus-Bandbreite auf schreibt. Es ist auch write-through-caching-Richtlinie (oder "no-write-allocate") die in der Regel bedeutet, dass bei cache-miss auf, schreibt die Daten werden nicht geholt, um den cache, und die sollte näher an die gleiche Leistung für lese-und Schreibvorgänge.
- Vielen Dank für die Bestätigung meiner früheren Vermutung (ich postete es ~30 min früher)! Ich werde es akzeptieren, bis/es sei denn, jemand überzeugt mich, dass es sachlich falsch.
- Auf einigen Plattformen kann man eigentlich kontrollieren die caching-policy pro allocation und write-performance ist einer der Gründe.
- Konventionelle Architekturen zurück schreiben aller modifizierten Daten in den Speicher zu einem bestimmten Zeitpunkt. Heute, viele Plattformen versuchen, die Leistung zu verbessern durch zusätzliche cache-control-Funktionen. Zum Beispiel, Plattformen wie Cavium Octeon spezielle cache-control-Richtlinien wie DWB(nicht Zurück Schreiben) von Optionen nicht zurück schreiben L2-cache Daten. Durch diese unnötige L2-Daten schreiben sichert den Speicher vermieden werden können.
InformationsquelleAutor JarkkoL

Den Unterschied-zumindest auf meinem Rechner mit einem AMD-Prozessor-ist, dass die lese-Programm nutzt vektorisierte Operationen. Die Dekompilierung der beiden ergibt dies für das schreiben von Programmen:

0000000000400610 <main>:
  ...
  400628:       e8 73 ff ff ff          callq  4005a0 <clock@plt>
  40062d:       49 89 c4                mov    %rax,%r12
  400630:       89 de                   mov    %ebx,%esi
  400632:       ba 00 ca 9a 3b          mov    $0x3b9aca00,%edx
  400637:       48 89 ef                mov    %rbp,%rdi
  40063a:       e8 71 ff ff ff          callq  4005b0 <memset@plt>
  40063f:       0f b6 55 00             movzbl 0x0(%rbp),%edx
  400643:       b9 64 00 00 00          mov    $0x64,%ecx
  400648:       be 34 08 40 00          mov    $0x400834,%esi
  40064d:       bf 01 00 00 00          mov    $0x1,%edi
  400652:       31 c0                   xor    %eax,%eax
  400654:       48 83 c3 01             add    $0x1,%rbx
  400658:       e8 a3 ff ff ff          callq  400600 <__printf_chk@plt>

Aber diese für das Lesen-Programm:

00000000004005d0 <main>:
  ....
  400609:       e8 62 ff ff ff          callq  400570 <clock@plt>
  40060e:       49 d1 ee                shr    %r14
  400611:       48 89 44 24 18          mov    %rax,0x18(%rsp)
  400616:       4b 8d 04 e7             lea    (%r15,%r12,8),%rax
  40061a:       4b 8d 1c 36             lea    (%r14,%r14,1),%rbx
  40061e:       48 89 44 24 10          mov    %rax,0x10(%rsp)
  400623:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
  400628:       4d 85 e4                test   %r12,%r12
  40062b:       0f 84 df 00 00 00       je     400710 <main+0x140>
  400631:       49 8b 17                mov    (%r15),%rdx
  400634:       bf 01 00 00 00          mov    $0x1,%edi
  400639:       48 8b 74 24 10          mov    0x10(%rsp),%rsi
  40063e:       66 0f ef c0             pxor   %xmm0,%xmm0
  400642:       31 c9                   xor    %ecx,%ecx
  400644:       0f 1f 40 00             nopl   0x0(%rax)
  400648:       48 83 c1 01             add    $0x1,%rcx
  40064c:       66 0f ef 06             pxor   (%rsi),%xmm0
  400650:       48 83 c6 10             add    $0x10,%rsi
  400654:       49 39 ce                cmp    %rcx,%r14
  400657:       77 ef                   ja     400648 <main+0x78>
  400659:       66 0f 6f d0             movdqa %xmm0,%xmm2 ;!!!! vectorized magic
  40065d:       48 01 df                add    %rbx,%rdi
  400660:       66 0f 73 da 08          psrldq $0x8,%xmm2
  400665:       66 0f ef c2             pxor   %xmm2,%xmm0
  400669:       66 0f 7f 04 24          movdqa %xmm0,(%rsp)
  40066e:       48 8b 04 24             mov    (%rsp),%rax
  400672:       48 31 d0                xor    %rdx,%rax
  400675:       48 39 dd                cmp    %rbx,%rbp
  400678:       74 04                   je     40067e <main+0xae>
  40067a:       49 33 04 ff             xor    (%r15,%rdi,8),%rax
  40067e:       4c 89 ea                mov    %r13,%rdx
  400681:       49 89 07                mov    %rax,(%r15)
  400684:       b9 64 00 00 00          mov    $0x64,%ecx
  400689:       be 04 0a 40 00          mov    $0x400a04,%esi
  400695:       e8 26 ff ff ff          callq  4005c0 <__printf_chk@plt>
  40068e:       bf 01 00 00 00          mov    $0x1,%edi
  400693:       31 c0                   xor    %eax,%eax

Beachten Sie auch, dass Ihre "homegrown" memset ist tatsächlich optimiert unten, um einen Anruf zu memset:

00000000004007b0 <my_memset>:
  4007b0:       48 85 d2                test   %rdx,%rdx
  4007b3:       74 1b                   je     4007d0 <my_memset+0x20>
  4007b5:       48 83 ec 08             sub    $0x8,%rsp
  4007b9:       40 0f be f6             movsbl %sil,%esi
  4007bd:       e8 ee fd ff ff          callq  4005b0 <memset@plt>
  4007c2:       48 83 c4 08             add    $0x8,%rsp
  4007c6:       c3                      retq   
  4007c7:       66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
  4007ce:       00 00 
  4007d0:       48 89 f8                mov    %rdi,%rax
  4007d3:       c3                      retq   
  4007d4:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  4007db:       00 00 00 
  4007de:       66 90                   xchg   %ax,%ax

Ich finde keine Referenzen in Bezug auf ob oder nicht memset nutzt vektorisierte Operationen, die Demontage von memset@plt ist wenig hilfreich hier:

00000000004005b0 <memset@plt>:
  4005b0:       ff 25 72 0a 20 00       jmpq   *0x200a72(%rip)        # 601028 <_GLOBAL_OFFSET_TABLE_+0x28>
  4005b6:       68 02 00 00 00          pushq  $0x2
  4005bb:       e9 c0 ff ff ff          jmpq   400580 <_init+0x20>

Diese Frage deutet darauf hin, dass seit memset ist entworfen, um zu behandeln jeden Fall, es fehlen möglicherweise einige Optimierungen.

Dieser Kerl scheint durchaus davon überzeugt, dass Sie brauchen, um zu Rollen Sie Ihre eigenen assembler memset um die Vorteile von SIMD-Anweisungen. Diese Frage stellt auch.

Ich werde einen Schuss im Dunkeln und denke, dass es keine SIMD-Operationen, weil Sie nicht sagen kann, ob oder nicht es geht um den Betrieb auf etwas, das ein Vielfaches der Größe einer Vektorgrafik-Betrieb, oder ein alignment-Problem.

Jedoch, können wir bestätigen, dass es nicht ein Problem der cache-Effizienz, indem Sie mit cachegrind. Das schreiben Programm erzeugt die folgende:

==19593== D   refs:       6,312,618,768  (80,386 rd   + 6,312,538,382 wr)
==19593== D1  misses:     1,578,132,439  ( 5,350 rd   + 1,578,127,089 wr)
==19593== LLd misses:     1,578,131,849  ( 4,806 rd   + 1,578,127,043 wr)
==19593== D1  miss rate:           24.9% (   6.6%     +          24.9%  )
==19593== LLd miss rate:           24.9% (   5.9%     +          24.9%  )
==19593== 
==19593== LL refs:        1,578,133,467  ( 6,378 rd   + 1,578,127,089 wr)
==19593== LL misses:      1,578,132,871  ( 5,828 rd   + 1,578,127,043 wr) << 
==19593== LL miss rate:             9.0% (   0.0%     +          24.9%  )

und das lese-Programm produziert:

==19682== D   refs:       6,312,618,618  (6,250,080,336 rd   + 62,538,282 wr)
==19682== D1  misses:     1,578,132,331  (1,562,505,046 rd   + 15,627,285 wr)
==19682== LLd misses:     1,578,131,740  (1,562,504,500 rd   + 15,627,240 wr)
==19682== D1  miss rate:           24.9% (         24.9%     +       24.9%  )
==19682== LLd miss rate:           24.9% (         24.9%     +       24.9%  )
==19682== 
==19682== LL refs:        1,578,133,357  (1,562,506,072 rd   + 15,627,285 wr)
==19682== LL misses:      1,578,132,760  (1,562,505,520 rd   + 15,627,240 wr) <<
==19682== LL miss rate:             4.1% (          4.1%     +       24.9%  )

Während die lese-Programm hat eine niedrigere LL-miss-rate, denn es führt viele mehr liest (ein extra Lesen pro XOR Betrieb), die Gesamtzahl der findet ist der gleiche. Also, was auch immer das Problem ist, es ist nicht da.

Sind Sie auch zu sehen das 2-fache Unterschied in der Bandbreite? Können Sie veröffentlichen Ihre zahlen und RAM-Konfiguration?
This guy definitely seems convinced ... Seine Puffer ist 244000 mal kleiner und passt in verschiedene caches.

InformationsquelleAutor Patrick Collins

9

Caching und Lokalität fast sicher erklären, die meisten der Effekte, die Sie sehen.

Gibt es keine Zwischenspeicherung oder der Lokalität auf, schreibt, es sei denn, Sie wollen ein nicht-deterministisches system. Die meisten schreiben mal gemessen als die Zeit, die es dauert, die Daten zu bekommen, die alle den Weg auf das Speichermedium (ob das eine Festplatte oder ein Speicher-chip), in der Erwägung, dass liest kann aus einer beliebigen Anzahl von cache-Ebenen, die schneller sind als das Speichermedium.
- 1 GB array ist viel größer als alle cache-Größe (das ist, warum ich wählte es). Durch die Zeit, die do_xor läuft die zweite Zeit, alle zuvor zwischengespeicherten Werte wurden gestrichen. Neben der Zwischenspeicherung erklären könnte, Lesen schneller als die DRAM->Cache link (falls dies der Fall ist). Es erklärt nicht schreiben wird langsamer.
- Ich hoffe, es ist selbstverständlich, dass Sie nicht brauchen, eine 1-GB-cache, um noch das cache-Effekte.
- +1-ich bin bereit zu Wetten, dass dieses Verfahren etwas damit zu tun hat; es ist nicht zu helfen, diejenigen schreibt, aber es wird helfen, die liest. Ich bin auch bereit zu Wetten, dass GCC ist weniger bereit, neu zu ordnen, schreibt als liest.
- Auf x86 -, normal-Geschäften (nicht movnt) stark bestellt. In einem schreiben an einen kalten cache-line Trigger-Lesen-für-Eigentum. Wie ich es verstehe, ist die CPU wirklich macht ein Lesen vom DRAM (oder niedrigeren level cache) zum füllen des cache-Zeile. Schreibt härter sind als Lesevorgänge für ein system mit stark bestellt Speicher (wie x86), aber nicht für den Grund, den Sie geben. Shops erlaubt sind, gepuffert werden und zu weltweit sichtbar, nachdem die Lasten von den selben thread. (MFENCE ist ein StoreLoad Schranke...) die AMD ist die Verwendung von write-through-caches für Einfachheit, aber Intel verwendet die write-back für bessere Leistung.
- Es ist definitiv wahr, in der Praxis, dass die Wiederholung einer nur-schreiben-Schleife (wie z.B. memset) mit einem Puffer, der passt in L1 ist schneller als mit einem größeren Puffer. Teil davon ist, dass die Zeilen, die bereits in der M-Zustand (MESI) ist nicht erforderlich-alle anderen Linien werden entfernt (das könnte stall, wenn Sie den entfernten Linie wurde in den M-Zustand und geschrieben werden musste, L2 ersten, esp. wenn L2, dann entfernt eine modifizierte Zeile, etc. down-to-DRAM). Aber ein anderer Teil, dass ist die Vermeidung der Lesen-für-Eigentum, wenn eine cacheline ist schon im E-oder M-Zustand. movnt und Schnelle String-rep movsb schwach-bestellten Geschäfte vermeiden, die RFO.
InformationsquelleAutor Robert Harvey
6

Könnte es Nur, Wie es (das-System-as-a-Ganzes) Führt. Das Lesen wird schneller scheint ein allgemeiner trend mit einem Breite Palette der relative Durchsatz-performance. Auf einem schnelle Analyse der DDR3 Intel und DDR2-charts aufgeführt, als einigen wenigen Fällen (schreiben/Lesen)%;

Einige top-performing-DDR3-chips sind schriftlich bei ~60-70% der lese-Durchsatz. Es gibt jedoch einige Speichermodule (ie. Das goldene Reich CL11-13-13-D3-2666) bis zu nur ~30% schreiben.

Top-performing-DDR2-chips scheinen nur etwa ~50% der write-Durchsatz im Vergleich zu Lesen. Aber es gibt auch einige, insbesondere bad-Anwärter (ie. OCZ OCZ21066NEW_BT1G) bis zu ~20%.

Dies ist zwar nicht erklären die Ursache für die ~40% write/read berichtete, wie benchmark-code und setup verwendet, ist wahrscheinlich anders (die Noten sind vage), dies ist definitiv eine Faktor. (Ich würde einige der bestehenden benchmark-Programme und sehen, wenn die zahlen fallen in eine Linie mit denen des Kodex in Frage.)

Update:

Ich habe die memory-look-up-Tabelle aus der verknüpften Seiten und bearbeitet es in Excel. Während es zeigt immer noch eine Breite Palette von Werten ist es viel weniger arg als die ursprüngliche Antwort oben, die schauten nur auf die top-lese-Speicher-chips und ein paar ausgewählte "interessante" Einträge aus den charts. Ich bin mir nicht sicher, warum die Unterschiede, vor allem in der schrecklichen Anwärter herausgegriffen oben, sind nicht in die sekundäre Liste.

Jedoch auch unter der neuen zahlen wird der Unterschied noch reicht überall von 50%-100% (median 65, Mittelwert 65) der lese-performance. Bitte beachten Sie, dass, nur weil ein chip war "100%" effizient in einem schreib - /lese-Verhältnis bedeutet nicht, es war insgesamt besser .. nur, dass es mehr selbst-Kiel zwischen den beiden Operationen.
- Es ist unklar, ob Sie 1 DIMM oder mehrere DIMMs installiert. Ich glaube, dass kann einen sehr signifikanten Unterschied. Mein test ist "rein" in dem Sinne, dass ich nur 1 DIMM.
- Es ist nicht ganz klar, aber es zeigt sich aber auch eine Vielzahl von Werten. Deshalb meine Empfehlung wäre zu sehen, wenn andere benchmarks, die Programme führen ähnliche Werte auf der bestimmten Maschine; und wenn ja, ob die geposteten benchmark folgt auch Klage auf unterschiedliche hardware.
InformationsquelleAutor user2864740
4

Hier ist meine Arbeitshypothese. Wenn das stimmt, erklärt es, warum schreibt etwa zweimal langsamer als liest:

Obwohl memset nur schreibt, um den virtuellen Speicher ignoriert die vorherigen Inhalte, die auf hardware-Ebene der computer nicht ein reines schreiben DRAM: es liest den Inhalt des DRAM in den cache aus, modifiziert es und dann schreibt Sie wieder zu DRAM. Daher, die auf hardware-Ebene memset bedeutet sowohl Lesen, als auch schreiben (obwohl der ehemalige scheint nutzlos)! Daher die ungefähr zwei-Fach-speed-Unterschied.
- Sie können dies vermeiden, Lesen Sie-zum-Eigentum mit schwach-bestellt stores (movnt oder Intel IvB-und-später rep stos / rep movs "Fast String Operations"). Es nervt, dass es nicht eine bequeme Möglichkeit schwach-bestellt-Shops (außer memset/memcpy auf aktuelle Intel CPUs) ohne auch unter Umgehung des cache. Ich verließ ähnliche Kommentare auf einige andere Antworten: der Hauptgrund für normal schreibt auslösen liest ist x86 ist stark-bestellt-Speicher-Modell. Begrenzen Sie Ihr system, um ein DIMM oder nicht, sollte nicht ein Faktor in diesem.
- Ich erwarte, dass einige andere Architekturen, wie ARM, Schreibe bei voller DRAM-Bandbreite ohne zusätzlichen Aufwand, denn es gibt keine Garantie, dass die Geschäfte werden sichtbar sein, andere threads in der Programm-Reihenfolge. z.B. ein Geschäft, um ein hot-cache-Zeile passieren könnte, sofort (oder zumindest, nachdem Sie sicher, dass keine Vorherige Anweisung kann Fehler oder ein mispredicted Zweig), aber ein Geschäft zu kalt cache-Zeile kann nur erhalten gepuffert, ohne jede Möglichkeit für andere Kerne um den Wert zu sehen, bis die Kälte cache-Zeile ist komplett neu geschrieben und in den store-Puffer gespült.
InformationsquelleAutor MaxB
2

Da Lesen Sie einfach Puls obigen Zeilen, die Adresse und das Auslesen der core-Staaten auf die Sinn-Linien. Die write-back-Zyklus Auftritt, nachdem die Daten geliefert, um die CPU und damit auch nicht die Dinge verlangsamen. Auf der anderen Seite, zu schreiben, müssen Sie zuerst eine gefälschte Lesen Sie zurücksetzen, um die Kerne, dann führen Sie den write-Zyklus.

(Nur, falls es nicht offensichtlich ist diese Antwort tongue-in-cheek -- beschreiben warum schreiben langsamer als das Lesen auf einem alten core-memory-box.)

InformationsquelleAutor Hot Licks

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.