Главная страница
qrcode

Intel vtunetmamplifier


НазваниеIntel vtunetmamplifier
Дата04.07.2020
Размер1.85 Mb.
Формат файлаpdf
Имя файлаvtune_amplifier.pdf
оригинальный pdf просмотр
ТипДокументы
#40790
Каталог
Анализ иоптимизацияприложенийс помощью
Intel® VTune
TM
Amplifier
С.А.Немнюгин
Высокопроизводительные вычисления на GRID системах. Архангельск, 2012
Содержание
• Оптимизация программного обеспечения.
• Общая характеристика Intel® VTune Amplifier XE.
• Некоторые проблемы производительности.
• Кейсы.
Оптимизация программного обеспечения обеспечения
Циклоптимизации
1.
Выявление «горячих пятен » (Hotspots).
2.
Определение причин низкой эффективности:
 промахи кэш-памяти;
 доступ к данным;
 простои выполнения программы;
 ошибки предсказания ветвлений;
 ошибки предсказания ветвлений;
 другие.
3.
Оптимизация.
Три уровня оптимизации:
• Системный уровень
• Уровень приложения
• Микроархитектурный уровень
1 шаг анализа производительности программы - науровне системы
 Анализ операций обмена с внешними носителями
(жесткими дисками).
 Анализ использования оперативной памяти.
 Анализ взаимодействия с сетью.
Цельоптимизациинауровнесистемы
– добиться
Цельоптимизациинауровнесистемы
– добиться наиболее эффективного взаимодействия программы с системой.
Наличие проблем на уровне системы может лишить смысла оптимизацию программы на других уровнях (если программа мало загружает процессор из-за проблем на уровне системы, даже серьезное ускорение на уровне архитектуры не даст, скорее всего, заметного выигрыша).
Оптимизация на уровне приложения - оптимизация алгоритмов.
Выполняется анализ:
эффективности использования ППИ;
эффективности реализации многопоточности;
наличия блокировок;
др
др
3 (самыйнижний) уровеньанализа – уровень архитектуры.
Обладает наименьшим потенциалом эффективности.
Ключевые факторы:
 использование кэш-памяти;
 выравнивание данных;
 другие вопросы.
Наибольший выигрыш (в несколько раз по производительности) достигается на уровне системы.
Умеренный выигрыш - на уровне приложения.
Небольшой выигрыш (до нескольких десятков процентов) - на уровне архитектуры процессора.
процентов) - на уровне архитектуры процессора.
При анализе выполнения программы в первую очередь следует обратить внимание на следующие факторы:
количествопромаховприобращенииккэш-памяти. Каждый промах приводит к дополнительным транзакциям между оперативной памятью и кэш-памятью, что отрицательно сказывается на производительности программы;
ошибкивпредсказанииветвлений. Предсказание ветвлений
ошибкивпредсказанииветвлений. Предсказание ветвлений позволяет прогнозировать исполнение программы, принимая меры для его ускорения. Чем точнее выполняется предсказание, тем эффективнее исполняется программа;
вычислениясплавающейточкой. Значение этого фактора очевидно для вычислительных программ, в которых может выполняться колоссальное количество арифметических операций с плавающей точкой;
блокировки, связанные с доступом к ресурсам. Каждая блокировка ведёт к потере производительности;
потери производительности, связанные с отсутствием выравнивания данных. Время выполнения команд с невыровненными данными существенно увеличивается, что приводит и к увеличению времени выполнения программы.
В Help имеется информация о событиях, по которым возможен сбор
В Help имеется информация о событиях, по которым возможен сбор статистики.
Длявыполненияанализаприложения VTune
потребуются:
исполняемый (бинарный) файл, подготовленный соответствующим образом;
исходный файл (не обязательно, но желательно, поскольку в этом случае результаты сбора статистики можно «привязать» к исходному коду программы);
символьная информация;
информация о номерах строк.
Необходим правильноподготовленныйтестовыйнаборданных, соответствующий «стандартной» для данного приложения ситуации. Запуск приложения с этим набором данных даёт опорную точку, по которой будет определяться эффективность различных методов оптимизации производительности.
Общая характеристика
Intel® VTune
TM
Amplifier
Intel® VTune
Amplifier
Intel® VTune Amplifier XE – эксIntel® VTune Performance
Analyzer – инструмент динамического анализа приложений.
Многоплатформенный: MS Windows, Linux.
Совместимость с : C/C++, Fortran, .NET, ассемблер.
Интеграция с Microsoft Visual Studio.
Интеграция с Microsoft Visual Studio.
Возможность работы в режиме командной строки (CLI).
Поддержка автономного интерфейса.
Входит в состав следующих пакетов:
 Intel® Parallel Studio XE
 Intel® Cluster Studio XE
Позволяет выполнять анализ следующего вида:
 анализ «горячих пятен» («хотспотов»);
 анализ эффективности реализации многопоточности;
 анализ блокировок и простоев;
 анализ статистики по событиям.
Графический интерфейс:
представление результатов различных типов анализа в виде
представление результатов различных типов анализа в виде временных диаграмм;
привязка к исходному тексту или результатам дизассемблирования.
Набор заранее сгенерированных профилей анализа.
Сборстатистики:

по времени (TBS);

по заданному количеству событий (например, по заданному количеству ошибочно предсказанных ветвлений, EBS);

привязка к исходному коду или дизассемблирование.
Некоторые проблемы производительности производительности
Использованиепроцессора
Idle – все ядра находятся в состоянии ожидания. Ни один поток не выполняется.
Poor – доля одновременно работающих ядер < 50%.
Ok – доля одновременно работающих ядер от 51% до 85%.
Ok – доля одновременно работающих ядер от 51% до 85%.
Ideal – доля одновременно работающих ядер > 86%.
Эффективностьмногопоточногопараллелизма
Idle – все потоки находятся в состоянии ожидания. Ни один поток не выполняется.
Poor – низкая эффективность. Доля используемых потоков < 50% от степени параллелизма архитектуры.
Ok – хорошая эффективность. Доля используемых потоков от 51%
до 85% от степени параллелизма архитектуры.
Ideal – очень хорошая эффективность. Доля используемых потоков от 86% до 115% от степени параллелизма архитектуры.
Over – избыточная эффективность. Доля используемых потоков
> 115% от степени параллелизма архитектуры.
«Горячиепятна»
Hotspot – это фрагмент, в котором программа проводит значительную часть времени.
Hotspots определяются в терминах событий
CPU_CLK_UNHALTED.THREAD («тиков»).
2 вида анализа Intel® VTune Amplifier XE:
1. Hotspots
2. Lightweight hotspots
Видыанализа Intel® VTune
TM
Amplifier XE
 Поиск функций, на выполнение которых тратится наибольшее время
(«хотспоты», «горячие пятна программы»);
 Поиск фрагментов программы, которые неэффективно используют процессор.
 Поиск фрагментов программы, в которых следует в первую очередь выполнить оптимизацию последовательного кода.
 Поиск фрагментов программы, в которых следует в первую очередь
 Поиск фрагментов программы, в которых следует в первую очередь выполнить оптимизацию многопоточной реализации.
 Поиск объектов синхронизации, которые «плохо» влияют на производительность.
 Поиск неэффективных операций ввода-вывода.
 Поиск «узких мест», связанных с неэффективным использованием оборудования.
 Другие.
Промахикэш-памяти
Промахи увеличивают CPI (Clocks Per Instruction).
Анализ выполняется в режиме General Exploration.
Метрики LLC_Hit, LLC_Miss.
Как уменьшить количество промахов:
 согласовать размер данных с размером кэша;
 использовать локальные по отношению к потокам переменные;
 использовать алгоритм, минимизирующий число обращений к памяти;
 другие (см. Intel® 64 and IA-32 Architectures Optimization
Reference Manual).
Конкуренцияподоступукпамяти
(write sharing)
Одному ядру нужны данные, модифицированные другим ядром.
Инициируется транзакция между кэш-памятью ядра, модифицировавшего данные и ядра, которому эти данные нужны.
«Пинг-понг» увеличивает время выполнения.
«Пинг-понг» увеличивает время выполнения.
False sharing
– модифицируются разные фрагменты одного набора данных, находящиеся в одной строке кэш-памяти.
True sharing
– модификация одних и тех же данных.
Выравниваниеданных
Отсутствие выравнивания увеличивает количество транзакций.
Профиль General Exploration.
Метрика 4K Aliasing.
Что делать:
 использовать выравнивание данных;
 использовать «правильные» операции доступа к памяти.
Ошибкипредсказанияветвлений
Ошибки предсказания ветвлений ухудшают эффективность, так как инициируются дополнительные выборки инструкций.
Профиль General Exploration.
Метрика Branch Mispredict.
Метрика Branch Mispredict.
Ошибки предсказания ветвлений есть всегда!
Что делать, чтобы минимизировать число ошибок предсказания ветвлений:
 использовать при компиляции оптимизацию на основе профилирования.
Процессоры Intel® Core 2-го поколения поддерживают технологии:
 hyper-threading;
 turbo boost.
Этитехнологиивлияютнаанализ. Статистика по некоторым событиям собирается по потокам, а по некоторым – по ядрам.
При анализе приложения часто отключают поддержку (BIOS), затем анализ повторяется при включенной поддержке.
Кейсы
Анализреализациимногопоточности выявилпроблемы:
Frequent fork-join operations.
Several "data race" errors.
Several "thread is waiting" errors caused by too often implicit barrier synchronization (at the end of each parallel section).
Several "thread is waiting" errors caused by missing "private" directives.
directives.
Solvm13, dotprd11 and axpy subroutines occupy most of the run time.
Примерпротоколаоптимизации:
b_iccg.f:
1. calls of axpy subroutine were changed to axpy1 calls (where
"axpy1" is axpy for a=-1) or axpy2 calls (where axpy2 is MKL's subroutine saxpy);
2. calls of CopyArray4to4 subroutine were changed to MKL's scopy calls (for Real8 solver it should be dcopy).
service.f
service.f
"Laminar transport coefficients" loop was parallelized + loop exchange was made on the line 919: loops exchanged and "private" directive added.
Примерпротоколаоптимизации:
poisson.f
1. dotprd11cell subroutine: instead of a big number of "omp parallel do" directives one parallel section was used. All omp do's completed with "nowait" option. It was made in order to allow the threads not to wait each other but to continue loop processing. (minimization of fork-join operations);
2. axpy1 and axpy2 subroutines added;
3. calls of axpy changed on axpy1 and axpy2 calls.
3. calls of axpy changed on axpy1 and axpy2 calls.
modules.f:
write-write data race fixed.
Примерпротоколаоптимизации:
heat.f
In "Look through all z-lines of cells" loop the private directive was fixed: s_ze variable was added
(this addition fixed read-write, write-write и write-read data races)
dynamic.f:
1.
in "Multiply by time step" loop instead of a big number of "omp parallel do" directives one parallel section was used. All omp do's completed with "nowait" option. It was made in order to allow the threads not to wait each other but to option. It was made in order to allow the threads not to wait each other but to continue loop processing. (minimization of fork-join operations);
2.
in "Pressure upgrade and velocity projection" loop all parallel sections changed on omp do nowait directives. Private directives added.;
3.
the loop on line 1195 was parallelized;
4.
" Fix pressure level in REGIONs" loop was parallelized;
5.
in "Add_Gravitation" subroutine instead of a big number of "omp parallel do" directives one parallel section was used. All omp do's completed with "nowait" option. It was made in order to allow the threads not to wait each other but to continue loop processing. (minimization of fork-join operations). Private directives added.
nemnyugin@parserplus.com

перейти в каталог файлов


связь с админом