PIRA
v0.6.0
Среда автоматизации усовершенствования инструментов производительности PIRA подходит к трудоемкой задаче создания разумного измерения производительности для неизвестной базы кода при использовании Score-P. Для получения дополнительной информации, пожалуйста, смотрите наши статьи:
| [PI18] | Ян-Патрик Лер, Александр Хюк, Кристиан Бишоф. ПИРА: автоматизация доработки контрольно-измерительных приборов. На 5-м международном семинаре ACM SIGPLAN по искусственному интеллекту и эмпирическим методам разработки программного обеспечения и системам параллельных вычислений (AI-SEPS) , страницы 1–10, ACM, 2018. |
| [PI19] | Ян-Патрик Лер, Александру Калотойу, Кристиан Бишоф, Феликс Вольф. Автоматическое усовершенствование инструментов для эмпирического моделирования производительности. На Международном семинаре по инструментам программирования и визуализации производительности (ProTools) , страницы 40–47, IEEE, 2019 г. |
| [PI21] | Петер Арцт, Янник Фишлер, Ян-Патрик Лер, Кристиан Бишоф. Автоматическое обнаружение дисбаланса нагрузки с низкими издержками в приложениях MPI. В Euro-Par 2021: параллельная обработка. Конспекты лекций по информатике, том 12820 , страницы 19–34, Springer, 2021. |
PIRA выполняет следующие четыре этапа (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 этого файла.
Мы также предоставляем (экспериментальный) Dockerfile для сборки PIRA и его тестирования.
$> 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 можно найти в сценариях run.sh в папке /test/integration/* . Потенциально хорошей отправной точкой является папка GameOfLife и ее тестовый пример.
Сначала настройте необходимые пути, поместив скрипт в папку resources .
$> cd resources/
$> . setup_paths.sh
Затем вы можете запустить пример приложения PIRA на очень простой реализации «Игры жизни» Конвея, используя предоставленный сценарий run.sh в папке ./test/integration/GameOfLife .
$> 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 использует информацию исходного кода для создания исходного инструментария и принятия решения о том, какие функции добавить к инструменту во время итеративного уточнения. Он предоставляет инструмент графа вызовов на основе Clang, который собирает всю необходимую информацию и выводит ее в файл .json . Вы можете найти инструмент cgcollector в подкаталоге ./extern/src/metacg/cgcollector . PIRA требует, чтобы файл графа вызовов был в формате файла MetaCG версии 2 (MetaCG v2).
Дополнительную информацию о CGCollector и его компонентах можно найти в документации MetaCG.
Применение CGCollector обычно происходит в два этапа.
Сначала cgc вызывается для каждого исходного файла проекта. например:
for f in $(find ./src -type f ( -iname "*.c" -o -iname "*.cpp" ) ); do
cgc --metacg-format-version=2 $f
done
Файлы .ipcg , созданные на шаге 1, затем объединяются в общий файл с помощью cgmerge .
"null" 2. Если ваш проект содержит более одной main функции, объедините файл только с правильной main функцией. echo "null" > $IPCG_FILENAME
find ./src -name "*.ipcg" -exec cgmerge $IPCG_FILENAME $IPCG_FILENAME {} +
Итоговый граф необходимо поместить в директорию графа-анализатора вызовов. Поскольку в настоящее время для анализа компьютерной графики используется 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 . Примеры взяты из примера GameOfLife в ./test/integration/GameOfLife .
Пользователь указывает: каталог , в котором искать впоследствии определенные элементы , в примере каталог — ./gol/serial_non_template . Этим каталогам присваиваются псевдонимы, которые разыменовываются с помощью знака «%». Элемент в PIRA — это целевое приложение, созданное определенным образом, поэтому оно сгруппировано в конфигурации в разделе сборки .
{
"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 также легко вызвать инструмент моделирования Extra-P, просто передав ему соответствующее местоположение, т. е. /tmp/pira в примере.
"cubes": "/tmp/pira"
Поле «варианты» добавляет еще один уровень возможного различия, поскольку целевые приложения могут быть созданы в разных вариантах . Примером может быть указание различных математических библиотек, с которыми должно связываться целевое приложение.
Наконец, каталог функторов указывает PIRA на место, где он ищет предоставленные пользователем функции Python, которые в конечном итоге сообщают PIRA, как создавать, запускать и анализировать целевое приложение. В этом примере PIRA указывает на каталог, называемый функторами, относительно местоположения конфигурации.
"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 : запускает целевое приложение. Функторы, как правило, поддерживают два режима вызова: активный и пассивный . Функтор сообщает PIRA, какой режим он использует, устанавливая соответствующее значение True в словаре, возвращаемом функцией get_method() .
В активном режиме функтор сам вызывает необходимые команды, например, для сборки программного обеспечения. При вызове функтору передается параметр **kwargs , содержащий, например, текущий каталог и экземпляр оболочки подпроцесса.
Пассивный режим возвращает только команды для выполнения, например, строку make для вызова простого Makefile в каталоге верхнего уровня элемента. Ему также передается параметр kwargs , который содержит конкретную информацию, например предварительно определенные значения, необходимые для добавления в CXXFLAGS, или дополнительные флаги компоновщика. Пример пассивного функтора можно найти в каталогах examples и test . В настоящее время все реализованные функторы используют пассивный режим.
PIRA передает следующие аргументы ключевого слова всем функторам. Кроме того, разные компоненты PIRA могут передавать дополнительные аргументы.
Важно ! Теперь мы выпускаем собственную версию Score-P. Таким образом, больше не требуется настраивать команды компиляции в PIRA. Посмотрите функторы в test/integration/AMG2013 чтобы увидеть примеры использования различной информации.
В настоящее время никакая информация не передается всем функторам.
[0] обращается к первому аргументу, [1] ко второму и так далее..so , реализующему функции оболочки MPI (важно для фильтрации MPI). Для некоторых режимов анализа требуются дополнительные параметры. В частности, для анализа моделирования PIRA LIDe (см. ниже) и Extra-P требуются параметры, предоставляемые пользователем. Создайте файл JSON и укажите его путь к PIRA, используя параметр --analysis-parameters -switch. Следующий пример содержит параметры для режима моделирования Extra-P. Доступные стратегии для объединения нескольких моделей Extra-P (когда функция вызывается в разных контекстах): FirstModel , Sum , Average , Maximum .
{
"Modeling": {
"extrapolationThreshold": 2.1,
"statementThreshold": 200,
"modelAggregationStrategy": "Sum"
}
}
Более подробную информацию о функции обнаружения дисбаланса нагрузки см. в [PI21]. Предоставьте вызову PIRA путь к файлу конфигурации, используя параметр --load-imbalance-detection . Этот JSON-файл должен иметь следующую структуру:
{
"metricType": "ImbalancePercentage",
"imbalanceThreshold": 0.05,
"relevanceThreshold": 0.05,
"contextStrategy": "None",
"contextStepCount": 5,
"childRelevanceStrategy": "RelativeToMain",
"childConstantThreshold": 1,
"childFraction": 0.001
}
Чтобы запустить PIRA в кластере с диспетчером рабочей нагрузки SLURM, вызовите его с флагом --slurm-config . Укажите вместе с ним путь к файлу конфигурации вашей пакетной системы. См. интеграционные тесты с суффиксом _Slurm ( test/integration/*_Slurm/ ). В настоящее время PIRA поддерживает пакетные системы с менеджером рабочей нагрузки SLURM. PIRA поддерживает использование module системы, которую можно найти в кластерах Slurm.
Файл пакетной конфигурации системы представляет собой 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 для использования стандартного sbatch с флагом --wait ; os для стандартных вызовов взаимодействия с sbatch и squeue . По умолчанию: pyslurm , поэтому необязательно.timings : как должно выполняться тайминг целевого кода. Варианты: subprocess для синхронизации с оболочкой Python и os.times в подпроцессе (точно так же, как это делает PIRA при локальном запуске); os , чтобы использовать /usr/bin/time . По умолчанию: subprocess , поэтому необязательно.force-sequential : по умолчанию false . Установите значение true чтобы заставить PIRA/вашу пакетную систему выполнять все запуски в последовательном порядке (только одно выполнение целевого кода за раз). Это означает, что 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. Решение по установке и упаковке pyslurm с PIRA находится в стадии разработки. Обратитесь к их 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 .
