Ich habe einen Multiply-Add-Kernel in meiner Anwendung und möchte seine Leistung erhöhen.
Ich verwende einen Intel Core i7-960 (3,2 GHz Takt) und habe den Kernel bereits per SSE Intrinsic wie folgt manuell implementiert:
for(int i=0; i<iterations; i+=4) {
y1 = _mm_set_ss(output[i]);
y2 = _mm_set_ss(output[i+1]);
y3 = _mm_set_ss(output[i+2]);
y4 = _mm_set_ss(output[i+3]);
for(k=0; k<ksize; k++){
for(l=0; l<ksize; l++){
w = _mm_set_ss(weight[i+k+l]);
x1 = _mm_set_ss(input[i+k+l]);
y1 = _mm_add_ss(y1,_mm_mul_ss(w,x1));
…
x4 = _mm_set_ss(input[i+k+l+3]);
y4 = _mm_add_ss(y4,_mm_mul_ss(w,x4));
}
}
_mm_store_ss(&output[i],y1);
_mm_store_ss(&output[i+1],y2);
_mm_store_ss(&output[i+2],y3);
_mm_store_ss(&output[i+3],y4);
}
Ich weiß, dass ich gepackte fp-Vektoren verwenden kann, um die Leistung zu steigern, und ich habe dies bereits erfolgreich getan, aber ich möchte wissen, warum der einzelne skalare Code die Spitzenleistung des Prozessors nicht erreichen kann.
Die Leistung dieses Kernels auf meiner Maschine beträgt ~1,6 FP-Operationen pro Zyklus, während das Maximum 2 FP-Operationen pro Zyklus wären (da FP add + FP mul parallel ausgeführt werden können).
Wenn ich beim Studium des generierten Assemblercodes richtig liege, würde der ideale Zeitplan wie folgt aussehen, wobei die mov Der Befehl dauert 3 Zyklen, die Umschaltlatenz vom Ladebereich zum FP-Bereich für die abhängigen Befehle dauert 2 Zyklen, die FP-Multiplikation dauert 4 Zyklen und die FP-Addition dauert 3 Zyklen. (Beachten Sie, dass die Abhängigkeit von Multiplizieren -> Addieren keine Switch-Latenz verursacht, da die Operationen zur selben Domäne gehören).
Entsprechend der gemessenen Performance (~80% der maximalen theoretischen Performance) ergibt sich ein Overhead von ~3 Instruktionen pro 8 Zyklen.
Ich versuche es entweder:
- Befreien Sie sich von diesem Overhead, oder
- erklären, woher es kommt
Natürlich gibt es das Problem mit Cache-Fehlern und Datenfehlausrichtungen, die die Latenz der Bewegungsanweisungen erhöhen können, aber gibt es noch andere Faktoren, die hier eine Rolle spielen könnten? Wie Registerlesestände oder so etwas?
Ich hoffe, mein Problem ist klar, danke im Voraus für Ihre Antworten!
Update: Die Montage der Innenschleife sieht wie folgt aus:
...
Block 21:
movssl (%rsi,%rdi,4), %xmm4
movssl (%rcx,%rdi,4), %xmm0
movssl 0x4(%rcx,%rdi,4), %xmm1
movssl 0x8(%rcx,%rdi,4), %xmm2
movssl 0xc(%rcx,%rdi,4), %xmm3
inc %rdi
mulss %xmm4, %xmm0
cmp $0x32, %rdi
mulss %xmm4, %xmm1
mulss %xmm4, %xmm2
mulss %xmm3, %xmm4
addss %xmm0, %xmm5
addss %xmm1, %xmm6
addss %xmm2, %xmm7
addss %xmm4, %xmm8
jl 0x401b52 <Block 21>
...
Es hängt wirklich viel vom Compiler (sogar von seiner Version) und den Optimierungsflags ab, die Sie ihm übergeben. Wenn Ihnen die numerische Leistung so wichtig ist, investieren Sie möglicherweise auch Ihre Zeit und Mühe in das Erlernen numerischer Bibliotheken und/oder OpenCL oder CUDA (um die Vorteile von GPGPU zu nutzen). Es gibt auch Überlegungen zum Cache. Das Vorhersagen der tatsächlichen Zeit einer Schleife ist bei gegenwärtigen Prozessoren schwierig.
– Basile Starynkevitch
3. April 2012 um 11:13 Uhr
Ich verstehe nicht, warum Sie denken würden, dass die Schleifensteuerung immer parallel erfolgen kann, während sie tatsächlich eine perfekte Abhängigkeitskette im Out-of-Order-Ausführungsschema erzeugt. Der INC-Befehl modifiziert ein Register. Der CMP-Befehl muss warten, bis INC beendet ist, um den Wert in diesem Register zu prüfen und die Flags entsprechend zu modifizieren. Dann muss der bedingte Sprungbefehl darauf warten, dass CMP die Flags schreibt, um zu entscheiden, ob tatsächlich gesprungen werden soll oder nicht. Da gibt es keine Parallelisierung, fürchte ich. Ganz zu schweigen davon, dass Sprünge Pipeline-Stalls verursachen – der Verzweigungsprädiktor kümmert sich darum.
– Daniel Kamil Kozar
3. April 2012 um 11:13 Uhr
Ganz zu schweigen davon, dass der INC-Befehl auf den vorherigen Befehl warten muss, der die Flags modifiziert hat, um den Zustand des CF-Flags zu bewahren. Abhilfe schaffen Sie einfach, indem Sie das INC durch das entsprechende ADD ersetzen.
– Daniel Kamil Kozar
3. April 2012 um 11:18 Uhr
Kannst du den Rohbau posten?
– Harald
3. April 2012 um 12:14 Uhr
@OrgnlDave: also? Sie werden alle ~4 ms unterbrochen und führen Kernelcode aus, der im schlimmsten Fall einige µs dauert. Dieser Overhead liegt weit unter 20 %, ich wäre überrascht, wenn es tatsächlich > 1 % wäre.
– ninjalj
3. April 2012 um 18:43 Uhr