Vtune amplifier xe linux

Intel VTune Amplifier

This article or section is out of date.

Intel VTune Amplifier is a commercial software performance profiler for Intel processors. There is a free 30 day trial.

Contents

Linux 4.0

VTune 2015 currently does not work with Linux 4.0, due to changes in the kernel that prevent the sepdk module from building. You need VTune 2016 which was released in August 2015.

Compiling the Kernel Modules

To build the kernel modules on Arch you should follow the 4th part of the README on sepdk folder. You can follow the Compile kernel module with Kernels/Traditional compilation#Download the kernel source, downloading the source code to /usr/src/ , extracting it with the name following the README and following the steps to unpack the kernel source.

There is a problem on the script ./build-driver that some users could not run the funcion get_absolute_path() so you should hardcode the variables DRIVER_DIRECTORY and KERNEL_SRC_DIR .

Also, there is a bug when trying to compile the kernel modules with kernel 4.10. Intel forum post

VTune Amplifier XE 2013

Follow the instructions for 2011. If you see errors while building the driver, it may be because intel is using deprecated functionality subsections. In the following sections, lines beginning with «-» indicates code that should be removed, lines beginning with «+» should be added.

Missing asm/system.h

Edit lwpmudrv.c as follows:

Implicit declaration of this_cpu_read

Edit eventmux.c as follows:

kmap_atomic and kunmap_atomic deprecated

Edit vtssp/user_vm.c as follows:

VTune Amplifier XE 2011

Starting with update 7 of the VTune Amplifier XE 2011, you can now use it on Linux 3.x and hence on Arch Linux, even though the latter is not officially supported. See also: VTune on Archlinux

Installing VTune

Using the following HOWTO you «install» VTune locally and can run it. Vtune requires a kernel module for all functionality. Nevertheless, VTune in user mode is very powerful and comes with lots of possibilities for profiling. Have fun!

• download VTune Amplifier XE 2011 (there is a free version for non-commercial use on linux)
• unpack the tarball
• install libpng12
• install libjpeg6AUR [broken link: package not found]
• install rpmextract
• Install the appropriate headers package(s) for your installed kernel(s), such as linux-headers or linux-lts-headers .
• if using a custom kernel, ensure that your kernel is compiled with the following options:
  • CONFIG_MODULES=y
  • CONFIG_MODULE_UNLOAD=y
  • CONFIG_SMP=y
  • CONFIG_KPROBES=y
  • CONFIG_PROFILING=y
  • CONFIG_OPROFILE=y

Now to «install» vtune:

• Create the group vtune and add yourself.
• Build and load the driver in /opt/intel/vtune_amplifier_xe_2011/sepdk/src/

• Add your license file to /opt/intel/licenses/

You can now start vtune:

For ease-of-use, it is recommended that you move the ./opt/intel/vtune_amplifier_xe_2011 to your homefolder or similar and add a symlink to the amplxe-gui binary to one of your PATH folders or similar.

Источник

7 новых возможностей Intel® VTune Amplifier XE

VTune Amplifier XE давно известен пользователям своими возможностями глубокого анализа производительности ПО, как на уровне приложения, так и на микроархитектурном уровне.

Инструмент не стоит на месте и активно развивается, улучшаясь и обрастая новым функционалом. В этом посте приведён краткий обзор новых «фич», появившихся как в вышедшем в сентябре VTune Amplifier XE 2013, так и совсем недавно, в последующих обновлениях:

• Анализ циклов
• Текстовый поиск
• Анализ энергоэффективности
• EBS анализ со стеками
• Профилировка Java приложений
• API для пользовательских задач
• Улучшения командного интерфейса

Анализ циклов

Как известно, оптимизация высокопроизводительных вычислений часто строится вокруг циклов – здесь и распараллеливание, и перераспределение данных для оптимального использования кэша, и векторизация. VTune Amplifier XE 2013 update 3 может определять, какие «горячие точки» на самом деле – «горячие циклы». Теперь пользователь может сконцентрироваться на их оптимизации, а не на поиске циклов по исходному коду, плюс оценить эффект от оптимизации каждого конкретного цикла от запуска к запуску.

Текстовый поиск

Результаты профилировки VTune Amplifier XE могут быть довольно объёмными, и бывает трудно сразу найти интересующую вас функцию/модуль/объект синхронизации и т.д.
Теперь пользователи наконец-то могут использовать простой текстовый поиск во всех основных окнах: bottom-up, top-down, source view, assembly view.

Анализ энергоэффективности

Энергоэффективность приложений приобретает всё большее значение. Ведь в растратах энергии повинна не только аппаратная часть, но и ПО. VTune Amplifier XE 2013 представил два новых типа анализа в этой области (пока доступы только для Linux).

Анализ CPU Frequency позволяет отследить изменение тактовой частоты во время исполнения программы на всех ядрах. Это даёт оценку активного энергопотребления, с тем, чтобы потом играть технологиями изменения частоты: Turbo Boost, SpeedStep и т.п.

Анализ CPU Sleep States даёт оценки пассивного энергопотребления – перехода по C-state-ам. Здесь отслеживаются “wake-up”-ы – “пробуждения”. Переход в более глубокий C-state и выход из него имеют затраты, поэтому если такое случается слишком часто, имеет смысл подумать об изменении ситуации. Анализ CPU Sleep States показывает частоту переходов по состояниям, статистику пребывания в разных состояниях, а главное объекты, вызывающие нежелательные «пробуждения» — например, таймеры:

EBS анализ со стеками

VTune Amplifier XE использует два основных подхода к профилированию. Первый основан на бинарной инструментации анализируемого процесса и называется «анализом пользовательского уровня». Второй подход (EBS анализ) работает не с процессом, а с модулем PMU в процессоре, что позволяет профилировать не только пользовательские приложения, но и операционную систему, и драйвера. Кроме того, так можно находить «микроархитектурные» проблемы софта.

До выхода 2013-й версии EBS анализ позволял найти функции и их код, но не стеки вызовов. Это было неудобно, если, например, «горячей точкой» оказывалась системная функция – найти ответственный за это пользовательский код было нелегко. С 2013-й версии анализы, основанные на EBS, предоставляют ещё и стеки вызовов. Теперь вы сможете проследить путь от системных вызовов и драйверов до вашего приложения, если оно к этому причастно.

Ещё одним приятным моментом является статистический подсчёт количества вызовов функций. Теперь можно не только увидеть суммарное время, потраченное на исполнение функции, но и оценить, каким образом оно формируется – часто, но по малу, или наоборот.

Профилировка Java приложений

Начиная с 2013-й версии VTune Amplifier XE поддерживает профилировку Java приложений. Это может быть особенно полезно для анализа «mixed» кода, совмещающего Java и вызовы «нативных» модулей (например, для выполнения тяжёлых вычислений). Кроме того, профилировщик позволяет обнаружить микроархитектурные проблемы в Java коде, например, неэффективное использование кэша. Более подробно читайте в этой статье (на английском).

API для пользовательских задач

Многие параллельные приложения строятся на «задачах» — небольших логических элементах работы, исполняющихся потоками. На задачах строится, например, библиотека Intel Threading Building Blocks.

API, предоставляемый VTune Amplifier XE (__itt API) недавно пополнился средством разметки таких задач:

Теперь пользовательские задачи можно отслеживать через grouping “Task Type / Function / Call Stack» и окно Tasks:

Подробно про task API читайте в этом посте.

Улучшения командного интерфейса

VTune Amplifier XE – это не только ценный мех красивый GUI, но и развитый командный интерфейс. Если вы просматриваете результаты профилировки в командной строке (или такой вывод используется в автоматизированном тестировании), вы могли заметить, что иногда не всё умещается в окно терминала и форматирование «съезжает». В 2013-й версии появился параметр report-width, ограничивающий ширину распечатываемых результатов, чтобы всё уместилось:

Для любителей GNU gprof появился новый формат представления результатов, в формате gprof:

При создании собственного EBS-анализа с нужным вам набором «эвентов» может потребоваться запустить его на другой машине. Если на ней нет графического интерфейса, можно скопировать командную строку. До недавнего времени вместе с таким нестандартным анализом приходилось копировать файл конфигурации, что требовало дополнительных действий, разбираться как использовать этот файл и т.п.

В последних обновлениях VTune Amplifier XE это стало делать проще – все параметры содержатся в командной строке. Просто нажимаете “Command line” в GUI и копируете сформированную строку на удалённую машину. Не нужно никаких дополнительных файлов.

Источник

Профилировка работы с памятью с Intel® VTune™ Amplifier XE

Неэффективный доступ к памяти, пожалуй, одна из наиболее частых проблем производительности программ. Скорость загрузки данных из памяти традиционно отстаёт от скорости их обработки процессором. Для уменьшения времени доступа к данным в современных процессорах реализуются специальные блоки и многоуровневые системы кэшей, позволяющие сократить время простоя процессора при загрузке данных, однако, в некоторых случаях, процессорная логика работает не эффективно. В этом посте поговорим о том, как можно исследовать работу с памятью вашего приложения с помощью нового профиля Memory Access в VTune Amplifier XE.

Метрики, относящиеся к памяти, уже давно доступны в VTune Amplifier. Новый тип анализа Memory Access не только собрал их в одном месте, но и добавил несколько серьёзных улучшений.

Было раньше в других типах анализа:

• Промахи кэшей всех уровней
• Данные о трафике в локальную оперативную память (DRAM bandwidth)
• Количество обращений к локальной и удалённой оперативной памяти на NUMA машинах

Появилось в Intel VTune Amplifier XE 2016:

• Отслеживание объектов данных
• Данные о трафике в удаленную оперативную память на NUMA машинах (QPI bandwidth)
• Среднее время исполнения (Аverage Latency) инструкций обращения к памяти или загрузки данных из объектов приложения

Итак, запускаем анализ Memory Access, сразу включаем отслеживание объектов данных. Эта возможность пока доступна только на Linux.

Или из командной строки:

Метрики подсистемы памяти

Итак, посмотрим на профиль, полученный после профилирования бенчмарка stream. В верхней половине окна Bottom-up отражён трафик, созданный нашим приложением:

• DRAM bandwidth – чтение (зелёным), запись (красным), и общий трафик в локальную оперативную память по каждому сокету (package).
• QPI outgoing bandwidth – исходящий трафик от одного сокета к другому.

Ниже представлена таблица, отражающая основные аппаратные метрики и счётчики обращений к памяти:

• Average Latency – среднее количество циклов процессора, затраченное на выполнение инструкций обращения к памяти или загрузку данных из объектов приложения. Это статистическое значение, может быть неточным на коротких замерах. Однако, если значение велико, стоит обратить внимание на остальные метрики.
• LLC Miss Count – количество промахов кэша верхнего уровня (обычно L3) – подразделяются на обращения к локальной оперативной памяти, удалённой оперативной памяти и удалённому кэшу, т.к. загружаемые данные могут находится в кэше другого процессора.
• Loads и Stores – количество исполненных инструкций чтения и записи данных
• Memory Bound – метрики эффективности операций с памятью

В Memory Bound входит отношение количества обращений к удалённой и локальной оперативной памяти, и метрики по тем же категориям, что и промахи кэша верхнего уровня (LLC):

Метрики Memory Bound это формулы, включающие количество тех или иных событий (например, промахов LLC) и их оценочной стоимости в циклах. Величина метрики сравнивается с некоторым эталонным значением, и подсвечивается розовым, если она превышает заданный порог. На выходе пользователь получает подсказку о том, на что стоит обратить внимание – большое количество промахов кэша может говорить о неэффективности расположения объектов данных, возможно, самые «горячие» объекты можно вынести в отдельный блок, который сможет дольше удерживаться в кэше.

Объекты данных

Проблемы работы с памятью неразрывно связаны с объектами данных, которые раньше приходилось вычислять самому. Теперь можно просто выбрать группировку с Memory Object, и наблюдать, на какие конкретно объекты приходятся большая часть обращений, промахи кэша и т.д.:

При этом, если дважды кликнуть на функцию над объектом, то попадём на строку кода, осуществлявшую интересующую нас операцию с памятью:

А если сгруппироваться по Memory Object Allocation Source и дважды кликнуть на сам объект, то можно определить место его создания:

VTune Amplifier распознаёт динамически создаваемые объекты языков С и C++ и статические объекты С, С++ и Fortran.

NUMA проблемы

На NUMA машинах обращения к локальной оперативной памяти выполняются быстрее, чем к удалённой, т.к. к оперативной памяти другого сокета приходится обращаться через QPI шину, которая медленнее, чем шина доступа к локальной оперативной памяти. Большое количество обращений к оперативной памяти или кэшу другого сокета, вкупе с высокими значениями Average Latency, может свидетельствовать о неэффективной локализации данных приложения. Если, например, глобальный объект данных создан в главном потоке, а другие потоки, возможно работающие на другом сокете, активно обращаются к нему, возможны простои процессора, обусловленные удалённым обращением к данным. Подобные проблемы можно решать с помощью локализации горячих данных в потоке, “пиннингом” (pinning) потоков, применением разных NUMA-aware библиотек.

Обнаружить NUMA проблемы в VTune Amplifier теперь достаточно просто. Для начала, смотрим все метрики со словом Remote, например, Remote/Local DRAM ratio – относительное количество удалённых обращений:

Можно отфильтровать функции и объекты с высоким QPI трафиком. На вкладке Summary в Bandwidth Utilization Histogram двигаем ползунки, определяя, какие значения мы считаем Low, Medium и High:

В Bottom-up группируемся по Bandwidth Domain, и смотрим, какие объекты использовались (или какой код исполнялся) во времена высокой QPI нагрузки:

Ну и традиционно для Bandwidth анализа, всплески трафика бывают наглядно видны на временной шкале. Выделяем такой участок и фильтруемся (клик правой кнопкой, Filter In by selection). Список функций в таблице внизу отразит только код, исполнявшийся в выбранном промежутке времени:

Ниже приведён результат профиля другого бенчмарка – Intel Memory Latency Checker:

Выделенный фрагмент имеет большой трафик на чтение и низкий на запись из локальной оперативной памяти сокета 1. Т.е. сокет 1 что-то активно читает. Также сокет 1 имеет большой исходящий трафик QPI, т.е. он активно что-то шлёт сокету 0 (больше некому, их всего два. Если сокетов 4 и больше, можно тоже определить направление по UNIT-ам, конкретным QPI линкам). При этом на сокете 0 наблюдается высокая активность процессора. Всё это наталкивает на мысль, что сокет 0 активно обращается к данным, которые расположены в оперативной памяти сокета 1, что подкрепляется данными о количестве удалённых обращений в таблице. Дальше можно разбивать таблицу до уровня функций и находить конкретные места в коде, ответственные за выявленный шаблон доступа.

Резюме

Новый тип анализа Memory Access помогает увидеть, как исполнение кода приложения соотносится с физической топологией памяти машины. Какие уровни памяти задействованы (кэши, DRAM, удалённая DRAM), как распределялся трафик памяти. И, что самое главное, какой код исполнялся во время долгих обращений к памяти, и к каким объектам данных эти обращения происходили.

Да, и если кто не слышал – Intel Parallel Studio можно скачать бесплатно для разных некоммерческих нужд – детали здесь.

Источник