PIRA
v0.6.0
성능 계측 개선 자동화 프레임 워크 PIRA는 Score-P를 사용할 때 알 수 없는 코드 기반에 대한 합리적인 성능 측정을 생성하는 시간 소모적인 작업에 접근합니다. 자세한 내용은 다음 문서를 참조하세요.
| [PI18] | 얀 패트릭 레어, 알렉산더 큉, 크리스티안 비쇼프. PIRA: 성능 계측 개선 자동화. 소프트웨어 엔지니어링 및 병렬 컴퓨팅 시스템(AI-SEPS)을 위한 인공 지능 및 경험적 방법에 관한 제5회 ACM SIGPLAN 국제 워크숍, 1~10페이지, ACM, 2018. |
| [PI19] | 얀 패트릭 레르, 알렉산드루 칼로토이우, 크리스티안 비쇼프, 펠릭스 볼프. 경험적 성능 모델링을 위한 자동 계측 개선. 프로그래밍 및 성능 시각화 도구(ProTools)에 관한 국제 워크숍 , 40-47페이지, IEEE, 2019. |
| [PI21] | 피터 아르츠, 야닉 피슐러, 얀 패트릭 레어, 크리스티안 비쇼프. MPI 애플리케이션에서 자동 낮은 오버헤드 부하 불균형 감지. Euro-Par 2021: 병렬 처리. 컴퓨터 과학 강의 노트, 12820권 , 19-34페이지, Springer, 2021. |
PIRA는 다음 4단계를 실행합니다(2~4단계가 반복됨).
PIRA는 자동으로 생성된 래퍼를 통한 MPI 함수의 런타임 필터링을 포함하여 함수의 컴파일 타임 및 런타임 필터링을 모두 지원합니다. 컴파일 타임 필터링에서는 원하는 기능만 컴파일 타임에 계측되므로 전반적인 측정 영향이 크게 줄어듭니다. 대조적으로, 런타임 필터링에서 컴파일러는 계측 후크를 대상 애플리케이션의 모든 기능에 삽입하고 필터링은 런타임에 발생합니다.
PIRA에는 CMake(>=3.16), Clang/LLVM 10, Python 3, Qt5 및 OpenMPI 4가 필요합니다. 이(또는 MetaCG)는 추가로 다운로드(및 빌드)됩니다.
인터넷에 접속할 수 없는 환경에서 PIRA를 구축하려면 resources/build_submodules.sh 스크립트를 확인하고 필요에 맞게 조정하세요.
PIRA 저장소를 복제합니다.
$> git clone https://github.com/tudasc/pira
$> cd pira
둘째, 제공된 스크립트를 사용하여 종속 하위 모듈을 빌드하거나 다양한 옵션에 대한 값을 전달합니다(사용 가능한 옵션은 -h 통해 사용법 정보 참조). 다운로드하고 빌드한 모든 파일은 external/src/ 에 배치되고 모든 설치 파일은 external/install/ 에 배치됩니다. PIRA의 외부 컴파일을 위해 생성될 컴파일 프로세스 수를 지정합니다. 스크립트는 PIRA의 종속성을 기본 버전으로 다운로드합니다. 이러한 버전은 CI에서도 테스트되었으며 작동할 것으로 예상됩니다.
$> cd resources
$> ./build_submodules.sh -p <ncores>
마지막 단계로 빌드 스크립트는 하위 모듈의 설치 경로를 resources/setup_paths.sh 파일에 기록합니다. PIRA를 다시 빌드하려면 이 파일을 git restore 것을 기억하세요.
또한 PIRA를 빌드하고 사용해 볼 수 있는 (실험적인) Dockerfile 제공합니다.
$> podman build -t pira:master -f docker/Dockerfile .
통합 테스트 등 컨테이너 내부에서 실행하는 경우 다음과 같이 스크립트를 호출하세요.
$> cd resources
$> . setup_paths.sh
$> cd ../test/integration/GameOfLife # Example test case
# By default PIRA will look into $HOME/.local, which is not currently existent in the docker
# XDG_DATA_HOME signals where to put the profiling data PIRA generates
$> XDG_DATA_HOME=/tmp ./run.sh
PIRA 사용 방법에 대한 전체 예제를 보려면 /test/integration/* 폴더에서 run.sh 스크립트를 확인하세요. 잠재적으로 좋은 출발점은 GameOfLife 폴더와 해당 테스트 사례입니다.
먼저 resources 폴더에서 스크립트를 소싱하여 필요한 경로를 설정합니다.
$> cd resources/
$> . setup_paths.sh
그런 다음 ./test/integration/GameOfLife 폴더에 제공된 run.sh 스크립트를 사용하여 Conway Game of Life의 매우 간단한 구현에서 PIRA의 예제 애플리케이션을 실행할 수 있습니다.
$> cd ./test/integration/GameOfLife
$> ./run.sh
스크립트는 처음부터 필요한 모든 단계, 즉 새 대상 코드에 대한 모든 구성 요소를 준비하여 최종적으로 PIRA를 호출하는 단계를 수행합니다. 후속 섹션에서는 해당 단계를 더 자세히 설명합니다. 단계는 다음과 같습니다.
config 구성 파일의 경로(필수 인수)--config-version [1,2] PIRA 구성 버전은 2가 기본값이며 권장됩니다. 1은 더 이상 사용되지 않습니다.--runtime-filter 런타임 필터링을 사용하며 기본값은 false입니다. 컴파일 시간 필터링에서는 함수가 컴파일 시간에 계측되지 않으므로 전체 측정 영향이 크게 줄어들지만 각 반복마다 대상을 다시 작성해야 합니다. 이와 대조적으로 런타임 필터링을 사용하면 컴파일러는 대상 애플리케이션의 모든 기능에 계측 후크를 삽입합니다.--iterations [number] Pira 반복 횟수, 기본값은 3입니다.--repetitions [number] 측정 반복 횟수, 기본값은 3입니다.--tape (다소 광범위한) 로깅 테이프를 기록해야 하는 위치입니다.--extrap-dir Extra-p 폴더 구조가 배치되는 기본 디렉터리입니다.--extrap-prefix Extra-P 접두사는 일련의 문자여야 합니다.--version PIRA 설치 버전 번호를 인쇄합니다.--analysis-parameters PGIS에 대한 분석 매개변수가 포함된 구성 파일의 경로입니다. Extra-P 및 LIDe 모드 모두에 필요합니다.--slurm-config [path to slurm cfg file] slurm 클러스터에서 대상 코드 실행을 활성화합니다. slurm 구성 파일이 필요합니다. 자세한 내용은 이 섹션을 참조하세요. --hybrid-filter-iters [number] [숫자] 반복 후 다시 컴파일하고 그 사이에 런타임 필터링을 사용합니다.--export 생성된 Extra-P 모델과 데이터 세트 크기를 대상의 IPCG 파일에 첨부합니다.--export-runtime-only --export 필요; 모든 반복의 중간 런타임 값만 함수에 연결합니다. Extra-P를 사용하지 않는 경우에만 사용할 수 있습니다.--load-imbalance-detection [path to cfg file] 로드 불균형 감지 모드를 활성화하고 구성합니다. 자세한 내용은 이 섹션을 읽어보세요. PIRA는 초기 계측을 구성하고 반복적 개선 중에 계측에 추가할 기능을 결정하기 위해 소스 코드 정보를 사용합니다. 필요한 모든 정보를 수집하고 해당 정보를 .json 파일로 출력하는 Clang 기반 호출 그래프 도구를 제공합니다. 하위 디렉토리 ./extern/src/metacg/cgcollector 에서 cgcollector 도구를 찾을 수 있습니다. PIRA에서는 콜그래프 파일이 버전 2(MetaCG v2)의 MetaCG 파일 형식이어야 합니다.
CGCollector 및 해당 구성 요소에 대한 자세한 내용은 MetaCG 설명서에서 찾을 수 있습니다.
CGCollector 적용은 일반적으로 두 단계로 이루어집니다.
처음에는 프로젝트의 모든 소스 파일에서 cgc 호출됩니다. 예:
for f in $(find ./src -type f ( -iname "*.c" -o -iname "*.cpp" ) ); do
cgc --metacg-format-version=2 $f
done
그런 다음 1단계에서 생성된 .ipcg 파일은 cgmerge 사용하여 일반 파일로 병합됩니다.
"null" 문자열만 포함하는 출력 파일을 만듭니다. 2. 프로젝트에 두 개 이상의 main 기능이 포함된 경우 해당 파일을 올바른 main 기능과만 병합하십시오. echo "null" > $IPCG_FILENAME
find ./src -name "*.ipcg" -exec cgmerge $IPCG_FILENAME $IPCG_FILENAME {} +
최종 그래프는 callgraph-analyzer 디렉토리에 배치되어야 합니다. 현재 CG 분석에는 PGIS가 사용되므로 생성된 전체 프로그램 파일이 PGIS 디렉터리에 복사됩니다. 현재 PGIS 디렉터리의 파일 이름은 item_flavor.mcg 패턴을 따르는 것이 중요합니다. 항목은 대상 애플리케이션을 나타냅니다. 맛과 품목이라는 용어에 대해서는 다음 섹션에서 자세히 알아보세요.
# Assuming $PIRA holds the top-level PIRA directory
$> cp my-app.mcg $PIRA/extern/install/pgis/bin/item_flavor.mcg
PIRA 구성에는 PIRA가 자동 프로세스를 실행하는 데 필요한 모든 정보가 포함되어 있습니다. 구성 파일에 지정해야 하는 다양한 디렉터리는 절대 경로이거나 pira 실행 경로에 대한 상대 경로 일 수 있습니다. 경로에는 환경 변수(예: $HOME 가 포함될 수 있습니다. 예제는 ./test/integration/GameOfLife 의 GameOfLife 예제에서 가져왔습니다.
사용자는 이후에 정의된 항목을 찾을 디렉토리를 지정합니다. 예에서 디렉토리는 ./gol/serial_non_template 입니다. 이러한 디렉토리에는 '%' 기호를 사용하여 역참조되는 별칭이 제공됩니다. PIRA의 항목은 특정 방식으로 구축된 대상 애플리케이션이므로 builds 아래의 구성에서 그룹화됩니다.
{
"builds": {
"%gol": {
"items": {
"gol": {
...
}
}
}
}
"directories": {
"gol": "./gol/serial_non_template"
}
}
모든 항목은 어떤 분석기를 사용해야 하는지 지정합니다. 기본 분석기는 PIRA와 함께 제공되며 소스는 각각 ./extern/src/metacg/pgis 또는 ./extern/install/pgis/bin 설치에서 찾을 수 있습니다. 분석기는 계측 개선을 담당하므로 PIRA 프레임워크의 필수 부분입니다.
argmap 필드는 성능 실험을 실행할 때 대상 애플리케이션에 전달되는 다양한 인수를 지정합니다. 인수가 대상 응용 프로그램에 전달되는 방법은 다양한 매퍼 에 의해 정의됩니다. 예제에서는 목록에 지정된 순서대로 size라는 매개변수의 값을 반복하는 선형 매퍼가 사용됩니다.
"argmap": {
"mapper": "Linear",
"size": [50, 80, 110, 150, 300, 500]
}
큐브 필드는 PIRA가 획득한 Score-P 프로필을 저장해야 하는 위치입니다. 해당 위치에 디렉토리 트리를 구성하므로 사용자는 PIRA가 완료된 후 간단히 해당 위치(예: /tmp/pira) 를 전달하여 Extra-P 모델링 도구를 쉽게 호출할 수도 있습니다.
"cubes": "/tmp/pira"
플레이버 필드는 대상 애플리케이션이 다양한 플레이버 로 구축될 수 있으므로 또 다른 수준의 구별을 추가합니다. 예를 들어 대상 응용 프로그램이 연결해야 하는 다른 수학 라이브러리를 지정하는 것입니다.
마지막으로 functors 디렉터리는 PIRA에게 대상 애플리케이션을 빌드, 실행 및 분석하는 방법을 궁극적으로 알려주는 사용자 제공 Python 함수를 찾는 위치를 PIRA에 지정합니다. 예제에서 PIRA는 구성 위치와 관련하여 functors 라는 디렉터리를 가리킵니다.
"flavors": [
"ct"
],
"functors": "./functors",
"mode": "CT"
이 버전의 PIRA에서는 모드 필드가 무시됩니다.
현재 사용자는 다섯 가지 다른 펑터를 구현해야 합니다.
analyze_<ITEM>_<FLAVOR>.py : 분석기를 호출합니다.clean_<ITEM>_<FLAVOR>.py : 빌드 디렉터리를 정리합니다.<ITEM>_<FLAVOR>.py : 계측 버전을 빌드합니다.no_instr_<ITEM>_<FLAVOR>.py : 바닐라 버전을 빌드합니다.runner_<ITEM>_<FLAVOR>.py : 대상 애플리케이션을 실행합니다. Functor는 일반적으로 활성 및 수동이라는 두 가지 호출 모드를 지원합니다. 펑터는 get_method() 함수가 반환한 사전에서 해당 값을 True 로 설정하여 PIRA에 사용하는 모드를 알려줍니다.
활성 모드에서 펑터 자체는 예를 들어 소프트웨어 빌드에 필요한 명령을 호출합니다. 호출되면 펑터에는 현재 디렉터리와 하위 프로세스 셸의 인스턴스 등을 보유하는 **kwargs 매개 변수가 전달됩니다.
수동 모드는 실행할 명령만 반환합니다. 예를 들어 항목의 최상위 디렉터리에서 간단한 Makefile을 호출하는 문자열 make 반환합니다. 또한 CXXFLAGS 또는 추가 링커 플래그에 추가하는 데 필요한 사전 정의된 값과 같은 특정 정보를 보유하는 kwargs 매개변수가 전달됩니다. 수동 펑터의 예는 examples 및 test 디렉토리에서 찾을 수 있습니다. 현재 구현된 모든 펑터는 패시브 모드를 사용합니다.
PIRA는 모든 펑터에 다음 키워드 인수를 전달합니다. 또한 다양한 PIRA 구성 요소가 추가 인수를 전달할 수도 있습니다.
중요 : 이제 자체 Score-P 버전을 출시합니다. 따라서 더 이상 PIRA에서 컴파일 명령을 조정할 필요가 없습니다. 다양한 정보의 사용 예를 보려면 test/integration/AMG2013 의 펑터를 확인하세요.
현재 모든 펑터에 정보가 전달되지 않습니다.
[0] 첫 번째 인수에 액세스하고 [1] 두 번째 인수에 액세스하는 식입니다..so 파일의 경로입니다(MPI 필터링에 중요). 일부 분석 모드에는 추가 매개변수가 필요합니다. 특히 PIRA LIDe(아래 참조) 및 Extra-P 모델링 분석에는 사용자 제공 매개변수가 필요합니다. --analysis-parameters -switch를 사용하여 JSON 파일을 생성하고 PIRA에 대한 경로를 제공합니다. 다음 예에는 Extra-P 모델링 모드에 대한 매개변수가 포함되어 있습니다. 여러 Extra-P 모델을 집계하는 데 사용할 수 있는 전략(함수가 다른 컨텍스트에서 호출되는 경우)은 FirstModel , Sum , Average , Maximum 입니다.
{
"Modeling": {
"extrapolationThreshold": 2.1,
"statementThreshold": 200,
"modelAggregationStrategy": "Sum"
}
}
부하 불균형 감지 기능에 대한 자세한 내용은 [PI21]을 참조하세요. --load-imbalance-detection -매개변수를 사용하여 구성 파일 경로와 함께 PIRA 호출을 제공합니다. 이 JSON 파일은 다음 구조를 가져야 합니다.
{
"metricType": "ImbalancePercentage",
"imbalanceThreshold": 0.05,
"relevanceThreshold": 0.05,
"contextStrategy": "None",
"contextStepCount": 5,
"childRelevanceStrategy": "RelativeToMain",
"childConstantThreshold": 1,
"childFraction": 0.001
}
SLURM 워크로드 관리자가 있는 클러스터에서 PIRA를 실행하려면 --slurm-config 플래그를 사용하여 호출하십시오. 배치 시스템 구성 파일의 경로를 제공하십시오. _Slurm ( test/integration/*_Slurm/ )이 붙은 통합 테스트를 참조하세요. PIRA는 현재 SLURM 워크로드 관리자가 포함된 배치 시스템을 지원합니다. PIRA는 슬럼 클러스터에서 찾을 수 있는 module 시스템의 사용을 지원합니다.
배치 시스템 구성 파일은 JSON 파일로, 다음과 같이 구성됩니다.
{
"general": {
"backend": "slurm",
"interface": "pyslurm",
"timings": "subprocess"
},
"module-loads": [
{
"name": "gcc",
"version": "8.5"
},
{
"name": "llvm",
"version": "10.0.0",
"depends-on": [
{
"name": "gcc",
"version": "8.5"
}
]
}
],
"batch-settings": {
"time_str": "00:10:00",
"mem_per_cpu": 3800,
"number_of_tasks": 1,
"partition": null,
"reservation": null,
"account": "your_account_here",
"cpus_per_task": 96
}
}
고장:
general 섹션: PIRA가 배치 시스템에서 코드를 실행하는 방식을 선택할 수 있습니다. 이 섹션의 모든 옵션은 선택 사항이므로 기본값을 사용해도 괜찮다면 전체 섹션을 생략할 수 있습니다.backend : 사용할 워크로드 관리자입니다. 선택 사항: slurm , slurm 워크로드 관리자용. 기본값: slurm , 따라서 선택 사항입니다.interface : PIRA가 배치 시스템 관리자와 상호 작용하는 방식입니다. SLURM 백엔드의 경우 다음과 같습니다. pyslurm , PySlurm 사용(이를 위해서는 PySlurm을 설치해야 합니다. 이 섹션을 참조하세요. sbatch-wait , --wait 플래그와 함께 표준 sbatch 사용하고, os , 표준 sbatch 및 squeue 상호 작용 호출용). 기본값: pyslurm , 따라서 선택 사항입니다.timings : 대상 코드의 타이밍을 어떻게 설정해야 하는지입니다. 선택사항: subprocess , 하위 프로세스에서 Python 래퍼 및 os.times 사용하여 타이밍을 지정합니다(로컬에서 실행하는 경우 PIRA가 수행하는 것과 정확히 동일함). os , /usr/bin/time 사용합니다. 기본값: subprocess , 따라서 선택 사항입니다.force-sequential : 기본값은 false . PIRA/배치 시스템이 모든 실행을 순차적으로 수행하도록 하려면 true 로 설정합니다(한 번에 하나의 대상 코드만 실행). 이는 PIRA가 배치 시스템이 반복을 실행하고 실험을 순차적으로 확장하는 다양한 작업을 실행하도록 관리한다는 것을 의미합니다. false 로 설정/왼쪽으로 설정하면 PIRA는 배치 시스템에 모든 반복 내에서 가능한 한 많은 실행을 병렬로 수행하도록 지시합니다.module-loads 섹션: 현재 PIRA에서 사용되지 않으며 작업이 진행 중입니다! 현재 PIRA를 시작하기 전에 모든 모듈을 수동으로 로드해야 합니다! module 시스템과 함께 로드되어야 하는 모듈을 의미합니다. 이를 위해서는 하나가 있어야 합니다(PIRA에서 module load 및 module purge 명령을 사용할 수 있음). module 시스템이 없거나 사용하고 싶지 않은 경우 이 섹션을 완전히 생략하거나 "module-loads": null 설정하세요. PIRA가 로드해야 하는 모듈을 지정하려면 위의 예와 같이 모듈 목록을 지정합니다.name 있어야 합니다.version 선택 사항이며, 제공되지 않은 경우 module 시스템이 기본 모듈 버전으로 로드하는 항목에 따라 달라집니다. 항상 버전을 명시적으로 제공하는 것이 좋습니다.depends-on 도 선택 사항입니다. 이 모듈이 의존하는 모듈 목록을 제공하십시오. 이러한 모듈에는 name 있어야 하며 선택적으로 version 제공될 수 있습니다. 여기에 정의된 종속성은 PIRA에서 모듈을 로드해야 하는 순서를 결정하는 데 사용됩니다.null 로 설정하면 이 모듈에는 종속성이 없는 것으로 간주됩니다.depends-on 지정되지 않은 경우 PIRA는 구성 파일에 지정된 순서대로 모듈을 로드하려고 시도합니다.batch-setting 섹션: 배치 시스템에 대한 실제 하드웨어 및 작업 옵션입니다. 섹션의 일부 옵션은 필수이므로 이 섹션을 생략할 수 없습니다.time : sbatch --time 옵션은 필수입니다.mem-per-cpu : sbatch --mem-per-cpu 옵션은 필수입니다.ntasks : sbatch --ntasks 옵션은 필수입니다.partition , reservation , account (모두 기본값은 null = 제공되지 않음), cpus-per-task (기본값은 4 ), exclusive (기본값은 true , pyslurm 에서는 지원되지 않음) 및 cpu-freq (기본값은 null ).sbatch 옵션이 있습니다. 이는 PIRA가 내부적으로 사용하는 일부 옵션(예: --array 옵션)으로 인해 반복을 작업 배열에 매핑하기 때문입니다. 클러스터에 설치하는 PySlurm 버전과 방법은 SLURM 버전 및 SLURM 설치에 따라 크게 달라집니다. PIRA를 사용한 pyslurm의 설치 및 패키징 솔루션이 진행 중입니다. README를 참조하세요. 다음 중 일부를 시도해 볼 수 있습니다.
include 및 lib 디렉토리를 찾으십시오.python3 setup.py build --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/includepython3 setup.py install --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/include .
