Оптимизация параллельной программы
10.8.4. Анализ производительности приложения
Далее мы по шагам изучим основные элементы графического интерфейса ITP, попутно рассматривая, как каждый из них используется при анализе производительности приложения.
10.8.4.1. Вкладка Summary
В нижней части окна ITP располагаются вкладки под названием Profile View и Summary. Перейдите на вторую из них, наведя на нее курсор и щелкнув левой кнопкой мыши. Эта вкладка содержит общую информацию о трассе приложения (рис. 10.15).
Вкладка состоит из двух таблиц: первая содержит общую информацию о состоявшемся запуске (характеристики узла, время работы приложения, число потоков и т.д.), а вторая - статистику вызовов API.
Щелкните на знак "+", располагающийся возле надписи "APIs" в нижней таблице, при этом она должна принять вид, как показано на рис. 10.15. Из таблицы можно узнать, сколько времени приложение потратило на ввод/вывод, синхронизацию, непроизводительные издержки и т.д.
После того как вы ознакомитесь с приведенной информацией, вернитесь на вкладку Profile View.
10.8.4.2. Окно Profile
Основную часть окна Profile занимает область, на которой представлен критический путь приложения. Пользователь имеет возможность управлять представлением критического пути, для чего используется функция группировки и справка по использованию цветов ( легенда ), располагающаяся справа. Рассмотрим их подробнее.
10.8.4.2.1 Выбор характеристик поведения потоков для визуализации
С помощью панели Legend пользователь имеет возможность указать интересующие его характеристики поведения потоков. Для этого используются находящиеся на легенде кнопки-флажки (check-box). Первый из них, называемый Thread State, позволяет указать, интересует ли нас информация о состоянии потока. Напомним, что существуют три типа состояния: активное ( active ), активное ожидание ( spin ), ожидание ( wait ).
Выберите тип группировки по потокам, нажав на панели кнопку с изображением катушки
. После этого в окне появится информация о распределении времени в критическом пути, как показано на рис. 10.17.
Информация о состоянии потоков представлена в виде столбиков зеленого цвета различной насыщенности. Бледно-зеленый цвет используется для обозначения того, что поток находился в состоянии ожидания, а темно-зеленый цвет соответствует активному состоянию потока. Из рисунка можно узнать, что два потока в нашем приложении (первый и третий столбики) большую часть времени были активны, а еще один поток в основном находился в состоянии ожидания. Нетрудно понять, что в ожидании находился основной поток нашего приложения, в то время как созданные им потоки производили разложение чисел на простые множители. Снимите флажок Thread State и убедитесь, что информация о состоянии потоков исчезнет. После этого верните флажок в исходное положение.
Следующая кнопка-флажок - Critical Path Data, при помощи которой пользователь может указать, интересует ли его разбиение критического пути по категориям времени. Снимите этот флажок и убедитесь, что на рисунке останется информация, касающаяся исключительно состояний потоков.
После этого верните все в исходное положение, в котором установлены флажки Critical Path Data и Concurrency, а флажок Behavior неактивен. В этой конфигурации легенды пользователь имеет возможность анализировать, насколько эффективно его приложение использует ядра процессора ( уровень параллелизма ). Здесь мы имеем дело с категориями времени, про которые было рассказано в разделе 3. В нашем случае можно увидеть, что основную часть критического пути занимает оранжевый цвет, что означает, что большую часть времени приложение выполнялось в последовательном режиме. Это тревожный симптом, который может означать недостаточно высокую степень распараллеливания или неравномерное распределение нагрузки между потоками.
Легенда также несет информационную функцию. Если вы забыли, что означает тот или иной цвет, наведите курсор мыши на прямоугольник соответствующего цвета в легенде. Появится всплывающая подсказка, содержащая информацию о том, что он означает. Кроме того, если цвет считается "проблемным" (свидетельствует о неправильной организации приложения), то в подсказке будут содержаться советы для решения данной проблемы.
На легенде неизученной осталась последняя кнопка-флажок Behavior. Установите ее и снимите флажок Concurrency. В этой конфигурации пользователь имеет возможность определить поведение потока в его активном состоянии, о котором мы говорили ранее в "Оценка производительности кластерных систем" . В нашем случае критический путь окрашен в основном в красный цвет, что означает, что происходило ожидание завершения работы некоторых потоков. Это дает нам мало новой информации, поскольку мы и раньше знали, что основной поток приложения большую часть времени ожидает завершения дочерних потоков.
Установите флажки Concurrency и Behavior, чтобы получить комбинацию двух этих режимов. Тогда критический путь приобретет более разнообразную окраску. Предназначен этот режим для одновременного анализа всей совокупности характеристик поведения потоков.
10.8.4.2.2 Использование функции группировки
Данная функция очень удобна при анализе критического пути, она позволяет взглянуть на оптимизируемое приложение с различных точек зрения. Так, если осуществить группировку по потокам (кнопка), то можно проанализировать эффективность работы каждого из потоков. Если же включить группировку по объектам (кнопка
), то становится доступной информация об эффективности работы с конкретным объектом (примитивом синхронизации, например).
Рассмотрим наиболее типичные варианты использования группировки. Полезно начать с варианта, когда группировки не используются. Нажмите кнопку с изображением перечеркнутого красного круга
- при этом критический путь примет вид как показано на рис. 10.18.
Этот режим наиболее полезен для получения информации о распределении времени в критическом пути. Используя его можно получить информацию о том, сколько процентов занимает последовательное выполнение (доля оранжевого цвета), сколько параллельное (зеленый, синий и красный цвета), а также какую часть занимают непроизводительные расходы (доля желтого цвета). Попробуйте также другие режимы группировки, анализируя каждый раз изменения критического пути.
Кроме того, может оказаться полезной возможность вторичной группировки.
В первом наборе кнопок группировки нажмите кнопку с изображением катушки, а во втором наборе - с буквами CL
. При этом критический путь примет вид, как показано на рис. 10.19.
В данном случае мы имеем возможность исследовать, насколько эффективно функционировал каждый из потоков. Мы видим три группы столбиков, каждая из которых соответствует одному потоку. Столбики показывают сколько времени каждый из потоков функционировал в последовательном режиме, сколько в параллельном, а сколько в состоянии ожидания. Как можно увидеть из рисунка, третий поток (левая группа столбиков) большую часть времени работал в последовательном режиме, то есть параллельно с ним не работал ни один другой поток. Второй же поток (правая группа столбиков) практически все время работал параллельно с третьим потоком. Основной же поток приложения (центральная группа столбиков) выполнялся лишь в последовательном режиме и большую часть жизни находился в режиме ожидания дочерних потоков.
Поэкспериментируйте, определяя различные порядки группировки, попытайтесь представить ситуации, в которых они могут быть полезны.
10.8.4.2.3 Рабочая область
Мы изучили различные способы представления критического пути в рабочей области окна Profile и пришло время изучить способы его анализа.
Выключите группировку, чтобы распределение критического пути по категориям времени было представлено в виде одного столбца как на рис. 10.20. Кроме того, установите все флажки на легенде. После этого наведите курсор на каждый из участков критического пути с различными цветами. В появляющихся подсказках содержится информация об участке критического пути, на который указывает курсор мыши.
Наведите курсор мыши на столбец и щелкните левой кнопкой один раз. В нижней части окна Profile появится информация о том, сколько времени приложение функционировало в различных режимах - распределение времени по категориям.
Двойной щелчок на столбце позволяет получить более подробную информацию. Попробуем, например, получить полную информацию об участке критического пути оранжевого цвета (здесь и далее имеется в виду ярко-оранжевый цвет). Для этого наведите на него курсор и произведите двойной щелчок левой кнопкой мыши. Критический путь распадется на уровни параллелизма ( concurrency ), в чем можно убедиться по нажатой кнопкена панели группировки и надписям под различными столбцами. Щелкните по оранжевому участку еще раз, и единый столбец снова распадется на несколько - уже по числу потоков. Еще один двойной щелчок приведет нас к уровню функций. Теперь надпись под столбцом однозначно указывает на имя функции, время работы которой вошло в критический путь с оранжевым цветом. Если произвести еще один двойной щелчок, то откроется вид исходного кода рис. 10.21.
Здесь мы можем убедиться, что за участок критического пути оранжевого цвета отвечает рабочая функция потоков, производящих факторизацию чисел.
Чтобы вернуться к исходному представлению критического пути, выключите все фильтры, нажав кнопку с изображением воронки
, а затем отмените всякую группировку, нажав кнопку.
Если имеется необходимость понять, какой участок кода отвечает за некоторый участок критического пути, можно поступить более простым способом, чем мы делали это раньше. А именно, выберите способ группировки по исходному коду. Для этого нажмите на кнопку с изображением файла
. После этого наведите курсор мыши на интересующий вас участок критического пути и нажмите правую кнопку мыши. Если ITP имеет доступ к коду, который отвечает за данный участок критического пути, то в контекстном меню будет доступен пункт Transition Source View. Выберите его, и откроется вид исходного кода.
Однако не всегда можно спуститься до уровня исходного кода - так случается, если в приложении не содержится отладочная информация. Типичная ситуация - приложение использует вызовы библиотеки, которая была получена в скомпилированном виде.
Итак, окно Profile предоставляет возможности анализа критического пути. С его помощью можно узнать распределение времени работы приложения по категориям. Но при этом мы получаем очень мало информации о динамике работы приложения. Для понимания того, что происходило с потоками во время исполнения, как они взаимодействовали между собой, обратимся к следующему окну ITP - окну Timeline.