Информационные технологии Вестник Нижегородского университета им. Н.И. Лобачевского, 2011, № 3 (2), с. 212-218
УДК 519.685.1
ОБЗОР ИССЛЕДОВАНИЙ В ОБЛАСТИ АВТОМАТИЗАЦИИ ДИАГНОСТИКИ ПРОИЗВОДИТЕЛЬНОСТИ MPI-ПРИЛОЖЕНИЙ
© 2011 г. А.В. Дергунов, С.Н. Карпенко
Нижегородский госуниверситет им. Н.И. Лобачевского
Поступила в редакцию 16.09.2010
Рассматриваются существующие исследования в области автоматизации анализа производительности в MPI-приложениях. Дается оценка того, в какой мере они помогают решить задачи повышения производительности.
Ключевые слова: параллельное программирование, MPI, анализ производительности.
Введение
После того, как параллельная программа написана и проверена на корректность, нужно провести анализ ее производительности. Программа может давать корректные результаты, но быть медленней, чем ожидалось, что связано с наличием проблем производительности. Цель анализа производительности в этом случае -применить подходящие инструменты и методы, чтобы определить, почему производительность программы не удовлетворяет ожиданиям.
Методы анализа производительности программ
Существуют три основных метода анализа производительности [1]:
1. Аналитическое моделирование (analytical modeling). Этот метод предусматривает математическое описание рассматриваемой системы, и по сравнению с другими методами он зачастую предоставляет наименее подробную информацию о системе. Но простая аналитическая модель может предоставить понимание общего поведения системы или ее компонентов и того, какие детали нужно изучить другими методами.
2. Имитация (simulation). Этот метод предусматривает написание программы-имитатора для моделирования важных характеристик исходной системы. К преимуществам этого метода относится то, что имитатор может быть легко модифицирован для изучения определенных аспектов исходной системы. К недостаткам относится невозможность имитировать каждую деталь исходной системы. В результате нужно
делать упрощающие предположения, чтобы иметь разумное время выполнения имитатора, но это ограничивает точность этого метода.
3. Измерение производительности существующей системы (measurements of existing system). В большинстве случаев этот метод является предпочтительным, т.к. не нужно делать упрощающих предположений - проводится измерение реальной системы. С другой стороны, этот метод не очень гибкий, т.к. предоставляет информацию только о той системе, которую он измеряет, и для конкретного набора ее параметров. В то время как существует возможность исследовать производительность для нескольких определенных параметров данных, в общем случае это сделать затруднительно. Например, в большинстве случаев нет возможности исследовать влияние скорости работы оперативной памяти на производительность программы.
В этой статье рассматриваются системы, которые используют третий метод анализа, измерение производительности существующей системы. Существуют три основных метода измерения производительности [1]:
1. Событийно-управляемый метод (event-driven). Этот метод осуществляет сбор показателей производительности при наступлении определенного события. В простейшем случае используется глобальный счетчик для подсчета количества произошедших событий. Например, с помощью этого метода можно подсчитать количество ошибок из-за отсутствия страницы в виртуальной памяти (page faults), которые произошли во время работы программы. Лучше всего этот метод подходит для событий, частота наступления которых не очень велика, т.к. в
противном случае изменяется поведение программы.
2. Трассировка (tracing). Этот метод похож на предыдущий, но кроме фиксирования произошедшего события также используется какая-либо информация о состоянии системы. Например, вместо простого подсчета количества ошибок из-за отсутствия страницы в виртуальной памяти трассировщик может также фиксировать адрес в оперативной памяти, при обращении к которому произошла эта ошибка. К недостаткам этого метода относятся повышенные требования к памяти для хранения собранной информации, что может привести к еще большему изменению поведения программы.
3. Сэмплирование (sampling). В противоположность событийно-управляемому методу, этот метод предусматривает сохранение состояния системы и значения показателей производительности в фиксированные временные интервалы. В результате накладные расходы на измерения не зависят от времени возникновения событий. Но с использованием этого метода собирается информация не о всех возникших событиях. Результат измерения представляет собой статистику работы программы.
Для анализа производительности MPI-программ наиболее часто используется трассировка вызовов MPI процедур. Все рассмотренные далее системы используют этот подход. Для трассировки наиболее часто используется профилировочный интерфейс MPI (MPI profiling interface) - механизм, который позволяет переопределять функции MPI и таким образом перехватывать их вызовы.
Процесс повышения производительности программ
Задача исследования производительности программ с целью ее повышения при использовании измерительных инструментов состоит из следующих задач:
1. Выбор метрик или параметров оценки производительности программы (performance metric). В [2] отмечается, что в качестве метрики измерения производительности можно рассматривать такие многообразные показатели, как общее время ее выполнения, параллельная эффективность, масштабируемость, требования к памяти, пропускная способность и т.д. Трассировщики MPI приложений наиболее часто предоставляют информацию о времени вызова MPI процедур и некоторые дополнительные данные (например, размер данных, посланных или при-
нятых процедурой MPI, ранк целевого процесса и т.п.). В [2] также отмечается, что время выполнения программы и параллельная масшабируе-мость - один из самых проблематичных показателей в параллельной программе. Но для оптимизации этих показателей зачастую бывает необходимо рассматривать и другие параметры (например, размер переданных данных).
2. Сбор данных производительности. Чаще всего производится один или несколько запусков MPI программы с репрезентативными данными и определенными параметрами на определенной вычислительной системе (или разных системах).
3. Анализ данных производительности программы на предмет выявления проблем производительности. Чаще всего при анализе производительности сначала используют статистические, суммарные данные. Например, предположим, что в результате анализа данных обнаружено, что затраты на коммуникационные операции составляют большую часть работы приложения. Более детальный анализ свидетельствует о том, что большая часть коммуникационных затрат приходится на прием данных (вызовы функций MPI_Recv).
4. Выявление причин возникновения проблем производительности. На этом этапе необходима более детальная информация о производительности программы. Например, многие средства визуализации данных производительности MPI программ предоставляют временную диаграмму вызовов MPI процедур (Event Timeline Chart [3]). Анализируя временную диаграмму для рассматриваемого примера, можно было бы обнаружить, что причиной больших затрат на прием данных является большая задержка при ожидании посылки данных другими процессами.
5. Принятие решения о способе устранения проблем производительности. Каждая проблема производительности может иметь несколько возможных решений, которые иногда могут быть реализованы на разных уровнях (уровне приложения, системы и т.п.), поэтому на этом шаге также требуется дополнительная информация. Например, чтобы исправить проблему на уровне приложения, часто необходимо анализировать его исходный код. В рамках рассматриваемого примера необходимо проверить, нужны ли данные непосредственно сразу после приема, и в противном случае использовать неблокирующие операции приема.
6. Устранение причин возникших проблем производительности. Изменение рассматриваемой системы также требует более детальной
информации, а также возможности вносить эти изменения.
Этот процесс может повторяться (например при наличии нескольких причин) до достижения требуемой производительности. При этом рекомендуется при повышении производительности начинать с устранения тех проблем, которые дадут наибольший результат, поэтому используемые инструменты должны предоставлять информацию о степени влияния проблем производительности на общее время работы приложения.
В этой статье дается обзор систем, которые помогают автоматизировать или упростить задачу анализа данных производительности, выявления проблем производительности и их причин, а также помогают указать способ разрешения этих проблем. Как отмечается в [4], системы с такой функциональностью являются «давно ожидаемым дополнением для любой системы анализа производительности». Задачи выбора метрик, сбора данных и визуализации, автоматизации планирования экспериментов, а также задача выполнения изменений для устранения причин недостаточной производительности выходят за рамки этой статьи.
Способы повышения производительности MPI программ
Ниже перечислены некоторые способы повышения производительности МР1 программ, почерпнутые из [5-8]:
• Необходимо распараллелить вычисления и назначить процессам процессоры так, чтобы сбалансировать вычислительную нагрузку, т.к. общее время вычислений определяется временем работы наиболее загруженного процессора.
• Необходимо сократить количество пересылаемых данных и по возможности посылать одно большое сообщение вместо нескольких маленьких, чтобы избежать большой латентности.
• В некоторых случаях имеет смысл продублировать вычисления определенных данных вместо их пересылки.
• Необходимо отправлять данные как можно раньше, а также маскировать ожидание приема данных, используя неблокирующие операции МР1.
• Необходимо использовать топологии МР1 (декартовы, графовые), чтобы эффективно распределить процессы между процессорами параллельной вычислительной системы и т.д.
Intel Trace Collector and Analyzer: сбор и визуализация трассы выполнения MPI приложений
Intel Trace Collector and Analyzer [3; 9] -коммерческий продукт компании Intel. Это достаточно популярный и функциональный инструмент для сбора и визуализации данных трассы, полученной при выполнении MPI приложения. Для анализа производительности доступны такие визуальные средства, как:
• Статистика по функциям (Function Profile Chart) - набор таблиц, показывающих, например, суммарное время, затраченное на вызов каждой из функций MPI.
• Временная диаграмма (Event Timeline Chart) визуализирует работу каждого процесса. На горизонтальной оси отложено время работы приложения. Вертикальная ось соответствует процессам программы. Работа процесса визуализируется последовательностью прямоугольников, обозначающих исполняемые функции, а линиями отмечено взаимодействие между процессами. Реализована возможность получить дополнительную информацию о каждой выполненной функции или посылке данных. Таким образом, эта диаграмма предоставляет самую детализированную информацию.
• Диаграммы процессов и событий (Qualitative Timeline, Quantitative Timeline and Counter Timeline Charts) показывают графики количества процессов, выполняющих коммуникационные функции MPI, или значения специальных счетчиков в определенные промежутки времени.
• Статистика операций обмена данных (Message Profile Chart) - матрица по процессам, показывающая информацию об обмене данными между ними (например, время, затраченное на обмен сообщениями). Кроме группировки по процессам поддерживаются также другие виды группировок.
• Статистика коллективных обменов данных (Collective Operations Profile Chart) - матрица, показывающая для каждого процесса информацию по каждому типу операций коллективного обмена, использованных в программе (например, время, затраченное процессом на определенный тип операций).
Тем не менее, при анализе проблем производительности с использованием перечисленных графических инструментов часто возникают следующие трудности:
• Анализ большого объема данных. Даже при достаточно коротком времени работы программы и небольшом числе процессов на временной диаграмме зачастую отображается очень большое количество информации.
• Часто встречающиеся проблемы производительности (например, «поздний прием данных» [8]) никак явно не обозначаются. Таким образом, для выяснения причин недостаточной производительности требуется анализ данных вручную с помощью перечисленных выше графических инструментов.
• Отсутствуют средства для выдачи рекомендаций пользователю по улучшению производительности. Таким образом, оптимизация производительности зачастую требует от пользователя глубоких знаний о MPI (возможностях по оптимизации, предусмотренных в этой библиотеке, принципах работы реализаций библиотек MPI), особенностях сети передачи данных и других знаний.
Таким образом, Intel Trace Collector and Analyzer позволяет выполнять только сбор и визуализацию данных производительности.
property synchronization cost (Region
{
LET
float barrier time = summary(r, e
IN
CONDITION: barrier_time > G;
CONFIDENCE: І;
SEVERITY: barrier time/duration
І
Для характеристик производительности вычисляются следующие параметры:
• Условие наличия характеристики (булево значение CONDITION)
• Степень уверенности в наличии (вещественное значение CONFIDENCE от 0 до І)
• Степень влияния на производительность (вещественное значение SEVERITY)
В языке ASL характеристики производительности могут описываться только с использованием статистических данных. В результате эта система не способна диагностировать целый класс проблем производительности, возникающих в результате взаимодействия процессов MPI. Таким образом, возможности по автоматизации выявления проблем производительности и их причин ограничены. Выдача рекомендаций по повышению производительности в системе не реализована.
Решение остальных задач полностью возлагается на пользователя.
Aksum: анализ производительности с использованием статистических данных
Система Aksum [10] основана на языке ASL [8] (APART Specification Language), который был разработан в рамках рабочей группы по автоматизации анализа производительности APART (Automatic Performance Analysis: Resources and Tools). Этот язык специфицирует:
• Модель описания данных производительности (performance-related data), которая включает как статическую информацию (например, описание распараллеленных частей программы в исходном коде), так и динамическую (например, статистические данные о временных затратах в приложении).
• Язык описания характеристик производительности (performance property).
Ниже приведен пример характеристики производительности, которая описывает накладные расходы на синхронизацию в программе (пример взят из [9]):
r, Experiment e, Region rank basis) ).sums.sync_time;
(rank_basis, e);
KOJAK (Kit for Objective Judgement and Knowledge-based Detection of Performance Bottlenecks): анализ производительности при взаимодействии процессов
Цель проекта KOJAK - разработка среды для автоматического анализа производительности параллельных программ [11].
Как отмечается в [12], для понимания причин возникновения проблем производительности недостаточно обладать только статистическими данными (например, данными о суммарном времени выполнения каждой из процедур MPI). Для приложений, использующих библиотеки передачи данных, главную сложность в интерпретации данных производительности составляет временная и пространственная отдаленность между причиной и симптомом проблемы производительности. Другими словами, для диагностики производительности MPI-
приложений необходимо анализировать взаимодействие процессов, и такая возможность реализована в системе KOJAK.
Система KOJAK состоит из нескольких компонентов, из которых в рамках данного обзора наибольший интерес представляют 2 средства:
• Библиотека EARL (Event Analysis and Recognition Language), которая предоставляет интерфейсы для C++ и Python для обработки трассы выполнения программ.
• Система EXPERT (Extensible PERformance Tool) для автоматизации диагностики проблем производительности. Эта система использует библиотеку EARL и состоит из набора подпрограмм, каждая из которых предназначена для обнаружения определенного типа проблемы производительности.
Примером проблемы производительности, которая диагностируется системой KOJAK, является поздняя посылка данных при операции двухточечного обмена сообщениями (late sender). Эта проблема возникает, когда операция приема данных вызывается позднее блокирующей операции посылки, и в результате последняя должна простаивать.
Для визуализации найденных проблем производительности применяется система CUBE. Это средство предоставляет 3 взаимосвязанных графических инструмента:
• Окно метрик или характеристик производительности (Metrics).
• Окно дерева вызовов (Call Tree or Flat Region Profile).
• Окно системных ресурсов (System Location: System Tree or Topology View). Это окно показывает иерархию вычислительных ресурсов: компьютеров, процессов, потоков или визуализирует топологию.
Итак, система KOJAK позволяет автоматизировать нахождение проблем производительности, которые возникают при взаимодействии MPI процессов. К недостаткам этой системы можно отнести то, что типы распознаваемых проблем производительности жестко определены и для их расширения необходимо изменять исходный код системы EXPERT. В системе также отсутствует выдача рекомендаций по повышению производительности.
KappaPI 2 (Knowledge-based Automatic
Parallel Program Analyzer for Performance Improvement): анализ производительности
при взаимодействии процессов и выдача рекомендаций для PVM программ
Авторы системы KappaPI 2 называют главной ее целью - выдачу рекомендаций пользова-
телю как улучшить производительность приложений [13]. В этом ее главное отличие от рассмотренных ранее систем.
Так же как и система KOJAK, рассматриваемая система основана на анализе взаимодействия процессов MPI. Но отличие системы KappaPI 2 в том, что в ней распознаваемые типы проблем производительности описаны в файлах в формате XML. В файлах указываются условия, при которых возникает описанная проблема, а также возможные советы для устранения этой проблемы, которые выводятся при выполнении дополнительных условий. Для вывода рекомендаций в системе реализована возможность анализа исходного кода программы.
К сожалению, в настоящее время система еще не доступна для использования. Имеются только статьи, описывающие основные принципы системы, что не позволяет в полной мере судить о ее возможностях. Также система реализована для анализа PVM программ. Но, с другой стороны, заявленные возможности позволяют решать такие задачи, как выявление проблем производительности и их причин, а также помощь в принятии решения по их устранению.
Hercule: анализ производительности
в терминах паттернов параллельного программирования
В [14] отмечается, что анализ производительности, осуществляемый многими существующими системами, является слишком низкоуровневым. В этой работе предлагается рассматривать проблемы производительности на уровне паттернов параллельного программирования. В рамках системы Hercule рассмотрены, в частности, такие модели, как «мастер-рабочие» (master-worker), «конвейер» (pipeline), «разделяй и властвуй» (divide-and-conquer). Располагая информацией о паттерне, примененном в анализируемой программе, и данными производительности, полученными в результате ее запуска, система рассчитывает различные временные параметры в терминах паттерна. Затем для диагностики проблем производительности используется специальное дерево решений, которое заранее составлено для каждого паттерна. В системе Hercule это дерево решений закодировано с помощью продукционных правил CLIPS. В [14] описан также способ составления дерева решений для любого паттерна параллельного программирования, поэтому система Hercule является расширяемой.
Таким образом, система позволяет решать задачи выявления проблем производительности
и их причин, причем информация предоставляется в терминах архитектуры программы пользователя. Доступны также рекомендации общего характера о способах по устранению обнаруженных проблем.
Сравнительный анализ рассмотренных систем
Сравнительный анализ рассмотренных систем приведен в таблице.
Таблица
Сравнительный анализ рассмотренных систем по степени автоматизации этапов процесса
повышения производительности
Название системы/ Задача процесса повышения производительности Intel Trace Collector and Analyzer Лквиш KOJAK KappaPI2 (для PVM программ) Негси1е
Анализ данных, обнаружение проблем производительности Богатые возможности графических средств; обнаружение проблем производительности выполняется пользователем Автоматическая диагностика производительности с использованием статистических данных Автоматическая диагностика проблем производительности при взаимодействии процессов Автоматическая диагностика производительно-сти в терминах паттернов параллельного программирования
Выявление причин возникновения проблем производительности Отсутствует
Принятие решения по устранению проблем производительности Отсутствует Отсутствует Отсут- ствует Выдача рекомендаций по изменению программы в результате анализа ее исходного кода Рекомендации общего характера
Итак, все системы позволяют в той или иной мере автоматизировать задачи, возникающие при повышении производительности MPI-приложений, но принципы их работы довольно сильно различаются, поэтому каждой системе присущи характерные ей сильные стороны:
• Одним из преимуществ системы Intel Trace Analyzer является высокая наглядность данных, визуализируемых на временной диаграмме.
• Преимуществом системы Aksum является высокоуровневый анализ на основе статистических данных.
• Преимуществом системы KOJAK является анализ взаимодействия процессов.
• Отличительной чертой системы KappaPI 2 является выдача рекомендаций по улучшению производительности, основанная на анализе исходного кода, а также описание типов проблем производительности в формате XML.
• Преимуществом системы Hercule является анализ производительности в терминах паттернов параллельного программирования.
Но с точки зрения пользователя все эти возможности важны. Поэтому имеет смысл разра-
ботка системы, которая обладает всеми перечисленными выше возможностями и таким образом предоставляет интегрированный подход к автоматизации диагностики проблем производительности MPI-приложений.
Также необходимо отметить, что из рассмотренных систем только Intel Trace Collector and Analyzer и KOJAK доступны для использования. Информация об остальных системах доступна только в научных статьях, что не позволяет в полной мере судить об их возможностях.
Заключение
Были рассмотрены существующие системы, позволяющие автоматизировать задачи повышения производительности MPI-приложений, и проведен сравнительный анализ этих систем. Было показано, как различные механизмы работы этих систем позволяют решать разные аспекты этих задач. В результате анализа пришли к выводу, что необходимо разработать средство, которое обладало бы интегрированным подходов к автоматизации диагностики проблем про-
изводительности MPI-приложений, а именно обладало бы следующими возможностями:
• анализ производительности на разных уровнях: высокоуровневый анализ на основе статистических данных, анализ взаимодействия процессов и анализ в терминах паттернов параллельного программирования;
• визуализация найденных проблем производительности с использованием временной диаграммы;
• выдача рекомендаций по улучшению производительности;
• возможность легкого описания типов проблем производительности без модификации исходного кода системы.
Список литературы
1. Lilja J.D. Measuring computer performance: a practitioner’s guide. N.Y., 2000. 278 p.
2. Foster I. Designing and Building Parallel Programs: Concepts and Tools for Parallel Software Engineering. Boston, 1995. 381 p.
3. Intel Trace Analyzer. Reference Guide [Электронный ресурс] // Intel Software Network : сайт. -URL: http://software.intel.com/en-us/articles/intel-trace-analyzer-and-collector-documentation/ (дата обращения
15.09.2010)
4. Collette M., Corey B., Johnson J. High Performance Tools & Technology // Technical Report. Lawrence Livermore National Laboratory, US. Dept. of Energy. 2004.
5. William G., Ewing L. Tuning MPI programs for peak performance [Электронный ресурс] // Argonne National Laboratory : сайт. - URL: http://www.mcs.anl. gov/research/projects/mpi/tutorials/perf/ (дата обращения 15.09.2010).
6. Barney B. MPI Performance Topics [Электронный ресурс] // High Performance Computing. Lawrence
Livermore National Laboratory : сайт. - URL: https:// computing.llnl.gov/tutorials/mpi_performance/ (дата обращения 15.09.2010).
7. Rabenseifner R. Optimization of MPI Applications [Электронный ресурс] // High Performance Computing Center Stuttgart : сайт. - URL: https://fs.hlrs. de/projects/par/par_prog_ws/engl/mpi_optimize_3/index .html (дата обращения 15.09.2010).
8. Fahringer T., Gerndt M., Mohr B., Wolf F., Riley G., Traff J.L. Knowledge Specification for Automatic Performance Analysis. APART Technical Report [Электронный ресурс] // Julich Supercomputing Centre : сайт. - URL: http://www.fz-juelich.de/jsc/docs/autoren 2001/fahringer/.
9. Intel Trace Collector. Reference Guide [Электронный ресурс] // Intel Software Network : сайт. -URL: http://software.intel.com/en-us/articles/intel-trace-analyzer-and-collector-documentation/ (дата обращения
15.09.2010)
10. Fahringer T., Seragiotto C. Aksum: a performance analysis tool for parallel and distributed applications // Performance analysis and grid computing, 2004. P. 189-208.
11. Wolf F., Mohr B. Automatic performance analysis of hybrid MPI/OpenMP applications // Journal of Systems Architecture: the EUROMICRO Journal, Vol. 49. Issue 10-11. 2003. P. 421-439.
12. Hermanns M. Verifying Causal Connections between Distant Performance Phenomena in Large-Scale Message-Passing Applications // Proceedings of the 2009 17th Euromicro International Conference on Parallel, Distributed and Network-based Processing, 2009. P. 78-84.
13. Jorba J., Margalef T., Luque E. Search of Performance Inefficiencies in Message Passing Applications with KappaPI 2 Tool // Proceedings of the 8th international conference on Applied parallel computing: state of the art in scientific computing, 2006. P. 409-419.
14. Li L., Malony A.D. Knowledge engineering for automatic parallel performance diagnosis // Concurrency and Computation: Practice & Experience, Vol. 19. Issue
11. 2007. P. 1497-1515.
A REVIEW OF RESEARCH IN THE FIELD OF DIAGNOSIS AUTOMATION OF MPI APPLICATION
PERFORMANCE
A.V. Dergunov, S.N. Karpenko
A review of investigations on diagnosis automation of MPI application performance is presented. We also estimate how these results can help to improve the performance.
Keywords: parallel programming, MPI, performance analysis.