Warum sind elementweise Additionen in separaten Schleifen viel schneller als in einer kombinierten Schleife?

OK, die richtige Antwort hat definitiv etwas mit dem CPU-Cache zu tun. Die Verwendung des Cache-Arguments kann jedoch sehr schwierig sein, insbesondere ohne Daten.

Es gibt viele Antworten, die zu vielen Diskussionen geführt haben, aber seien wir ehrlich: Cache-Probleme können sehr komplex und nicht eindimensional sein. Sie hängen stark von der Größe der Daten ab, daher war meine Frage unfair: Es stellte sich heraus, dass es sich um einen sehr interessanten Punkt im Cache-Diagramm handelt.

Die Antwort von @Mysticial überzeugte viele Leute (einschließlich mich), wahrscheinlich, weil es der einzige war, der sich auf Fakten zu verlassen schien, aber es war nur ein "Datenpunkt" der Wahrheit.

Deshalb habe ich seinen Test (mit einer fortlaufenden vs. getrennten Zuordnung) und den Rat von @James 'Answer kombiniert.

Die nachstehenden Grafiken zeigen, dass die meisten Antworten und insbesondere die meisten Kommentare zu den Fragen und Antworten je nach verwendetem Szenario und verwendeten Parametern als völlig falsch oder wahr eingestuft werden können.

Beachten Sie, dass meine erste Frage bei n = 100.0 war. Dieser Punkt weist (aus Versehen) ein besonderes Verhalten auf:

1. Es weist die größte Diskrepanz zwischen der Version mit einer und zwei Schleifen auf (fast ein Faktor drei).

2. Es ist der einzige Punkt, an dem Ein-Loop (nämlich mit kontinuierlicher Zuordnung) die Zwei-Loop-Version schlägt. (Dies ermöglichte Mystikals Antwort überhaupt.)

Das Ergebnis mit initialisierten Daten:

Das Ergebnis unter Verwendung nicht initialisierter Daten (dies wurde von Mysticial getestet):

Und das ist schwer zu erklären: Initialisierte Daten, die einmal vergeben und für jeden folgenden Testfall unterschiedlicher Vektorgröße wiederverwendet werden:

Vorschlag

Jede leistungsbezogene Frage zu Stack Overflow auf niedriger Ebene sollte erforderlich sein, um MFLOPS-Informationen für den gesamten Bereich der Cache-relevanten Datengrößen bereitzustellen! Es ist eine Verschwendung von Zeit, über Antworten nachzudenken und diese ohne diese Informationen mit anderen zu diskutieren.

Die zweite Schleife erfordert viel weniger Cache-Aktivität, sodass der Prozessor den Speicherbedarf leichter bewältigen kann.

Stellen Sie sich vor, Sie arbeiten auf einem Computer, auf dem n genau der richtige Wert war, um nur zwei Ihrer Arrays gleichzeitig im Speicher zu halten halte alle vier.

Unter der Annahme einer einfachen Caching-Richtlinie LIFO lautet dieser Code:

for(int j=0;j<n;j++){
    a[j] += b[j];
}
for(int j=0;j<n;j++){
    c[j] += d[j];
}

würde zuerst bewirken, dass a und b in RAM geladen und dann vollständig im RAM bearbeitet werden. Wenn die zweite Schleife startet, werden c und d von der Festplatte in RAM geladen und bearbeitet.

die andere Schleife

for(int j=0;j<n;j++){
    a[j] += b[j];
    c[j] += d[j];
}

wird zwei Arrays auslagern und in den anderen zwei blättern jedes Mal um die Schleife. Dies wäre offensichtlich viel langsamer.

Wahrscheinlich sehen Sie in Ihren Tests kein Platten-Caching, aber Sie sehen wahrscheinlich die Nebenwirkungen einer anderen Form des Caching.

Es scheint hier ein wenig Verwirrung/Missverständnis zu geben, deshalb werde ich versuchen, ein wenig anhand eines Beispiels zu erläutern.

Sagen Sie n = 2 und wir arbeiten mit Bytes. In meinem Szenario haben wir also nur 4 Bytes RAM und der Rest unseres Speichers ist bedeutend langsamer (sagen wir 100-mal längerer Zugriff).

Unter der Annahme einer ziemlich dummen Caching-Richtlinie von , wenn sich das Byte nicht im Cache befindet, platzieren Sie es dort und holen Sie sich auch das folgende Byte, während wir dabei sind Holen Sie sich ein Szenario wie folgt:

• Mit

  for(int j=0;j<n;j++){
   a[j] += b[j];
  }
  for(int j=0;j<n;j++){
   c[j] += d[j];
  }
  

• cache a[0] und a[1] dann b[0] und b[1] und setze a[0] = a[0] + b[0] in den Cache - es sind jetzt vier Bytes im Cache, a[0], a[1] und b[0], b[1]. Kosten = 100 + 100.

• setze a[1] = a[1] + b[1] in den Cache. Kosten = 1 + 1.
• Wiederholen Sie diesen Vorgang für c und d.

• Gesamtkosten = (100 + 100 + 1 + 1) * 2 = 404

• Mit

  for(int j=0;j<n;j++){
   a[j] += b[j];
   c[j] += d[j];
  }
  

• cache a[0] und a[1] dann b[0] und b[1] und setze a[0] = a[0] + b[0] in den Cache - es sind jetzt vier Bytes im Cache, a[0], a[1] und b[0], b[1]. Kosten = 100 + 100.

• werfen Sie a[0], a[1], b[0], b[1] aus dem Cache und Cache c[0] und c[1] dann d[0] und d[1] und setzen Sie c[0] = c[0] + d[0] in den Cache. Kosten = 100 + 100.
• Ich vermute, Sie beginnen zu sehen, wohin ich gehe.
• Gesamtkosten = (100 + 100 + 100 + 100) * 2 = 800

Dies ist ein klassisches Cache-Thrash-Szenario.

Dies liegt nicht an einem anderen Code, sondern an der Zwischenspeicherung: RAM ist langsamer als die CPU-Register und es befindet sich ein Cache-Speicher in der CPU, um zu vermeiden, dass jedes Mal eine Variable in RAM geschrieben wird verändert sich. Der Cache ist jedoch nicht so groß wie der RAM, sodass er nur einen Bruchteil davon abbildet.

Der erste Code ändert entfernte Speicheradressen, indem er sie bei jeder Schleife abwechselt, so dass der Cache kontinuierlich ungültig gemacht werden muss.

Der zweite Code wechselt nicht: Er fließt nur zweimal über benachbarte Adressen. Dadurch wird der gesamte Auftrag im Cache abgeschlossen und erst nach dem Start der zweiten Schleife ungültig.

Ich kann die hier diskutierten Ergebnisse nicht replizieren.

Ich weiß nicht, ob ein schlechter Benchmark-Code daran schuld ist oder nicht, aber die beiden Methoden liegen auf meinem Computer mit dem folgenden Code innerhalb von 10% voneinander, und eine Schleife ist normalerweise nur geringfügig schneller als zwei - wie Sie möchten erwarten von.

Die Arraygrößen reichten von 2 ^ 16 bis 2 ^ 24, wobei acht Schleifen verwendet wurden. Ich habe darauf geachtet, die Quell-Arrays zu initialisieren, damit die += -Zuweisung das FPU nicht aufforderte, Speichermüll hinzuzufügen, der als Double interpretiert wurde.

Ich habe mit verschiedenen Schemata herumgespielt, wie z. B. die Zuordnung von b[j], d[j] zu InitToZero[j] in den Schleifen und auch die Verwendung von += b[j] = 1 und += d[j] = 1, und ich habe ziemlich konsistente Ergebnisse.

Das Initialisieren von b und d innerhalb der Schleife mit InitToZero[j] brachte erwartungsgemäß den Vorteil des kombinierten Ansatzes, da diese vor den Zuweisungen zu a und c, aber immer noch innerhalb von 10% durchgeführt wurden. Stelle dir das vor.

Hardware ist Dell XPS 85 mit Generation 3 Core i7 bei 3,4 GHz und 8 GB Speicher. Für 2 ^ 16 bis 2 ^ 24 unter Verwendung von acht Schleifen betrug die kumulative Zeit 44,987 bzw. 40,965. Visual C++ 2010, vollständig optimiert.

PS: Ich habe die Schleifen so geändert, dass sie bis auf Null herunter zählen, und die kombinierte Methode war geringfügig schneller. Ich kratzte mich am Kopf. Beachten Sie die neue Größe des Arrays und die Anzahl der Schleifen.

// MemBufferMystery.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
#include <cmath>
#include <string>
#include <time.h>

#define  dbl    double
#define  MAX_ARRAY_SZ    262145    //16777216    // AKA (2^24)
#define  STEP_SZ           1024    //   65536    // AKA (2^16)

int _tmain(int argc, _TCHAR* argv[]) {
    long i, j, ArraySz = 0,  LoopKnt = 1024;
    time_t start, Cumulative_Combined = 0, Cumulative_Separate = 0;
    dbl *a = NULL, *b = NULL, *c = NULL, *d = NULL, *InitToOnes = NULL;

    a = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    b = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    c = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    d = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    InitToOnes = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    // Initialize array to 1.0 second.
    for(j = 0; j< MAX_ARRAY_SZ; j++) {
        InitToOnes[j] = 1.0;
    }

    // Increase size of arrays and time
    for(ArraySz = STEP_SZ; ArraySz<MAX_ARRAY_SZ; ArraySz += STEP_SZ) {
        a = (dbl *)realloc(a, ArraySz * sizeof(dbl));
        b = (dbl *)realloc(b, ArraySz * sizeof(dbl));
        c = (dbl *)realloc(c, ArraySz * sizeof(dbl));
        d = (dbl *)realloc(d, ArraySz * sizeof(dbl));
        // Outside the timing loop, initialize
        // b and d arrays to 1.0 sec for consistent += performance.
        memcpy((void *)b, (void *)InitToOnes, ArraySz * sizeof(dbl));
        memcpy((void *)d, (void *)InitToOnes, ArraySz * sizeof(dbl));

        start = clock();
        for(i = LoopKnt; i; i--) {
            for(j = ArraySz; j; j--) {
                a[j] += b[j];
                c[j] += d[j];
            }
        }
        Cumulative_Combined += (clock()-start);
        printf("\n %6i miliseconds for combined array sizes %i and %i loops",
                (int)(clock()-start), ArraySz, LoopKnt);
        start = clock();
        for(i = LoopKnt; i; i--) {
            for(j = ArraySz; j; j--) {
                a[j] += b[j];
            }
            for(j = ArraySz; j; j--) {
                c[j] += d[j];
            }
        }
        Cumulative_Separate += (clock()-start);
        printf("\n %6i miliseconds for separate array sizes %i and %i loops \n",
                (int)(clock()-start), ArraySz, LoopKnt);
    }
    printf("\n Cumulative combined array processing took %10.3f seconds",
            (dbl)(Cumulative_Combined/(dbl)CLOCKS_PER_SEC));
    printf("\n Cumulative seperate array processing took %10.3f seconds",
        (dbl)(Cumulative_Separate/(dbl)CLOCKS_PER_SEC));
    getchar();

    free(a); free(b); free(c); free(d); free(InitToOnes);
    return 0;
}

Ich bin mir nicht sicher, warum entschieden wurde, dass MFLOPS eine relevante Metrik ist. Ich dachte, die Idee sei, mich auf Speicherzugriffe zu konzentrieren, also habe ich versucht, die Gleitkomma-Rechenzeit zu minimieren. Ich bin im += abgereist, bin mir aber nicht sicher warum.

Eine direkte Zuweisung ohne Berechnung wäre ein sauberer Test der Speicherzugriffszeit und würde einen Test erzeugen, der unabhängig von der Schleifenzahl einheitlich ist. Vielleicht habe ich etwas im Gespräch verpasst, aber es lohnt sich, zweimal darüber nachzudenken. Wird das Plus aus der Zuordnung herausgerechnet, ist die kumulierte Zeit mit jeweils 31 Sekunden nahezu identisch.

Dies liegt daran, dass die CPU nicht so viele Cache-Fehler aufweist (und warten muss, bis die Array-Daten von den RAM Chips stammen). Es wäre interessant für Sie, die Größe der Arrays kontinuierlich anzupassen, damit Sie die Größen des Level 1-Cache (L1) und dann des Level 2-Cache (überschreiten. L2) Ihrer CPU und zeichnen Sie die Ausführungszeit Ihres Codes in Abhängigkeit von der Größe der Arrays auf. Das Diagramm sollte keine gerade Linie sein, wie Sie es erwarten würden.

Die erste Schleife schreibt abwechselnd in jede Variable. Die zweiten und dritten machen nur kleine Sprünge von Elementgröße.

Versuchen Sie, zwei parallele Linien von 20 Kreuzen mit einem Stift und Papier in einem Abstand von 20 cm zu schreiben. Versuchen Sie einmal, die eine und dann die andere Zeile zu beenden, und versuchen Sie es ein anderes Mal, indem Sie abwechselnd ein Kreuz in jede Zeile schreiben.

Es kann altes C++ und Optimierungen sein. Auf meinem Computer habe ich fast die gleiche Geschwindigkeit erhalten:

Eine Schleife: 1,577 ms

Zwei Schleifen: 1,507 ms

Ich führe Visual Studio 2015 auf einem E5-1620 3,5-GHz-Prozessor mit 16 GB RAM aus.