Ich untersuche die Auswirkung der Vektorisierung auf die Leistung des Programms. Dazu habe ich folgenden Code geschrieben:
#include <stdio.h>
#include <sys/time.h>
#include <stdlib.h>
#define LEN 10000000
int main(){
struct timeval stTime, endTime;
double* a = (double*)malloc(LEN*sizeof(*a));
double* b = (double*)malloc(LEN*sizeof(*b));
double* c = (double*)malloc(LEN*sizeof(*c));
int k;
for(k = 0; k < LEN; k++){
a[k] = rand();
b[k] = rand();
}
gettimeofday(&stTime, NULL);
for(k = 0; k < LEN; k++)
c[k] = a[k] * b[k];
gettimeofday(&endTime, NULL);
FILE* fh = fopen("dump", "w");
for(k = 0; k < LEN; k++)
fprintf(fh, "c[%d] = %f\t", k, c[k]);
fclose(fh);
double timeE = (double)(endTime.tv_usec + endTime.tv_sec*1000000 - stTime.tv_usec - stTime.tv_sec*1000000);
printf("Time elapsed: %f\n", timeE);
return 0;
}
In diesem Code initialisiere und multipliziere ich einfach zwei Vektoren. Die Ergebnisse werden im Vektor gespeichert c. Was mich hauptsächlich interessiert, ist der Effekt der Vektorisierung der folgenden Schleife:
for(k = 0; k < LEN; k++)
c[k] = a[k] * b[k];
Ich kompiliere den Code mit den folgenden zwei Befehlen:
1) icc -O2 TestSMID.c -o TestSMID -no-vec -no-simd
2) icc -O2 TestSMID.c -o TestSMID -vec-report2
Ich erwarte eine Leistungsverbesserung, da der zweite Befehl die Schleife erfolgreich vektorisiert. Meine Studien zeigen jedoch, dass es keine Leistungsverbesserung gibt, wenn die Schleife vektorisiert wird.
Vielleicht habe ich hier etwas übersehen, da ich mich mit dem Thema nicht so gut auskenne. Bitte lassen Sie mich wissen, wenn etwas mit meinem Code nicht stimmt.
Vielen Dank im Voraus für Ihre Hilfe.
PS: Ich verwende Mac OSX, daher müssen die Daten nicht ausgerichtet werden, da alle zugewiesenen Speicher 16-Byte-ausgerichtet sind.
Bearbeiten: Ich möchte mich zunächst bei Ihnen allen für Ihre Kommentare und Antworten bedanken. Ich habe über die von @Mystcial vorgeschlagene Antwort nachgedacht und es gibt einige weitere Punkte, die hier erwähnt werden sollten. Erstens, wie @Vinska erwähnte, c[k]=a[k]*b[k] dauert nicht nur einen Zyklus. Zusätzlich zum Inkrement des Schleifenindexes und des durchgeführten Vergleichs wird dies sichergestellt k ist kleiner als LEN, müssen noch andere Dinge getan werden, um die Operation durchzuführen. Wenn man sich den vom Compiler generierten Assemblercode ansieht, sieht man, dass eine einfache Multiplikation viel mehr als einen Zyklus benötigt. Die vektorisierte Version sieht so aus:
L_B1.9: # Preds L_B1.8
movq %r13, %rax #25.5
andq $15, %rax #25.5
testl %eax, %eax #25.5
je L_B1.12 # Prob 50% #25.5
# LOE rbx r12 r13 r14 r15 eax
L_B1.10: # Preds L_B1.9
testb $7, %al #25.5
jne L_B1.32 # Prob 10% #25.5
# LOE rbx r12 r13 r14 r15
L_B1.11: # Preds L_B1.10
movsd (%r14), %xmm0 #26.16
movl $1, %eax #25.5
mulsd (%r15), %xmm0 #26.23
movsd %xmm0, (%r13) #26.9
# LOE rbx r12 r13 r14 r15 eax
L_B1.12: # Preds L_B1.11 L_B1.9
movl %eax, %edx #25.5
movl %eax, %eax #26.23
negl %edx #25.5
andl $1, %edx #25.5
negl %edx #25.5
addl $10000000, %edx #25.5
lea (%r15,%rax,8), %rcx #26.23
testq $15, %rcx #25.5
je L_B1.16 # Prob 60% #25.5
# LOE rdx rbx r12 r13 r14 r15 eax
L_B1.13: # Preds L_B1.12
movl %eax, %eax #25.5
# LOE rax rdx rbx r12 r13 r14 r15
L_B1.14: # Preds L_B1.14 L_B1.13
movups (%r15,%rax,8), %xmm0 #26.23
movsd (%r14,%rax,8), %xmm1 #26.16
movhpd 8(%r14,%rax,8), %xmm1 #26.16
mulpd %xmm0, %xmm1 #26.23
movntpd %xmm1, (%r13,%rax,8) #26.9
addq $2, %rax #25.5
cmpq %rdx, %rax #25.5
jb L_B1.14 # Prob 99% #25.5
jmp L_B1.20 # Prob 100% #25.5
# LOE rax rdx rbx r12 r13 r14 r15
L_B1.16: # Preds L_B1.12
movl %eax, %eax #25.5
# LOE rax rdx rbx r12 r13 r14 r15
L_B1.17: # Preds L_B1.17 L_B1.16
movsd (%r14,%rax,8), %xmm0 #26.16
movhpd 8(%r14,%rax,8), %xmm0 #26.16
mulpd (%r15,%rax,8), %xmm0 #26.23
movntpd %xmm0, (%r13,%rax,8) #26.9
addq $2, %rax #25.5
cmpq %rdx, %rax #25.5
jb L_B1.17 # Prob 99% #25.5
# LOE rax rdx rbx r12 r13 r14 r15
L_B1.18: # Preds L_B1.17
mfence #25.5
# LOE rdx rbx r12 r13 r14 r15
L_B1.19: # Preds L_B1.18
mfence #25.5
# LOE rdx rbx r12 r13 r14 r15
L_B1.20: # Preds L_B1.14 L_B1.19 L_B1.32
cmpq $10000000, %rdx #25.5
jae L_B1.24 # Prob 0% #25.5
# LOE rdx rbx r12 r13 r14 r15
L_B1.22: # Preds L_B1.20 L_B1.22
movsd (%r14,%rdx,8), %xmm0 #26.16
mulsd (%r15,%rdx,8), %xmm0 #26.23
movsd %xmm0, (%r13,%rdx,8) #26.9
incq %rdx #25.5
cmpq $10000000, %rdx #25.5
jb L_B1.22 # Prob 99% #25.5
# LOE rdx rbx r12 r13 r14 r15
L_B1.24: # Preds L_B1.22 L_B1.20
Und die nicht vektoisierte Version ist:
L_B1.9: # Preds L_B1.8
xorl %eax, %eax #25.5
# LOE rbx r12 r13 r14 r15 eax
L_B1.10: # Preds L_B1.10 L_B1.9
lea (%rax,%rax), %edx #26.9
incl %eax #25.5
cmpl $5000000, %eax #25.5
movsd (%r15,%rdx,8), %xmm0 #26.16
movsd 8(%r15,%rdx,8), %xmm1 #26.16
mulsd (%r13,%rdx,8), %xmm0 #26.23
mulsd 8(%r13,%rdx,8), %xmm1 #26.23
movsd %xmm0, (%rbx,%rdx,8) #26.9
movsd %xmm1, 8(%rbx,%rdx,8) #26.9
jb L_B1.10 # Prob 99% #25.5
# LOE rbx r12 r13 r14 r15 eax
Außerdem lädt der Prozessor nicht nur 24 Bytes. Bei jedem Zugriff auf den Speicher wird eine volle Zeile (64 Bytes) geladen. Noch wichtiger, da der erforderliche Speicher für a, bund c zusammenhängend ist, würde der Prefetcher definitiv viel helfen und lädt die nächsten Blöcke im Voraus. Allerdings halte ich die von @Mystcial berechnete Speicherbandbreite für zu pessimistisch.
Darüber hinaus wird die Verwendung von SIMD zur Verbesserung der Programmleistung für eine sehr einfache Addition in erwähnt Leitfaden zur Intel-Vektorisierung. Daher scheint es, dass wir in der Lage sein sollten, eine Leistungsverbesserung für diese sehr einfache Schleife zu erzielen.
Edit2: Nochmals vielen Dank für Ihre Kommentare. Dank des Beispielcodes von @Mystcial habe ich endlich die Auswirkung von SIMD auf die Leistungsverbesserung gesehen. Das Problem war, wie Mystcial erwähnte, die Speicherbandbreite. Mit der Wahl kleiner Größe für a, bund c die in den L1-Cache passen, zeigt sich, dass SIMD helfen kann, die Performance deutlich zu verbessern. Hier sind die Ergebnisse, die ich erhalten habe:
icc -O2 -o TestSMIDNoVec -no-vec TestSMID2.c: 17.34 sec
icc -O2 -o TestSMIDVecNoUnroll -vec-report2 TestSMID2.c: 9.33 sec
Und das Aufrollen der Schleife verbessert die Leistung noch weiter:
icc -O2 -o TestSMIDVecUnroll -vec-report2 TestSMID2.c -unroll=8: 8.6sec
Außerdem sollte ich erwähnen, dass mein Prozessor nur einen Zyklus benötigt, um eine Iteration abzuschließen, wenn er mit kompiliert wird -O2.
PS: Mein Computer ist ein Macbook Pro Core i5 @2.5GHz (Dual Core)
Ich habe gerade meine Antwort aktualisiert, um zu beweisen, dass mein Prozessor 1 Iteration pro Zyklus ausführen kann, und um zu erklären, wie dies möglich ist.
– Mystisch
10. August 2013 um 20:16 Uhr
Ich hasse es wirklich, das anzusprechen, aber die Build-Befehle platzieren beide Versionen der ausführbaren Datei in derselben Datei. Es wäre viel klarer gewesen, wenn die beiden Versionen unterschiedliche Namen gehabt hätten.
– Wallyk
11. August 2013 um 3:07 Uhr
Sie sagen, dass es “keine Notwendigkeit zum Ausrichten” gibt, aber der generierte asm-Code prüft alle Ausrichtungsmöglichkeiten. Es gibt eine Schleife für Quellen, die nicht ausgerichtet sind, und eine Schleife, die verwendet wird
mulpdmit einem Speicheroperanden. Aber auch die ausgerichtete Version verwendet das Seltsamemovsd+movhpdFolge zum Laden 128b. Ich denke, das ist fürcundaausgerichtet,bnicht ausgerichtet (nach Skalar-Intro). Ich glaube, ich erinnere mich, dass ich gelesen habe, dass auf einigen älteren Architekturen eine 2-Insn-Sequenz manchmal schneller war alsmovupd. Die Nur-Ziel-ausgerichtete Version der Schleife verwendetmovupdfür eine Quelle und die 2 insn-Methode für die andere, /boggle.– Peter Cordes
5. Juli 2015 um 2:51 Uhr
Welche Größe von
LENhaben sie gewählt?– Manolete
23. November 2018 um 18:44 Uhr