IACA 란 무엇이며 어떻게 사용합니까?

IACA 란 무엇이며 어떻게 사용합니까?

---

IACA (인텔 아키텍처 코드 분석기) 라는 흥미롭고 강력한 도구를 찾았 지만 이해하는 데 어려움이 있습니다. 그것으로 무엇을 할 수 있고, 그것의 한계는 무엇이며 어떻게 할 수 있습니까?

• C 또는 C ++에서 코드를 분석하는 데 사용합니까?
• x86 어셈블러에서 코드를 분석하는 데 사용합니까?

---

2019-04 : EOL 도달 . 제안 된 대안 : LLVM-MCA

2017-11 : 버전 3.0 출시 (2019-05-18 기준 최신)

2017-03 : 버전 2.3 출시

그것은 무엇입니까 :

IACA (인텔 아키텍처 코드 분석기) 는 최신 인텔 프로세서에서 실행할 때 명령 일정을 정적으로 분석하기 위해 인텔에서 만든 ( 2019 : 수명 종료 ) 프리웨어 폐쇄 소스 정적 분석 도구입니다. 이를 통해 주어진 스 니펫에 대해

• 에서는 처리량 모드 , 최대 처리량 ( 니핏은 가장 안쪽 루프의 몸체로 가정 )
• 에서 대기 모드 , 마지막으로 첫 번째 명령에서 최소 대기 시간.
• 추적 모드 에서는 파이프 라인 단계를 통해 지침의 진행 상황을 인쇄합니다.

최적의 실행 조건을 가정 할 때 (모든 메모리 액세스가 L1 캐시에 도달하고 페이지 오류가 없음).

IACA는 버전 2.3부터 Nehalem, Westmere, Sandy Bridge, Ivy Bridge, Haswell, Broadwell 및 Skylake 프로세서와 버전 3.0부터 Haswell, Broadwell 및 Skylake에 대한 컴퓨팅 스케줄링을 지원합니다.

IACA는 ASCII 텍스트 보고서 및 Graphviz 다이어그램을 생성하는 명령 줄 도구입니다. 버전 2.1 이하에서는 32 비트 및 64 비트 Linux, Mac OS X 및 Windows 및 32 비트 및 64 비트 코드 분석을 지원했습니다. 버전 2.2 이상은 64 비트 OS 및 64 비트 코드 분석 만 지원합니다.

사용 방법:

IACA의 입력이 개 주입 된되는 코드의 컴파일 된 바이너리 마커를 A : 시작 마커 와 끝 마커 . 마커를 사용하면 코드를 실행할 수 없지만 도구가 관련 코드를 빠르게 찾아 분석 할 수 있습니다.

시스템에서 바이너리를 실행할 수있는 기능은 필요하지 않습니다. 사실, IACA에 제공된 바이너리 는 코드에 삽입 된 마커가 있기 때문에 어쨌든 실행할 수 없습니다 . IACA는 분석 할 바이너리를 읽는 기능 만 필요합니다. 따라서 IACA를 사용하여 펜티엄 III 컴퓨터에서 FMA 명령을 사용하는 Haswell 바이너리를 분석 할 수 있습니다.

C / C ++

C 및 C ++에서는을 사용하여 마커 삽입 매크로에 액세스 할 수 있습니다 #include "iacaMarks.h". 여기서는 하위 디렉토리 iacaMarks.h의 도구와 함께 제공되는 헤더입니다 include/.

그런 다음 다음과 같이 가장 안쪽 에있는 관심 루프 또는 관심있는 직선 청크 주위에 마커를 삽입합니다 .

/* C or C++ usage of IACA */

while(cond){
    IACA_START
    /* Loop body */
    /* ... */
}
IACA_END

그런 다음 최적화가 활성화 된 상태에서 애플리케이션이 다시 빌드됩니다 (Visual Studio와 같은 IDE 사용자의 경우 릴리스 모드). 출력은 애플리케이션을 실행할 수 없게 만드는 마크가있는 경우를 제외하고 릴리스 빌드와 모든 측면에서 동일한 바이너리입니다.

IACA는 마크를 과도하게 재정렬하지 않는 컴파일러에 의존합니다. 따라서 이러한 분석 빌드의 경우 가장 안쪽 루프 내에없는 외부 코드를 포함하도록 마크를 재정렬하거나 그 안의 코드를 제외하는 경우 특정 강력한 최적화를 비활성화해야 할 수 있습니다.

어셈블리 (x86)

IACA의 마커는 코드 내의 올바른 위치에 삽입 된 매직 바이트 패턴입니다. 사용시 iacaMarks.hC 또는 C ++에서, 매직 삽입 컴파일러 핸들 정확한 위치 헤더에 의해 지정된 바이트 수. 그러나 조립시 이러한 마크를 수동으로 삽입해야합니다. 따라서 다음을 수행해야합니다.

    ; 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

컴파일러가 이와 동일한 패턴을 달성하는 것은 C / C ++ 프로그래머에게 중요합니다.

출력 내용 :

예를 들어 Haswell 아키텍처 에서 다음 어셈블러 예제를 분석해 보겠습니다 .

.L2:
    vmovaps         ymm1, [rdi+rax] ;L2
    vfmadd231ps     ymm1, ymm2, [rsi+rax] ;L2
    vmovaps         [rdx+rax], ymm1 ; S1
    add             rax, 32         ; ADD
    jne             .L2             ; JMP

.L2레이블 바로 앞에 시작 마커를 추가하고 바로 뒤에 jne끝 마커를 추가합니다. 그런 다음 소프트웨어를 다시 빌드하고 IACA를 호출합니다 (Linux에서는 bin/디렉토리가 경로에 있고 fooIACA 마크를 포함하는 ELF64 객체라고 가정).

iaca.sh -64 -arch HSW -graph insndeps.dot foo

, thus producing an analysis report of the 64-bit binary foo when run on a Haswell processor, and a graph of the instruction dependencies viewable with Graphviz.

The report is printed to standard output (though it may be directed to a file with a -o switch). The report given for the above snippet is:

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

The tool helpfully points out that currently, the bottleneck is the Haswell frontend and Port 2 and 3's AGU. This example allows us to diagnose the problem as the store not being processed by Port 7, and take remedial action.

Limitations:

IACA does not support a certain few instructions, which are ignored in the analysis. It does not support processors older than Nehalem and does not support non-innermost loops in throughput mode (having no ability to guess which branch is taken how often and in what pattern).

ReferenceURL : https://stackoverflow.com/questions/26021337/what-is-iaca-and-how-do-i-use-it