Ich habe dieses interessante und leistungsstarke Tool namens gefunden IACA (der Intel Architecture Code Analyzer), aber ich habe Schwierigkeiten, es zu verstehen. Was kann ich damit machen, wo liegen seine Grenzen und wie kann ich:
Ich werde nicht existieren Ich werde nicht existieren
2019-04: Erreichten Ende. Vorgeschlagene Alternative: LLVM-MCA
2017-11: Ausführung 3.0 herrausgebracht (spätestens vom 18.05.2019)
2017-03: Ausführung 2.3 herrausgebracht
IACA (der Intel Architecture Code Analyzer) ist ein (2019: Lebensende) Freeware, statisches Closed-Source-Analysetool von Intel zur statischen Analyse der Planung von Anweisungen bei der Ausführung durch moderne Intel-Prozessoren. Dies ermöglicht es, für ein bestimmtes Snippet zu berechnen,
wenn optimale Ausführungsbedingungen angenommen werden (alle Speicherzugriffe treffen auf den L1-Cache und es gibt keine Seitenfehler).
IACA unterstützt Rechenzeitpläne für Nehalem-, Westmere-, Sandy Bridge-, Ivy Bridge-, Haswell-, Broadwell- und Skylake-Prozessoren ab Version 2.3 und Haswell, Broadwell und Skylake ab Version 3.0.
IACA ist ein Befehlszeilentool, das ASCII-Textberichte und Graphviz-Diagramme erstellt. Die Versionen 2.1 und darunter unterstützten 32- und 64-Bit-Linux, Mac OS X und Windows sowie die Analyse von 32-Bit- und 64-Bit-Code; Version 2.2 und höher unterstützen nur 64-Bit-Betriebssysteme und die Analyse von 64-Bit-Code.
Die Eingabe der IACA ist eine kompilierte Binärdatei Ihres Codes, in die zwei eingefügt wurden Markierungen: ein Startmarkierung und ein Endmarkierung. Die Markierungen machen den Code unausführbar, ermöglichen dem Tool jedoch, die relevanten Codeteile schnell zu finden und zu analysieren.
Sie müssen die Binärdatei nicht auf Ihrem System ausführen können; Tatsächlich wird die Binärdatei an die IACA geliefert kippen trotzdem ausgeführt werden, da die eingefügten Markierungen im Code vorhanden sind. IACA erfordert lediglich die Fähigkeit, die zu analysierende Binärdatei zu lesen. Somit ist es unter Verwendung von IACA möglich, eine Haswell-Binärdatei unter Verwendung von FMA-Anweisungen auf einer Pentium-III-Maschine zu analysieren.
In C und C++ erhält man Zugriff auf Markierungs-injizierende Makros mit #include "iacaMarks.h"wo iacaMarks.h ist ein Header, der mit dem Tool in der ausgeliefert wird include/ Unterverzeichnis.
Man fügt dann die Markierungen um die herum ein innerste interessierende Schleife oder das interessierende geradlinige Stück wie folgt:
/* C or C++ usage of IACA */
while(cond){
IACA_START
/* Loop body */
/* ... */
}
IACA_END
Die Anwendung wird dann neu erstellt, wie sie es sonst mit aktivierten Optimierungen tun würde (im Release-Modus für Benutzer von IDEs wie Visual Studio). Die Ausgabe ist eine Binärdatei, die in jeder Hinsicht mit dem Release-Build identisch ist, außer dass die Markierungen vorhanden sind, die die Anwendung nicht lauffähig machen.
Die IACA verlässt sich darauf, dass der Compiler die Markierungen nicht übermäßig neu ordnet; Daher müssen für solche Analyse-Builds möglicherweise bestimmte leistungsstarke Optimierungen deaktiviert werden, wenn sie die Markierungen neu anordnen, um irrelevanten Code einzuschließen, der sich nicht in der innersten Schleife befindet, oder Code darin auszuschließen.
Die Markierungen der IACA sind magische Bytemuster, die an der richtigen Stelle innerhalb des Codes eingefügt werden. Beim Benutzen iacaMarks.h In C oder C++ kümmert sich der Compiler um das Einfügen der magischen Bytes, die durch den Header an der richtigen Stelle angegeben sind. Bei der Montage müssen Sie diese Markierungen jedoch manuell einfügen. Also muss man folgendes tun:
; NASM usage of IACA
mov ebx, 111 ; Start marker bytes
db 0x64, 0x67, 0x90 ; Start marker bytes
.innermostlooplabel:
; Loop body
; ...
jne .innermostlooplabel ; Conditional branch backwards to top of loop
mov ebx, 222 ; End marker bytes
db 0x64, 0x67, 0x90 ; End marker bytes
Für C/C++-Programmierer ist es entscheidend, dass der Compiler dasselbe Muster erreicht.
Lassen Sie uns als Beispiel das folgende Assembler-Beispiel auf der Haswell-Architektur analysieren:
.L2:
vmovaps ymm1, [rdi+rax] ;L2
vfmadd231ps ymm1, ymm2, [rsi+rax] ;L2
vmovaps [rdx+rax], ymm1 ; S1
add rax, 32 ; ADD
jne .L2 ; JMP
Wir fügen unmittelbar vor dem hinzu .L2 Beschriften Sie die Startmarkierung und unmittelbar danach jne die Endmarkierung. Wir erstellen dann die Software neu und rufen IACA so auf (Unter Linux wird davon ausgegangen, dass die bin/ Verzeichnis im Pfad sein, und foo um ein ELF64-Objekt zu sein, das die IACA-Marken enthält):
iaca.sh -64 -arch HSW -graph insndeps.dot foo
wodurch ein Analysebericht der 64-Bit-Binärdatei erstellt wird foo bei Ausführung auf einem Haswell-Prozessor und ein Diagramm der Befehlsabhängigkeiten, das mit Graphviz angezeigt werden kann.
Der Bericht wird auf der Standardausgabe gedruckt (obwohl er möglicherweise in eine Datei mit einer -o schalten). Der Bericht für das obige Snippet lautet:
Intel(R) Architecture Code Analyzer Version - 2.1
Analyzed File - ../../../tests_fma
Binary Format - 64Bit
Architecture - HSW
Analysis Type - Throughput
Throughput Analysis Report
--------------------------
Block Throughput: 1.55 Cycles Throughput Bottleneck: FrontEnd, PORT2_AGU, PORT3_AGU
Port Binding In Cycles Per Iteration:
---------------------------------------------------------------------------------------
| Port | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 |
---------------------------------------------------------------------------------------
| Cycles | 0.5 0.0 | 0.5 | 1.5 1.0 | 1.5 1.0 | 1.0 | 0.0 | 1.0 | 0.0 |
---------------------------------------------------------------------------------------
N - port number or number of cycles resource conflict caused delay, DV - Divider pipe (on port 0)
D - Data fetch pipe (on ports 2 and 3), CP - on a critical path
F - Macro Fusion with the previous instruction occurred
* - instruction micro-ops not bound to a port
^ - Micro Fusion happened
# - ESP Tracking sync uop was issued
@ - SSE instruction followed an AVX256 instruction, dozens of cycles penalty is expected
! - instruction not supported, was not accounted in Analysis
| Num Of | Ports pressure in cycles | |
| Uops | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 | |
---------------------------------------------------------------------------------
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [rdi+rax*1]
| 2 | 0.5 | 0.5 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [rsi+rax*1]
| 2 | | | 0.5 | 0.5 | 1.0 | | | | CP | vmovaps ymmword ptr [rdx+rax*1], ymm1
| 1 | | | | | | | 1.0 | | | add rax, 0x20
| 0F | | | | | | | | | | jnz 0xffffffffffffffec
Total Num Of Uops: 6
Das Tool weist hilfreich darauf hin, dass derzeit das Haswell-Frontend und die AGU von Port 2 und 3 der Engpass sind. Mit diesem Beispiel können wir das Problem diagnostizieren, dass der Speicher nicht von Port 7 verarbeitet wird, und Abhilfemaßnahmen ergreifen.
Die IACA unterstützt einige wenige Anweisungen nicht, die bei der Analyse ignoriert werden. Es unterstützt keine Prozessoren, die älter als Nehalem sind, und unterstützt keine nicht innersten Schleifen im Durchsatzmodus (keine Fähigkeit zu erraten, welcher Zweig wie oft und in welchem Muster genommen wird).
Verlangt die IACA, dass Sie die Hardware haben? Ich meine, können Sie zB für fma3 kompilieren und es mit IACA auf einem Core2-System mit nur SSE2 testen? Und das Gegenteil. Wenn ich nur SSE2-Code testen möchte, kann ich dies mit einem Haswell-System tun? Wenn die IACA Zähler ausliest, glaube ich nicht, dass dies möglich wäre. Aber da IACA keinen Root/Admin benötigt, gehe ich davon aus, dass dies bedeutet, dass die Hardware nicht erforderlich ist.
– Z-Boson
24. September 2014 um 16:18 Uhr
@Zboson benötigt keine Hardware; Es ist ein statisches Analysetool und führt als solches den Code nie wirklich aus. Die einzige wirkliche Anforderung ist eine zu analysierende Binärdatei; Sie müssen nicht einmal in der Lage sein, diese Binärdatei auszuführen, um sie zu analysieren. Tatsächlich soll die Binärdatei analysiert werden kippen wegen der injizierten Marker trotzdem ausgeführt werden.
– Ich werde nicht existieren Ich werde nicht existieren
24. September 2014 um 16:25 Uhr
Du hörst nicht zu, was ich sage. ich suche nach iacaMarks.h! Sie beziehen sich auf Definitionen, die für C/C++ gelten. Mit NASM geht das nicht. Schauen Sie sich das Ende der Kopfzeile an. Es gibt einen Kommentarblock, der mit “/**************** asm *****************” beginnt. Der Assemblercode im Block verwenden Sie mit NASM.
– Z-Boson
25. September 2014 um 7:16 Uhr
Fun-Tool :-} Ich habe einen inneren Assembler-Block mit einigen internen Verzweigungen zwei Ausgänge. Ich platziere die Startmarkierung oben und die Endmarkierungen an beide Ausgänge. Wenn ich es starte (es funktioniert! schön!), wählt es aus ein der beiden Ausgänge und zeigt mir ein Ergebnis für den gewählten Pfad. a) es scheint Code innerhalb des Blocks aufzunehmen, der bedingt, aber selten ausgeführt wird; wie bekomme ich es dazu, das zu ignorieren, und b) wie bekomme ich es hin, beide Pfade zu analysieren? (Ich werde versuchen, die Markierung auf einem Zweig zu löschen, aber ich mache mir Sorgen, dass das Tool diesem Zweig in den unendlichen Vorrat an Code folgt, zu dem er führt …
– Ira Baxter
25. September 2014 um 9:24 Uhr
@halivingston Moderne Intel-CPUs sind nicht nur gepipelinet (das Konzept, mehrere Anweisungen zu haben in verschiedenen Stadien der Fertigstellung gleichzeitig ausführen), sondern auch superskalar (das Konzept der Ausführung mehrerer Anweisungen im gleichen Fertigstellungsstadium). Die (mehreren) Anweisungen, die ein Intel-Prozessor abruft, werden dann in 0+ Mikrooperationen decodiert, und diese werden an einen oder mehrere Ports gesendet, die sie verarbeiten können. Gut abgestimmter Code stellt sicher, dass die verwendeten Anweisungen die Ports gleichmäßig sättigen, sodass alle produktiv sind.
– Ich werde nicht existieren Ich werde nicht existieren
28. September 2015 um 22:34 Uhr
