CC BY
47
УДК 004.051
Н. Е. Андреев
Кемеровский государственный университет ул. Красная, 6, Кемерово, 650043, Россия E-mail: [email protected]
МЕТОДЫ АВТОМАТИЗИРОВАННОГО АНАЛИЗА ПРОИЗВОДИТЕЛЬНОСТИ
ПАРАЛЛЕЛЬНЫХ ПРОГРАММ
Согласно отчету Межведомственной комиссии по развитию сверхмощных вычислений США, эффективность современных параллельных систем находится ниже отметки в 10 %. Для того, чтобы добиться приемлемой эффективности, разработчики пользуются инструментами поиска и устранения проблем производительности. Большая часть таких инструментов полагаются на пользователя при анализе и интерпретации данных, но есть ряд систем, позволяющих в той или иной мере автоматизировать этот процесс и снизить нагрузку на пользователя. Именно таким инструментам и методам, которые они реализуют, посвящена данная статья.
Ключевые слова: параллельное программирование, трассировка, оценка производительности, эффективность, автоматизация, оптимизация.
Введение
Компьютер, пожалуй, самая сложная машина, созданная когда-либо человеком, а параллельный компьютер, в свою очередь, самая сложная компьютерная система. Она была создана для поддержки одновременных вычислений, но, несмотря на то, что одновременные события - явление обычное для окружающего нас мира, запрограммировать одновременность на компьютере не просто даже для простых, на первый взгляд, задач. Главное преимущество параллельных систем заключается в поддержке одновременного выполнения параллельных операций с целью достижения высокой производительности. Получение высокой эффективности в процессе выполнения программы еще более усложняет использование параллельных систем. Согласно отчету Межведомственной комиссии по развитию сверхмощных вычислений США, эффективность современных параллельных систем находится ниже отметки в 10 % \ Рынок сверхмощных вычислений просто не настолько велик, чтобы отвлечь внимание компьютерной индустрии от более крупных и более прибыльных секторов электронной коммерции и бизнес-расчетов. Продажи в сфере высокопроизводительных вычислений составляют примерно 1 млрд долларов, тогда как на рынке серверов - более 50 млрд. Так как индустрия сосредоточена на доходном серверном рынке, предложения в области высокопроизводительных вычислений представляют собой совокупность большого количества процессоров, разработанных для более мелких систем. Такие массивные мультипроцессорные системы исключительно сложны в программировании и достижении высокого уровня производительности для определенного класса приложений. Рис. 1 иллюстрирует постоянно растущее несоответствие между теоретической пиковой производительностью суперкомпьютеров и производительностью на реальных приложениях. На рис. 1 представлены результаты теста, разработанного в Национальном исследовательском центре научных расчетов в области энергетики (NERSC), который расположен в Национальной лаборатории Лоуренса в Беркли, специально для оценки производительности приложений, использующихся в центре. Постоянные технологические улучшения микропроцессоров, подталкиваемые законом Мура, приводят к резкому росту верхней кривой теоретической пиковой производительности. Тем не менее, в результате мультипроцессоры становятся все менее сбалансированными. С каждым годом растет дисбаланс между скоростью процессоров и пропускной способностью памяти. Этот дисбаланс приводит к низкому росту кривой производительности на реальных приложениях.
1 См. подробнее: Federal plan for high-end computing: Report of the High-end computing revitalization task force (HECRTF) - http://www.nitrd.gov/pubs/2004_hecrtf/20040702_hecrtf.pdf.
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2009. Том 7, выпуск 1 © Н. Е. Андреев, 2009
В условиях резкой нехватки производительности программистам необходимы инструменты анализа эффективности и оптимизации программ. Разработка и реализация таких инструментов для параллельных компьютеров очень сложна, ввиду как архитектурной, так и эксплуатационной сложности таких систем. Общие требования к таким программам следующие:
• скрывать модель системы и брать на себя низкоуровневые операции по управлению системой, чтобы упростить процесс оптимизации программы;
• быть чувствительными к ограничениям, накладываемым задачей, на объем получаемой информации о системе;
• извлекать важные для анализа метрики системы;
• учитывать возможные возмущения системы, возникающие при оснащении (добавлении меток, снимающих метрики производительности) программы или искажения результатов моделирования, возникающие ввиду той или иной степени абстракции от физической системы.
Годы
Теор. - пиковая производительность;
Реал. - производительность на реальных приложениях.
Рис. 1. Расхождение теоретической и реальной производительности
Полезность инструментального средства определяется точностью моделирования системы, на которой оно базируется, а также способностью захватывать необходимую информацию о состоянии системы с определенной точностью и степенью детализации. Ввиду сложности параллельных платформ это знание достаточно непросто извлечь. Возможно самый важный аспект инструмента - это способность к разрешению проблем производительности. Он может оказать неоценимую помощь в нахождении и устранении проблем параллельных программ, если он поддерживает возможность мониторинга состояний программы и системы, но такие инструменты могут сами влиять на систему в процессе измерений, необходимых для последующего анализа. В худшем случае возмущение поведения системы может достигать такого уровня, когда наблюдения будут ненадежны, а модели, в которых эти данные используются, приведут к неправильным выводам.
Инструменты анализа производительности
Анализ производительности - ключевой аспект, на который следует обращать внимание при разработке инструментов данного класса. То, как инструмент способен анализировать приложение, играет важную роль в его признании. В идеале такая программа должна не только показывать данные в интуитивно понятном виде, но и помогать пользователю детализировать интересующую его информацию так, чтобы возникшие узкие места и проблемы производительности могли быть легко выявлены.
Adam Leko в статье «Performance Analysis Strategies» 2 приводит эталонный процесс отладки производительности (рис. 2). Сначала пользователь добавляет в свою программу изме-
2 Leko A. Performance Analysis Strategies: http://www.hcs.ufl.edu/prj/upcgroup/upcperf/documents/20050302-AnalysisDraft.pdf.
рительный код (желательно без особых усилий), запускает его и далее подает полученные в процессе выполнения данные в программу анализа. Программа должна помочь пользователю найти и исправить проблемы производительности исходной программы. Этот процесс повторяется до тех пор, пока пользователь не добьется приемлемого уровня производительности. Измерительный код должен вносить низкий процент накладных расходов на выполнение пользовательской программы и собирать достаточный объем данных, чтобы выявить любую проблему производительности. Процесс анализа в идеале должен быть автоматизирован настолько, насколько это возможно, и выполнен полно и точно после того, как все необходимые данные были собраны в процессе выполнения программы. В реальности не существует инструментов, которые бы следовали этому процессу в таком виде. Зачастую они поддерживают его частично, балансируя между функциональностью, накладными расходами на выполнение и простотой использования. Современные системы настолько сложны, что собрать информацию, достаточную для выявления любой проблемы производительности, невозможно без серьезного влияния на скорость выполнения программы, что сводит на нет полезность такой информации. Даже когда удается собрать достаточно полную информацию без изменения характеристик выполнения программы, большой объем и различный тип информации создают проблемы объединения ее в единое целое, что затрудняет анализ данных.
Рис. 2. Цикл отладки производительности
Таким образом, реальные инструменты анализа производительности должны решить, какие данные они будут собирать, и должны быть способны проводить анализ и фильтрацию даже недостаточно полной и точной информации. Фактически это означает, что фильтрация и анализ могут (а иногда должны) проводиться на разных этапах отладки производительности, вместо фиксированного, как показано на рис. 2.
Существующие методики можно разделить следующим образом:
• предварительный анализ, интерактивные методы и постобработка. Методы предварительного анализа выполняют оценку до непосредственного запуска программы, интерактивные методы выполняют анализ в процессе работы прикладной программы. Постобработка -это метод, который требует наличия полной информации, получаемой в процессе выполнения программы, перед тем, как анализ поведения этой программы может быть запущен;
• ручные и полуавтоматические методы. Некоторые стратегии анализа и поиска узких мест могут быть в той или иной степени автоматизированы, другие полностью полагаются на пользователя при анализе и интерпретации данных.
Данные категории не взаимоисключающие. Некоторые стратегии могут основываться на комбинации вышеописанных методов. Таким образом, инструменты можно условно разделить на шесть категорий: постобработка, интерактивный метод и предварительный анализ в ручном и полуавтоматическом вариантах.
Необходимо заметить, что в методе ручного анализа трудоемкий процесс поиска узких мест производительности выполняется пользователем. Инструменты, использующие данный метод, полагаются полностью на представление пользователю соответствующих диаграмм, графиков и таблиц и методы манипулирования ими (масштабирование и поиск). Представление информации о производительности программы в графическом виде может быть мощным приемом, но без сложных методов фильтрации объем отображаемых данных может быть чрезвычайно большим.
Чтобы привести пример того, как объем данных может стать чрезвычайно большим, посмотрим, как выглядит визуализация бенчмарка NAS LU (нагрузка класса B) в Jumpshot-4 (рис. 3).
Рис. 3. Визуализации теста NAS LU в Jumpshot-4
В данном примере отсутствует какая-либо фильтрация данных. Размер трассировочного файла для трех минут выполнения составляет 325 Мб. Как видно из рисунка, очень сложно разглядеть, что же происходит в программе из-за большого количества коммуникаций, даже несмотря на то, что 32-процессорная система считается небольшой по сегодняшним меркам. Чтобы справиться с этой проблемой, инструменты, работающие с файлами трасс и предоставляющие лишь методы ручного анализа, зачастую позволяют осуществлять поиск, фильтрацию и масштабирование, чтобы ограничить объем отображаемых данных. Например, многие инструменты визуализации трасс MPI позволяют пользователю ограничить отображаемые передачи сообщений при помощи выбора тэга или источника и назначения. Тем не менее, большинство инструментов, использующих ручной анализ при помощи трасс, не позволяют отобразить полученные данные обратно на исходный код, так как сложно увя-
зать эту информацию с временной шкалой. За выбор фильтров в данном методе также ответственен пользователь.
Методы полуавтоматического анализа
Очевидно, что машины гораздо более приспособлены к обработке больших массивов информации. С учетом этого некоторые разработчики создали прототипы систем, которые пытаются автоматизировать процесс поиска проблем производительности настолько, насколько это возможно. Есть несколько реализованных прототипов, которые способны выполнять нечто похожее на автоматический анализ собранных в процессе выполнения программы данных. Большинство стратегий используют приемы и методы из области искусственного интеллекта, такие как экспертные системы на основе баз знаний и методы автоматической классификации. Далее в статье будут рассмотрены несколько инструментов, в основе которых лежат методы полуавтоматической постобработки.
IPS-2
IPS [Miller et al., 1990] - это одна из ранних программ, первые публикации о которой датируются 1987 г. Разрабатывалась Висконсин-Мэдисонским университетом совместно с Bell Laboratories для систем, работающих на микропроцессорах VAX, DECStation и Sun 4 под управлением ОС 4.3BSD UNIX. IPS представляет собой распределенный программный комплекс для анализа программ, как для распределенных систем, так и систем с общей памятью. Программист начинает работу с запуска графического интерфейса, где он добавляет узлы параллельного компьютера, указывает для каждого узла исполняемый файл и запускает задачу на выполнение. Система сама выполняет оснащение программы и передачу двоичных файлов на расчетные узлы. Накопленные в процессе работы программы файлы трасс проходят предварительную обработку дочерними аналитическими модулями на расчетных узлах, после чего передаются родительскому модулю, который агрегирует данные и представляет их в графическом виде пользователю. Представление данных выполнено в IPS в иерархическом виде. Верхний уровень иерархии - программа. На данном уровне она представлена черным ящиком, который подает данные в систему и получает результат. Известны только общие сведения о программе, например, совокупное время выполнения, детали скрыты. На машинном уровне программа состоит из нескольких процессов, которые одновременно работают на различных узлах параллельного компьютера. Здесь можно посмотреть суммарную информацию по каждому узлу и коммуникациям между узлами. На машинном уровне ничего не известно о деятельности процессов внутри узла. Эта информация раскрывается на уровне процессов, где распределенная программа представлена совокупностью взаимодействующих процессов. Здесь можно рассматривать группы процессов, работающих внутри машины, или выйти за рамки одной машины и взглянуть на все процессы в совокупности. На уровне процедур программа представляет собой последовательную цепь вызовов процедур по каждому из процессов, а на уровне примитивной активности отслеживаются операции синхронизации, отправки и приема сообщений, создания и уничтожения процессов и т. д. Данный подход позволяет пользователю выбрать тот уровень абстракции, который его интересует, что значительно сокращает объем анализируемой информации. Наряду с представлением пользователю сгруппированных метрик производительности, в IPS используется несколько методов автоматизированного анализа программ: анализ критического пути и анализ фазового поведения.
Анализ критического пути (АКП) позволяет найти самый длинный по времени путь, через который параллельная программа проходит в процессе своего выполнения. Чтобы провести АКП, на основе трассировочной информации строится граф операций программы. Вершины графа - события, например, межпроцессные коммуникации или создание процессов, а дуги -время, затраченное на выполнение события. По ходу взаимодействия процессов друг с другом возникают различные пути, оптимизация самого длительного из которых приведет к сокращению общего времени выполнения программы. После того как граф операций построен, выполняется поиск самого длинного пути. Путь может состоять из тысяч вершин, поэтому на каждом из уровней иерархии информация пользователю представляется в агрегированном
виде. Например, на уровне процессов, какой процент времени критического пути программа выполняла расчеты и какой - межпроцессные коммуникации, для каждой пары процессов. IPS не позволяет рассчитывать пути близкие к критическому. Если существуют пути близкие по времени и практически не пересекающиеся с критическим, то оптимизация не даст результатов. Для того чтобы определить, какое влияние на программу окажет оптимизация критического пути, IPS позволяет приравнять его к нулю и пересчитать оценку.
Анализ фазового поведения (АФП) [Miller et al., 1990] - это метод, способный выделить различные фазы выполнения программы. Например, в параллельной программе, работающей по схеме главный - подчиненный, можно выделить следующие фазы: 1) главный процесс ставит задачу; 2) инициализируются подчиненные процессы; 3) главный распределяет части задачи каждому подчиненному; 4) подчиненный рассчитывает свою часть задачи; 5) главный объединяет частичные результаты. Шаги 3-5 повторяются, пока не получено решение. Каждая фаза имеет свои характеристики. Задача АФП - автоматически выделить эти фазы, что позволит в дальнейшем выполнять оптимизацию, сосредоточившись на определенной фазе. АФП состоит из трех этапов: сглаживания, сегментации и комбинирования. На вход метода подаются кривые метрик производительности, которые представляют собой значение метрики в различные моменты времени выполнения программы. Задача сглаживания - упростить последующий анализ за счет устранения пиков. Сглаживание выполняется по алгоритму скользящего окна. После сглаживания выполняется сегментация. Задача сегментации - построить кривую границ, которая для каждой метрики производительности т показывала бы вероятность возникновения перехода фаз для каждого момента времени t t. Для этого сначала строится ступенчатая функция hm ., которая для момента времени t t равна разнице между
значениями предыдущего минимума (максимума) и следующего максимума (минимума) кривой метрики m . Далее строится кривая границ, которая имеет следующий вид: АУт1
Бт . = abs(——) х h ., где АV . - разница между значениями метрики т в моменты време-
, At, , , ни tt и ti_1. Чем больше значение Бт t, тем выше вероятность, что в данной точке кривой находится переход фаз. После того как кривые границ для каждой метрики посчитаны, они объединяются в итоговой функции, учитывающей все метрики производительности:
фаз, если первая производная от В { равна нулю и В { выше определенного порогового значения. Пороговое значение выставляется программистом вручную. Чем пороговое значение выше, тем меньше фаз и наоборот. После того, как фазы получены, программист получает возможность более гибко и оптимально выполнять оптимизацию программы. Например, он может применить АКП к определенной фазе.
Иной подход используется в пакете SCALEA [Truong et al., 2001] - инструменте анализа производительности для программ, написанных на OpenMP, MPI, HPF и смешанных параллельных / распределенных программах. На первом этапе препроцессор SCALEA строит абстрактное синтаксическое дерево (АСД) программы, что позволяет пользователю выбрать интересующие его блоки кода, будь то обычные циклы, процедуры, циклы HPF INDEPENDENT, циклы OpenMP PARALLEL, секции OpenMP, операции MPI Send/Recv или что-либо другое. Если необходимо выбрать произвольную область кода, можно воспользоваться специальными директивами, которые вручную помещаются в исходный код программы. Для каждого анализируемого блока кода формируется файл описания инструментовки, который содержит идентификатор блока, информацию о его местоположении в исходном коде и ссылку на собранную информацию о производительности. Это позволяет уменьшить объем трассировочной информации за счет того, что служебная информация в каждой строчке трассы сокращается до единственного идентификатора, а также четко отображать данные анализа на исходный код программы. После того как инструментовка закончена, программа
Считается, что в момент времени tt происходит переход
SCALEA
запускается и в процессе ее выполнения собирается трассировочная информация, а также показатели аппаратных счетчиков. Обработка собранной информации выполняется в два этапа. Вначале данные проходят первичную фильтрацию и строится динамический граф вызовов блоков кода (ДГБ). ДГБ для программы Q задается направленным графом потоков G = (R, E, s), где R - множество узлов, а E - множество дуг. Узел r e R представляет собой блок кода, который хотя бы единожды выполняется в процессе работы программы Q . Дуга (r, r2) e E указывает, что при выполнении программы Q блок кода r2 вызывается внутри r, r2 в таком случае - динамический подблок r1 . Блок кода, с которого начинается выполнение Q, задается s. ДГБ позволяет структурировать данные о производительности программы и точно рассчитать издержки на те или иные операции по каждому блоку на основе информации из подблоков там, где это необходимо. После того, как ДГБ построен и трассы распределены по соответствующим блокам, начинается непосредственно анализ производительности. SCALEA выполняет анализ в форме поиска издержек выполнения программы. С точки зрения программиста коммуникации MPI Send/Recv можно считать издержками на перемещения данных, которых в последовательной программе нет, а циклы процессора, которые тратятся на создание и уничтожение нитей в OpenMP при входе в параллельную секцию - издержками на управление параллелизмом. Согласно закону Амдала [Amdahl, 1967], теоретически лучший последовательный алгоритм требует времени Ts для того, чтобы выполнить программу, Tp - время, необходимое для выполнения параллельной версии на р-процессорах. Тогда временные издержки могут быть заданы как To = Tp - Ts / p и отражают разницу между достигнутой и оптимальной производительностью. To , в свою очередь, можно разделить на T и Tu таким образом, что To = Ti + Tu, где Ti - это издержки, которые можно установить, а Tu - это часть издержек, которую не удается детально проанализировать. В SCALEA выделяется 6 групп издержек:
• перемещения данных - любые передачи данных внутри адресного пространства процесса (доступ к локальной памяти) или между процессами (доступ к удаленной памяти);
• синхронизация (например, барьеры и блокировки) - это операции, координирующие работу процессов и нитей при доступе к данным, для поддержания целостности данных и вычислений;
• управление параллелизмом (например, fork/join операции и диспетчеризация циклов) используется для регулирования и управления параллелизмом программы и может осуществляться пользователем, компилятором или библиотекой времени выполнения;
• дополнительные вычисления отражают любые изменения исходной последовательной программы, включая изменения алгоритма и трансформации компилятора, с целью увеличения параллелизма (например, устранение зависимостей по данным) или локальности данных (например, при помощи изменения шаблонов доступа к данным);
• потеря параллелизма ввиду неполного распараллеливания программы, которую можно дальше классифицировать как нераспараллеливаемый код (выполняемый только одним процессором), дублированный код (выполняемый всеми процессорами) и частично распараллеливаемый код (выполняемый более чем одним процессором, но не всеми);
• неидентифицированный параллелизм относится к издержкам, неохватываемым вышеописанными категориями.
Для того чтобы подсчитать издержки, SCALEA строит ДГБ для последовательной и параллельной версии программы и сравнивает соответствующие регионы кода двух версий. Обозначим ДГБ параллельной и последовательной версий - DRGs (Vs, Es, ss ) и DRGp (Vp, Ep, sp )
соответственно. Для региона кода Rp в DRGp найдем соответствующий Rp регион в DRGs. Предположим, что это регион R*. Положим, что Ts (R° ), Tp (Rp ) и To (Ri ) - это время выполнения последовательной версии, время выполнения параллельной версии и полученные из-
держки. Тогда накладные расходы рассчитываются следующим образом: To(R) = Tp(Rp)-Ts(R)/p .
EXPERT (Extensible Performance Tool)
EXPERT [Wolf, 2005; 2000] - это один из популярных инструментов, который также использует подход баз знаний для поиска узких мест параллельных программ. EXPERT в своем подходе позволяет отделить сам процесс анализа от описания шаблонов неэффективного поведения, имеет модульную архитектуру и расширяем. EXPERT - это модуль анализа, который входит в состав набора инструментов KOJAK (Kit for Objective Judgement and Knowledge-based Detection of Performance Bottlenecks), который автоматически выполняет оценку производительности программ, написанных на C/C++ или Fortran с использованием MPI, OpenMP или смешанного подхода. В качестве источника данных используются файлы трасс. Инструментовка программы может быть выполнена автоматически при помощи профилировочного интерфейса компилятора, с помощью TAU (Tuning and Analysis Utilities) [Shende, 2001] или DPCL (Dynamic Probe Class Library) [DeRose и др., 2001]. Если необходимо, пользователь может оснастить произвольные блоки кода при помощи POMP директив, которые потом обрабатываются пакетом OPARI (OpenMP Pragma And Region Instrumentor) [Mohr и др., 2002]. OPARI используется также для автоматического оснащения OpenMP программ. Инструментовка MPI директив выполняется автоматически библиотекой-оберткой. После того как данные о работе программы собраны, они передаются в модуль анализа EXPERT.
В процессе анализа EXPERT ищет в трассировочных файлах шаблоны неэффективного поведения. То, как EXPERT представляет эти шаблоны внутри себя, позволяет ему фиксировать очень сложные ситуации, не охватываемые профилировочными инструментами и ви-зуализаторами трасс. EXPERT описывает шаблоны в виде составных событий. Составное событие - это набор найденных в трассировочном файле событий, которые удовлетворяют условиям возникновения ситуации, описываемой шаблоном. Так как составные события обычно включают в себя сложные меж-событийные связи, необходимы высокоуровневые структуры данных, которые способны отслеживать и предоставлять в нужный момент такую информацию. Поэтому EXPERT построен на базе языка EARL (Evaluation and Report Language) [Wolf, 2004] доступа к трассировочным файлам. Основная задача EARL - упростить описание шаблонов неэффективного поведения, что позволяет легко расширять и корректировать набор шаблонов, используемых в процессе анализа. В отличие от необработанного файла трасс, который позволяет считывать записи в последовательном виде, EARL обеспечивает произвольный доступ к различным событиям и два типа абстракций: состояния и указатели. Состояния отражают различные аспекты общего состояния выполнения программы. Каждое состояние - это множество событий. Появление события приводит к добавлению либо удалению элемента из множества. Например, для каждой пары процессов EARL поддерживает очередь сообщений. Если возникает событие отправки сообщения, оно добавляется в очередь, если возникает событие приема, то соответствующее ему событие отправки удаляется из очереди. EARL также поддерживает состояния для коллективных коммуникаций MPI, операций OpenMP parallel, синхронизаций на основе блокировок, стеков блоков кода и дерева вызовов. Указатели - это атрибуты событий, ссылающиеся на другое соответствующее событие. Например, событие приема содержит атрибут sendptr, который указывает на соответствующее ему событие отправки. Наличие указателей дает возможность воспользоваться состояниями. Другие указатели связывают соответствующие события входа и выхода, операции над одной и той же переменной синхронизации и информацию о порядке вызовов. Состояния и указатели формально описаны в [Wolf, 2003], а исчерпывающая документация по EARL API может быть найдена в [Wolf, 2004].
В процессе анализа поведения приложения EXPERT последовательно перебирает файлы трасс и пытается найти шаблоны, описанные ранее в виде составных событий. Для того чтобы проиллюстрировать, как описываются и обнаруживаются составные события, обратимся к рис. 4, на котором в виде временной шкалы изображено составное событие поздняя отправка. Процесс A ожидает сообщения от процесса B, которое отправлено гораздо позже на-
чала операции приема. Таким образом, большая часть времени, потраченная операцией приема, фактически время простоя, которое может быть использовано с пользой. EXPERT распознает этот шаблон, ожидая операции приема в потоке событий. Как только такое событие поймано, EXPERT при помощи указателей (пунктирные линии на рисунке), подсчитанных EARL, находит моменты входа обоих коммуникационных операций и определяет смещение (idle time на рисунке). Из рисунка также видно, что шаблона поздняя отправка можно избежать, поменяв порядок приема сообщений. Так как сообщение от процесса C отправлено раньше B, оно в любом случае достигнет процесса A раньше. Поэтому вместо того, чтобы ждать сообщения от процесса B, A может провести это время с пользой. В данном контексте шаблон поздняя отправка называется поздняя отправка / неправильный порядок. EXPERT распознает эту ситуацию, просмотрев состояние выполнения, подсчитанное EARL, на момент приема процессом A сообщения от процесса B. Проверка очереди сообщений, отправленных A, показывает, что есть более старые сообщения, чем только что принятое.
□ Сход В Выход
Q Отправка
ф прием MPISend
М Pljtecv
Сообщение sendptr
L'iltL'iplT
Рис. 4. Составное событие поздняя отправка / неправильный порядок
На основе описанного подхода EXPERT позволяет выявить ряд накладных расходов на выполнение параллельного приложения, которые можно разбить на две группы. Первая состоит преимущественно из суммарной информации, полученной в результате профилировки. Вторая включает в себя времена ожидания, которые могут быть получены только при помощи подробного сравнения временных связей между определенными блоками. В процессе анализа, при нахождении соответствия тому или иному шаблону, определяется точность и важность. Точность определяет, с какой степенью точности было сделано предположение о соответствии данному шаблону, а важность говорит о том, насколько важна информация, накопленная по одному шаблону по отношению к другому. EXPERT позволяет: вычислить стоимость коммуникаций, синхронизации и стоимость операций ввода\вывода; выявить преобладающую и самую частую операции коммуникации, большие сообщения, наличие неравномерного распределения и разбалансировку на барьерной операции. Также в поле зрения метода попадают такие сложные события, как поздняя отправка, поздний прием, неправильный порядок сообщений и несколько событий из парадигмы главный - подчиненные.
Заключение
В данной статье был представлен ряд методов, реализованных в инструментах автоматизированного анализа и отладки производительности параллельных приложений. Подавляющее большинство современных инструментов идут по пути наименьшего сопротивления, давая возможность пользователю вручную фильтровать и просматривать полученные в процессе сбора данные. Инструменты, рассмотренные в статье, выпадают из этого списка. Они реализуют в себе сложные подходы, которые позволяют значительно снизить нагрузку на пользователя в процессе анализа приложения и повысить результативность данного процесса. Полагаясь только на временные шкалы и профилировку, программист рискует пропустить действительные причины низкой эффективности его приложения. Большинство утилит анализа базируются на постобработке трасс. Причиной тому - легкость реализации и удобство для пользователя. Также большинство разработчиков признает крайнюю важность вовле-
чения пользователя в процесс анализа. Хотя некоторые пытаются (со временем) полностью избавить его от утомительного анализа и оптимизации, проблема оптимизации изучена не настолько глубоко. Поэтому любой метод, выходящий за рамки простого анализа масштабируемости, предполагает вмешательство пользователя и раз так, инструмент, реализующий данный подход, должен обеспечить пользователя интерфейсом должного уровня.
Список литературы
Amdahl D. Validity of the single-processor approach to achieving large-scale computer capabilities // Proc. of the AFIPS Conference. 1967. P. 483-485.
Miller B. P., ClarkM., Hollingsworth J., Kierstead S., Lim S. S., Torzewski T. IPS-2: The second generation of a parallel program measurement system // IEEE Trans. Parallel Distrib. Syst. 1990. Vol. 1. № 2. P. 206-217.
Truong H. L., Fahringer T., Madsen G., Malony A. D., Moritsch H., Shende S. On using scalea for performance analysis of distributed 21 and parallel programs // Supercomputing'01: Proceedings of the 2001 ACM/IEEE conference on Supercomputing (CD-ROM). ACM Press, 2001. P. 34-34.
Truong H. L., Fahringer T. Scalea - a performance analysis system for distributed and parallel programs // Technical report, Institute for Software Science. University of Vienna, Liechtensteinstr. 22, A-1090 Vienna, Austria, April, 2001.
Wolf F., Mohr B., Dongarra J., Moore S. Automatic search for patterns of inefficient behavior in parallel applications // Submitted to Concurrency Practice and Experience by Jack Dongarra. February, 2005.
Wolf F., Mohr B. Automatic performance analysis of MPI applications based on event traces // Euro-Par'00: Proceedings from the 6th International Euro-Par Conference on Parallel Processing. Springer-Verlag, 2000. P. 123-132.
Shende S. S. The Role of Instrumentation and Mapping in Performance Measurement: PhD thesis. University of Oregon, August, 2001.
DeRose L., Hoover T. Jr., Hollingsworth J. K. The Dynamic Probe Class Library - An Infrastructure for Developing Instrumentation for Performance Tools // Proceedings of the 15 th International Parallel and Distributed Processing Symposium (IPDPS'01). 2001. Vol. 1.
Mohr B., Malony A., Shende S., Wolf F. Design and Prototype of a Performance Tool Interface for OpenMP // The Journal of Supercomputing. August, 2002. Vol. 23. P. 105-128.
Wolf F. EARL - API Documentation // Technical Report ICL-UT-04-03. University of Tennessee, Innovative Computing Laboratory, October, 2004.
Wolf F. Automatic Performance Analysis on Parallel Computers with SMP Nodes: PhD thesis. RWTH Aachen, Forschungszentrum Julich, February, 2003.
Материал поступил в редколлегию 26.11.2008
N. E. Andreev
AUTOMATED METHODS OF ANALYZING PARALLEL APPLICATIONS PERFORMANCE
According to the report of the USA High-end computing revitalization task force (HECRTF) sustained performance of contemporary parallel machines is less than 10 %. To gain acceptable parallel performance programmers often use performance analysis instruments. Most of them entirely rely on developer in finding parallel performance problems but some automate this process more or less. This paper is dedicated to such kind of instruments.
Keywords: parallel programming, tracing, performance evaluation, effectiveness, automation, optimization.
