Загрузка...
Учебная работа. Дипломная работа: Анализ эффективности MPI-программ
1.Введение.3
2. Обзор имеющихся моделей параллельного программирования.5
3. Обзор средств отладки эффективности MPI-программ. 9
3.1 Общие задачи всех средств трассировки.10
3.2 Обзор главных средств отладки.11
3.2.1 AIMS — Automated Instrumentation and Monitoring System.. 11
3.2.2Vampir, VampirTrace. 12
3.2.3Jumpshot14
3.2.4Pablo Performance Analysis Toolkit Software. 15
3.2.5Paradyn. 17
3.2.6CXperf18
4. свойства и методика отладки DVM-программ.20
4.1Основные свойства производительности. 20
4.2методика отладки эффективности. 22
4.3Рекомендации по анализу.23
5. Средство анализа эффективности MPI программ.27
5.1.Постановка задачки.27
5.2Этапы работы анализатора.28
5.3Устройство анализатора.29
5.3.1Сбор трассы.. 29
5.3.2анализ.30
5.3.3Визуализация. 35
Заключение.37
Перечень литературы.. 39
Приложение 1.40
приложение 2.40
1.Введение
Сейчас нереально представить для себя эффективную компанию работы без внедрения компов в таковых областях, как планирование и управление созданием, проектирование и разработка сложных технических устройств, издательская деятельность, образование — словом, во всех областях, где возникает необходимость в обработке огромных размеров инфы. Но более принципиальным как и раньше остается внедрение их в том направлении, для которого они фактически и создавались, а конкретно, для решения огромных задач, требующих выполнения большенных размеров вычислений. Такие задачки появились посреди прошедшего века в связи с развитием атомной энергетики, авиастроения, ракетно-космических технологий и ряда остальных областей науки и техники.
В наше время круг задач, требующих для собственного решения внедрения массивных вычислительных ресурсов, еще наиболее расширился. Это соединено с тем, что произошли фундаментальные конфигурации в самой организации научных исследовательских работ. Вследствие широкого внедрения вычислительной техники существенно усилилось направление численного моделирования и численного опыта. Численное моделирование, заполняя просвет меж физическими тестами и аналитическими подходами, позволило учить явления, которые являются или очень сложными для исследования аналитическими способами, или очень дорогостоящими либо небезопасными для экспериментального исследования. При всем этом численный сделалось вероятным моделировать в настоящем времени процессы интенсивных физико-химических и ядерных реакций, глобальные атмосферные процессы, процессы экономического и промышленного развития регионов и т.д. Разумеется, что решение таковых масштабных задач просит значимых вычислительных ресурсов[12].
Вычислительное направление внедрения компов постоянно оставалось главным движком прогресса в компьютерных разработках. Не умопомрачительно потому, что в качестве главный свойства компов употребляется таковой показатель, как
— величина, показывающая, какое количество арифметических операций он может выполнить за единицу времени. Конкретно этот показатель с большей очевидностью показывает масштабы прогресса, достигнутого в компьютерных разработках.
В истинное время основным направлением увеличения производительности ЭВМ является создание многопроцессорных систем с распределенной памятью. Создание прикладных программ для схожих распределенных систем наталкивается на ряд суровых проблем. Разработка параллельной программки просит выбора либо сотворения пригодного вычислительного способа. При всем этом для заслуги требуемой эффективности приходится неоднократно проходить путь от спецификации метода к программке на языке программирования, который для параллельных вычислительных систем оказывается еще наиболее сложным, чем для поочередных.
При переходе от 1-го микропроцессора к нескольким резко растет сложность программирования. И почти все классические подходы тут уже не работают. Причём если на мультипроцессорной системе довольно верно распределить вычисления, то в случае распределённой системы нужно ещё распределить данные, и самое основное, необходимо, чтоб распределение данных и вычислений было согласованным.
одной из главных заморочек является неувязка эффективности компьютерной программки. Принципиально созидать, какой эффект дает распараллеливание нашей программки и что можно создать, чтоб максимизировать этот эффект.
Эффективность выполнения параллельных программ на многопроцессорных ЭВМ с распределенной памятью определяется последующими главными факторами:
· степенью распараллеливания программки — толикой параллельных вычислений в общем объеме вычислений;
· равномерностью загрузки микропроцессоров во время выполнения параллельных вычислений;
· временем, нужным для выполнения межпроцессорных обменов;
· степенью совмещения межпроцессорных обменов с вычислениями;
· эффективностью выполнения вычислений на любом микропроцессоре (а она может варьироваться существенно зависимо от степени использования кэша).
способы и средства отладки производительности параллельной программки значительно зависят от той модели, в рамках которой разрабатывается параллельная программка.
2. Обзор имеющихся моделей параллельного программирования
Для организации доступа к данным на многопроцессорных ЭВМ требуется взаимодействие меж её микропроцессорами. Это взаимодействие может происходить или через общую память, или через механизм передачи сообщений – две главные модели параллельного выполнения программки
. Но эти модели являются достаточно низкоуровневыми. Потому основным недочетом выбора одной из их в качестве модели программирования
будет то, что таковая модель непривычна и неудобна для программистов, разрабатывающих вычислительные программки.
Можно отметить системы автоматического распараллеливания, которые полностью удачно использовались на мультипроцессорах. А внедрение этих систем на распределённых системах значительно затруднено тем, что
Во-1-х
, так как взаимодействие микропроцессоров через коммуникационную систему просит значимого времени (латентность – время самого обычного взаимодействия — велика по сопоставлению со временем выполнения одной машинной команды), то вычислительная работа обязана распределяться меж микропроцессорами большими порциями
.
Во-2-х,
в отличие от многопроцессорных ЭВМ с общей памятью, на системах с распределенной памятью нужно произвести не только лишь распределение вычислений, да и распределение данных, также обеспечить на любом микропроцессоре доступ к удаленным данным
— данным, размещенным на остальных микропроцессорах. Для обеспечения действенного доступа к удаленным данным требуется создавать анализ индексных выражений не только лишь снутри 1-го цикла, да и меж различными циклами. К тому же, недостаточно просто обнаруживать факт наличия зависимости по данным, а требуется найти буквально тот сектор данных, который должен быть переслан с 1-го микропроцессора на иной.
В третьих
, распределение вычислений и данных обязано быть произведено согласованно.
Несогласованность распределения вычислений и данных приведет, скорее всего, к тому, что параллельная программка будет производиться еще медлительнее поочередной. Согласованное распределение вычислений и данных просит кропотливого анализа всей программки,
и неважно какая некорректность анализа может привести к чертовскому замедлению выполнения программки.
В истинное время есть последующие модели
программирования
:
Модель передачи сообщений. MPI.[1]
В модели передачи сообщений параллельная программка представляет собой огромное количество действий, любой из которых имеет собственное локальное адресное место. Взаимодействие действий — обмен данными и синхронизация — осуществляется средством передачи сообщений. Обобщение и стандартизация разных библиотек передачи сообщений привели в 1993 году к разработке эталона MPI (Message Passing Interface). Его обширное внедрение в следующие годы обеспечило коренной перелом в решении задачи переносимости параллельных программ, разрабатываемых в рамках различных подходов, использующих модель передачи сообщений в качестве модели выполнения.
В числе главных плюсов MPI по сопоставлению с интерфейсами остальных коммуникационных библиотек обычно именуют последующие его способности:
· Возможность использования в языках Фортран, Си, Си++;
· Предоставление способностей для совмещения обменов сообщениями и вычислений;
· Предоставление режимов передачи сообщений, позволяющих избежать лишнего копирования инфы для буферизации;
· Широкий набор коллективных операций (к примеру, широковещательная рассылка инфы, сбор инфы с различных микропроцессоров), допускающих еще наиболее эффективную реализацию, чем внедрение соответственной последовательности пересылок точка-точка;
· Широкий набор редукционных операций (к примеру, суммирование расположенных на различных микропроцессорах данных, либо нахождение их наибольших либо малых значений), не только лишь упрощающих работу программера, да и допускающих еще наиболее эффективную реализацию, чем это в состоянии сделать прикладной программер, не имеющий инфы о свойствах коммуникационной системы;
· Комфортные средства именования адресатов сообщений, упрощающие разработку обычных программ либо разделение программки на многофункциональные блоки;
· Возможность задания типа передаваемой инфы, что дозволяет обеспечить ее автоматическое преобразование в случае различий в представлении данных на различных узлах системы.
Но создатели MPI подвергаются и грозной критике за то, что интерфейс вышел очень массивным и сложным для прикладного программера. интерфейс оказался сложным и для реализации, в итоге, в истинное время фактически не существует реализаций MPI, в каких полностью обеспечивается совмещение обменов с вычислениями.
Показавшийся в 1997 проект эталона MPI-2 [2] смотрится еще наиболее массивным и неподъемным для полной реализации. Он предугадывает развитие в последующих направлениях:
· Динамическое создание и ликвидирование действий;
· Однобокие коммуникации и средства синхронизации для организации взаимодействия действий через общую память (для действенной работы на системах с конкретным доступом микропроцессоров к памяти остальных микропроцессоров);
· Параллельные операции ввода-вывода (для действенного использования имеющихся способностей параллельного доступа почти всех микропроцессоров к разным дисковым устройствам).
Модель неструктурированных нитей.
программка представляется как совокупа нитей (threads), способных производиться параллельно и имеющих общее адресное место. Имеющиеся средства синхронизации нитей разрешают организовывать доступ к общим ресурсам. Почти все системы программирования поддерживают эту модель: Win32 threads, POSIXthreads, Javathreads.
Модель параллелизма по данным.
Главным её представителем является язык HPF
[3]. В данной нам модели программер без помощи других распределяет данные поочередной программки по микропроцессорам. Дальше поочередная программка преобразуется компилятором в параллельную, выполняющуюся или в модели передачи сообщений, или в модели с общей памятью. При всем этом любой машина — комплекс технических средств, предназначенных для автоматической обработки информации в процессе решения вычислительных и информационных задач) (либо вычислительной системы) которое делает арифметические и логические операции данные программкой преобразования инфы управляет вычислительным действием и коор производит вычисления лишь над теми данными, которые на него распределены.
Модель параллелизма по управлению.
Эта модель появилась в применении к мультипроцессорам. Заместо определений нитей предлагалось применять особые конструкции – параллельные циклы и параллельные секции. Создание, ликвидирование нитей, распределение на их витков параллельных циклов либо параллельных секций – всё это брал на себя компилятор. Эталоном для данной нам модели на данный момент является интерфейс OpenMP
[4].
Гибридная модель параллелизма по управлению с передачей сообщений
. программка представляет собой систему взаимодействующих MPI – действий, любой из которых программируется на OpenMP.
Модель
параллелизма
по
данным
и
управлению
– DVM
(Distributed Virtual Machine, Distributed Virtual Memory)[5]. Эта модель была разработана в Институте прикладной арифметики им. М. В. Келдыша ран.
3. Обзор средств отладки эффективности MPI-программ
При анализе MPI-программ могут возникать разные сложные ситуации, для анализа которых можно применить специально разработанные инструменты. Эти программки могут посодействовать в решении возникающих заморочек. Большая часть таковых инструментов соединяет воединыжды то, что они во время выполнения программки создают сбор информацию в трассу (описание событий), а потом предоставляют разные средства анализа и визуализации приобретенных данных.
Обычно для целей трассировки в исследуемую программку встраиваются «профилировочные» вызовы, которые фиксируют пришествие определенных событий либо длительность интервалов, и фиксируют эту информацию в журнальчике трассировки, передают ее online-анализатору либо просто видоизменят собираемую статистику.
Можно выделить два главных подхода к анализу производительности:
· A. «Трассировка + Визуализация». Данный подход предполагает два шага:
o A1. Во время выполнения программки собирается «трасса», т.е. журнальчик о ходе работы программки.
o A2. Потом приобретенная трасса просматривается и анализируется.
· B. «Online-анализ». Поведение программки анализируется конкретно в процессе ее выполнения.
Рис.1 Схема А. “Трассировка + Визуализация”.
3.1 Общие задачи всех средств трассировки
1. формат трасс не унифицирован и обычно нацелен на определенную библиотеку передачи сообщений.
2. Сбор инфы — слабенькие способности опции фильтров событий (какие действия и какую информацию включать в трассы). Нет способности разнообразить размер трассы.
3. Не учитывается эффекта замера — средство трассировки довольно очень изменяет задачи визуализации.
1. Что демонстрировать? Какая информация увлекательна и полезна для отладки эффективности MPI программки.
2. Как демонстрировать? Рис.2 . нужно проводить обобщение собираемой инфы. Просто вид всех событий быть может неинформативен.
3. Когда демонстрировать? Принципиально демонстрировать то, что полезно в данный момент для отладки эффективности, чтоб не загромождать юзера лишней информацией.
Рис.2 VAMPIR.
3.2 Обзор главных средств отладки
Ниже будут коротко описаны некие главные средства отладки MPI-программ:
· AIMS -инструментарий, библиотека мониторинга и средства анализа
· MPE -библиотека сохранения Log-файлов средство визуализации Nupshot
· Pablo — библиотека мониторинга и средства анализа
· Paradyn – динамический инструментарий и ран тайм библиотека
· SvPablo – встроенный инструментарий, библиотека мониторинга, средства анализа
· VAMPIRtrace — библиотека мониторинга andVAMPIR – средство визуализации
3.2.1 AIMS — Automated Instrumentation and Monitoring System
пространство разработки:
Некоммерческийпродукт, разрабатываетсяв NASA Ames Research Center врамкахпрограммы High Performance Computing and Communication Program.
Тип
Тип А (трассировка + визуализация)
Языки/Библиотеки
Fortran 77, HPF, С. Библиотеки передачи сообщений: MPI,PVM,NX.
Платформы
IBM RS/6000 SP, рабочие станции Sun и SGI, Cray T3D/T3E.
Функциональность трассировки
Сбор трасс. Автоматическое изменение начального кода программки методом вставки особых вызовов. Параллельно со сбором трассы создается файл со статической информацией.
Уровни детализации. Подпрограммы, вызовы процедур, процедуры различного типа (процедуры ввода-вывода, MPI процедуры т.п.)
формат трасс. Формат описан в[7]. Нацелен на передачу сообщений.
Тип трассировки. Действия, статистика (может собираться без полной трассы).
Визуализация
Процессы — параллельные полосы. Действия изображаются точками на этих линиях. Особенным образом изображаются затратные расходы: времена ожидания, блокировка. Есть возможность «проигрывания» трасс.
время — реальное (астрономическое)
Связь линий действий линиями, обозначающими взаимодействия (передача сообщений, глобальные операции).
Диаграммы взаимодействия действий, временные срезы, история вызовов и трассируемых блоков.
Поддерживается связь с начальным кодом.
Статистика
Суммарное время по замеряемым инструкциям либо типам инструкций и количество срабатываний.
Рис.3 AIMS. Итог подробного анализа пуска.
Vampir, VampirTrace
URL
HTTP://www.pallas.de/pages/vampir.htm
Где разрабатывается?
Коммерческий продукт, разработка компании Pallas (Германия).
Версии
VAMPIR 4.0 (X Window), VAMPIRtrace 4.0
Тип
Тип А (трассировка + визуализация). VampirTrace — система генерации трасс (A1), Vampir — система визуализации (A2).
Языки/библиотеки
Языки — Fortran, C; передача сообщений в рамках MPI.
Платформы
· Cray T3D/T3E
· DEC Alpha (OSF/1)
· Fujitsu VP 300/700
· Hitachi SR2201
· HP 9000
· IBM RS/6000, SP
· Intel Paragon
· NEC SX-4
· SGI Origin, PowerChallenge (IRIX 6)
· Sun SPARC
· Intel x86 (Solaris 2.5)
Функциональность трассировки.
Сбор трасс. Линковка с VampirTrace — прослойкой меж MPI и пользовательской программкой. Уровни детализации. Cлабые вохможности опции уровня детализации — лишь по подпрограммам. Вероятна установка точек начала/конца трассировки. Тип трассировки. Лишь действия (статистика собирается на шаге анализа трасс).
Визуализация
Процессы — параллельные полосы, действия — точки на их.
Взаимодействия. Связь линий действий, матрицы размеров и количества пересылок
Остальные объекты. Радиальные диаграммы и статистические гистограммы.
Поддерживается связь с начальным кодом.
Статистика
Cуммарное время по замеряемым инструкциям либо типам инструкций и количеству срабатываний; отображается на радиальных диаграммах и гистограммах.
Рис.4. VAMPIR 4.0
Jumpshot
URL
HTTP://www-unix.mcs.anl.gov/mpi/www/www1/Jumpshot.html
Где разрабатывается?
Некоммерческое средство, создано в Аргоннской государственной лаборатории. Распространяется вкупе с пакетом MPICH.
версия
Jumpshot 1.0 (требуется Java 1.1 либо выше)
Тип
A2 (визуализация трасс)
Языки/библиотеки
Передача сообщений: MPI.
Платформа
Сбор трасс — любые платформы, где работает MPICH. Визуализация — Java.
Функциональность трассировки
Сбор трасс. Для получения трассы программку нужно откомпилировать с профилировочной версией библиотеки MPICH. формат трасс. CLOG. Тип трасс. Действия
Визуализация
Процессы — параллельные полосы, цветом изображается тип функции. Взаимодействия. Связь линий действий. Остальные объекты. Объемы пересылок по времени, гистограммы затратных расходов по времени.
Статистика
Суммарные времена работы разных типов процедур.
Различное
jumpshot заходит в состав MPICH начиная с версии 1.1.1 и подменяет собой Tcl/Tk-программы upshot/nupshot, входившие в состав MPICH наиболее ранешних версий.
Pablo Performance Analysis Toolkit Software
Пакет состоит из набора средств:
· SvPablo — визуализатор статистической инфы (X Window).
· SDDF — библиотека для записи трасс и набор средств для работы с SDDF файлами
· Trace Library and Extensions — библиотекадлятрассировки
· I/O Analysis — статистика операций ввода-вывода
· MPI I/O Analysis — статистика MPI I/O
· HDF (Hierarchical Data Format) Analysis — анализиспользования HDF операций
· Analysis GUI — библиотека средств для просмотра SDDF трасс
· IO Benchmarks — cбор трасс операций ввода-вывода
·
URL
HTTP://vibes.cs.uiuc.edu/Software/Pablo/pablo.htm
Где разрабатывается?
Некоммерческий пакет, разработан в институте шт. Иллинойс.
Языки/библиотеки
ANSI C, Fortran 77, Fortran 90 (сограничениями), HPF (Portland Group).
Платформы
· SvPablo — SunOS 5.6, SGI Irix 6.5
· Trace Library and Extensions — Sun SunOS, Sun Solaris, RS6000, SP2, Intel Paragon, Convex Exemplar, SGI IRIX
· I/O Analysis — Sun Solaris, SGI IRIX
· MPI I/O Analysis — Sun SunOS, SGI IRIX
· HDF Analysis — Sun Solaris, SGI IRIX
· Analysis GUI — Sun Solaris (X11R5+Motif)
· IO Benchmarks — Sun Solaris, SGI IRIX, Intel Paragon
Функциональность трассировки.
Уровни детализации. Hа уровне интерфейсов, можно созодать ручную разметку с внедрением svPablo. формат трасс — SDDF Тип трасс. Статистика, действия.
Визуализация
SvPablo. база визуализации — связь с начальным кодом. Представляет цветом число вызовов и общее время фрагмента.
Analysis GUI. Библиотека подпрограмм для визуализации трасс в формате SDDF
Статистика
Развернутые средства статистики, в виде набора пакетов.
· I/O Analysis: анализ операций ввода-вывода
· MPI I/O Analysis: анализ ввода-вывода MPI функций
· HDF Analysis: анализ операций HDF.
Сопоставимость
Есть конверторы из различных форматов в SDDF – IBM VT Trace, AIMS.
Развитие
Поддержка HPF, Fortran 90. Поддержка MPI 2.0.
Рис 5. способности Pablo.
Paradyn
URL
http://www.cs.wisc.edu/paradyn
Где разрабатывается?
Некоммерческое средство, разрабатывается в University of Wisconsin,
версия
4.0
Тип
B (онлайн-анализ)
Языки/библиотеки
Fortran, Fortran 90, C, C++: MPI, PVM; HPF
Платформы
· Sun SPARC (лишь PVM)
· Windows NT на x86
· IBM RS/6000 (AIX 4.1 либо старше)
Функциональность трассировки
Динамическая настраиваемая оркестровка программ во время выполнения. В код программки во время ее выполнения динамической вставляются и убираются вызовы трассирующих процедур. Все делается автоматом, в итоге существенно уменьшаются затратные расходы. Начинает с больших блоков, потом равномерно детализирует узенькие места (для этого программка обязана довольно длительно работать)
Визуализация
В базе визуализации лежат два вектора
· измеряемые характеристики производительности: процессорное время, разные затратные расходы, ожидания, времена пересылок и ввода-вывода и т.д.
· составляющие программки/вычислительной системы, к которым относятся характеристики: процедуры, микропроцессоры, диски, каналы передачи сообщений, барьеры и т.д.
На этих векторах появляется матрица: ее элементы или скаляр (конфигурации свойства).
Все свойства показываются во время выполнения программки.
Задачи
Есть задачи с масштабируемостью. На программке при малом числе микропроцессоров (меньше 12) все смотрелось нормально, а на большем числе микропроцессоров — наиболее чем 80% повышение времени. Так же на данный момент самой системой занимается весьма много памяти.
Развитие
Устранение заморочек масштабируемости, уменьшение требуемой памяти, поддержка остальных платформ.
CXperf
URL
HP Performance Analysis Tools — HTTP://www.hp.com/esy/lang/tools/Performance/ CXperf User’s Guide
Где разрабатывается?
Коммерческое средство, разработка Hewlett-Packard.
Тип
A (трассировка + визуализация)
Языки/библиотеки
HP ANSI C (c89), ANSI C++ (aCC), Fortran 90 (f90), HP Parallel 32-bit Fortran 77
Платформы
Сервера HP на базе PA-RISC
Функциональность трассировки
Сбор и настройка трасс осуществляется при помощи указания особых профилировочных опций компилятора.
Визуализация
3D-визуализация, связь с кодом программки, масштабирование, сопоставительный анализ, графы вызовов.
Некие остальные средства анализа поведения паралелльных программ:
· XMPI — графическая среда пуска и отладки MPI-программ, заходит в состав пакета LAM.
· HP Pak — набор средств от Hewlett-Packard для анализа поведения многопоточных программ.
· TAU (Tuning and Analysis Utilities) — некоммерческий набор утилит анализа производительности программ, написанных на языке C++ и его параллельных вариантах. Включает пакет профилировки TAU Portable Profiling.
· Carnival
· Chiron — средство для оценки производительности многопроцессорных систем с общей памятью.
· Pangaea
· GUARD — параллельный отладчик.
· MPP-Apprentice — средствовсоставе Message-Passing Toolkit от SGI.
· ParaGraph
· PGPVM2
· TraceInvader
· XPVM — графическое средство мониторинга PVM-программ.
Подробнее можно прочесть в [8].
4. свойства и методика отладки
DVM-программ
4.1 Главные свойства производительности
Возможность различать поочередные и параллельные участки программки дозволяет при ее выполнении на многопроцессорной ЭВМ спрогнозировать время, которое будет нужно для выполнения данной нам программки на однопроцессорной ЭВМ . Это время именуется полезным временем
. Тем возникает возможность вычислить главную характеристику эффективности параллельного выполнения — коэффициент эффективности
, равный отношению полезного времени к общему времени
использования микропроцессоров, которое в свою очередь равно произведению времени выполнения
программки на многопроцессорной ЭВМ (наибольшее число применяемых микропроцессоров
. Разница меж общим временемиспользования микропроцессоров и полезным временем представляет собой потерянное время
. Если программер не удовлетворен коэффициентом эффективности выполнения собственной программки, то он должен проанализировать составляющие части потерянного времени и предпосылки их появления.
Есть последующие составляющие потерянного времени:
· утраты из-за недочета параллелизма, приводящего к дублированию вычислений на нескольких микропроцессорах (недостающий параллелизм
). Дублирование вычислений осуществляется в 2-ух вариантах. Во-1-х, поочередные участки программки производятся всеми микропроцессорами. Во-2-х, витки неких параллельных циклов могут быть по указанию программера вполне либо отчасти размножены.
· утраты из-за выполнения межпроцессорных обменов (коммуникации
).
· утраты из-за простоев тех микропроцессоров, на которых выполнение программки закончилось ранее, чем на других (простои
).
время выполнения межпроцессорных обменов, кроме времени пересылки данных с 1-го микропроцессора на иной, может включать в себя и время, которое тратится из-за того, что операция приема сообщения на одном микропроцессоре выдана ранее соответственной операции посылки сообщения на другом микропроцессоре. Таковая ситуация именуется рассинхронизацией микропроцессоров и быть может вызвана различными причинами.
Так как утраты, вызываемые рассинхронизацией микропроцессоров, весьма нередко составляют подавляющую часть времени коммуникаций, то принципиально предоставить программеру информацию, позволяющую ему оценить эти утраты и отыскать их предпосылки. Но, четкое определение утрат, вызванных рассинхронизацией, соединено со значительными затратными расходами
Если какая-либо из перечисленных операций выдана различными микропроцессорами не сразу, то при ее выполнении возникнут утраты из-за рассинхронизации микропроцессоров. Для оценки величины таковых утрат для каждой коллективной операции рассчитываются потенциальные утраты из-за ее неодновременного пуска — время, которое было бы потрачено всеми микропроцессорами на синхронизацию, если б выполнение хоть какой коллективной операции начиналось бы с синхронизации микропроцессоров. При всем этом затратные расходы на пересылку синхронизационных сообщений игнорируются.
Для оценки суммарных возможных утрат, которые могут появиться из-за неодновременного пуска коллективных операций на различных микропроцессорах, служит особая черта – синхронизация.
Основная причина утрат из-за рассинхронизации, на устранение которой должен быть нацелен программер – разбалансировка загрузки микропроцессоров. Разбалансировка может возникать из-за того, что выполняющиеся в параллельном цикле вычисления распределены меж микропроцессорами неравномерно.
Если б при входе в любой параллельный цикл и при выходе из него выполнялась бы синхронизация микропроцессоров (межпроцессорный обмен), то разбалансировка загрузки микропроцессоров непременно приводила бы к потерям из-за рассинхронизации. Но, так как таковая синхронизация осуществляется не для всех циклов, то разбалансировка на различных участках программки может компенсироваться и настоящие утраты могут быть незначимыми либо совершенно отсутствовать. Для оценки вероятных утрат из-за разбалансировки программеру может выдаваться некая обобщенная черта — разбалансировка.
С целью понижения затратных расходов привычислении данной нам свойства делается предположение, что синхронизация микропроцессоров будет выполняться лишь один раз — при окончании выполнении программки. Потому поначалу для всякого микропроцессора определяется его суммарная вычислительная загрузка, а потом прогнозируется вызываемая разбалансировкой величина утрат из-за рассинхронизации. Но, так как в настоящей программке синхронизация микропроцессоров осуществляется не только лишь при окончании программки, а еще почаще, то настоящие утраты будут превосходить эту величину. Настоящие утраты из-за рассинхронизации будут еще наиболее превосходить величину разбалансировки в том случае, когда вычислительная загрузка микропроцессоров очень меняется при неоднократном выполнении 1-го и такого же параллельного цикла.
Рассинхронизация может возникать не только лишь из-за разбалансировки, но также из-за различий во временах окончания выполнения на различных микропроцессорах одной и той же коллективной операции, вызванных чертами ее реализации на определенной параллельной ЭВМ . Для оценки величины таковой возможной рассинхронизации программеру может выдаваться особая черта – разброс времен
окончания коллективных операций. Как и время разбалансировки, эта черта является интегральной. Она довольно буквально отражает вероятные утраты из-за рассинхронизации в том случае, когда различия времен выполнения коллективных операций не являются случайными, а определяются, к примеру, топологией коммуникационной сети либо многофункциональной специализацией микропроцессоров (машина — комплекс технических средств, предназначенных для автоматической обработки информации в процессе решения вычислительных и информационных задач) (либо вычислительной системы) которое делает арифметические и логические операции данные программкой преобразования инфы управляет вычислительным действием и коор ввода-вывода, время перекрытия
обменов вычислениями.
Главные свойства эффективности являются интегральными чертами, позволяющими оценить степень распараллеливания программки и главные резервы ее увеличения. Но для исследования эффективности сложных программ одних интегральных черт может оказаться недостаточно. В таком случае программер желает получить наиболее подробную информацию о выполнении собственной программки и ее отдельных частей.
4.2 методика отладки эффективности
Для анализа эффективности выполнения сложных параллельных программ недостаточно иметь свойства выполнения всей программки полностью, а требуется уметь детализировать эти свойства применительно к отдельным частям программки.
В системе DVM были реализованы надлежащие средства, которые разрешают представить выполнение программки в виде иерархии интервалов
[подробнее — 6].
Выполнение всей программки полностью рассматривается как интервал самого высочайшего (нулевого) уровня. Этот интервал может включать в себя несколько интервалов последующего (первого) уровня. Таковыми интервалами могут быть параллельные циклы, поочередные циклы, также любые отмеченные программером последовательности операторов, выполнение которых постоянно начинается с выполнения первого оператора, а завершается выполнением крайнего. Все описанные выше свойства рассчитываются не только лишь для всей программки, да и для всякого ее интервала. При всем этом неоднократное выполнение интервала может рассматриваться (с некой толикой условности) как выполнение на тех же микропроцессорах отдельной программки, состоящей из развернутой последовательности тех операторов интервала, которые были выполнены при настоящем прохождении параллельной программки. Практически же, свойства таковых неоднократно выполняемых интервалов скапливаются при любом их выполнении. При всем этом интервалы, входящие в состав 1-го и такого же интервала наиболее высочайшего уровня, идентифицируются именованием файла с начальным текстом программки и номером строчки в нем, подходящим началу интервала, также, может быть, неким приписанным ему программером целочисленным номером.
Разбиением программки на интервалы юзер управляет при ее компиляции. Он может задать такие режимы, при которых интервалами будут поочередные циклы, которые содержат снутри себя параллельные циклы, или все поочередные циклы совершенно, или отмеченные им в программке последовательности операторов.
4.3
Советы по анализу
При разработке параллельной программки юзер, обычно, преследует одну из 2-ух вероятных целей – обеспечить решение задачки в применимые сроки, или сделать программку, способную отлично решать на разных параллельных ЭВМ задачки определенного класса.
В первом случае, если время выполнения программки удовлетворяет юзера, то остальные свойства его могут уже не заинтересовывать. Во 2-м случае основным аспектом для юзера является коэффициент эффективности распараллеливания. Если время выполнения либо коэффициент эффективности не удовлетворяет юзера, то ему нужно рассматривать потерянное время и его составляющие.
Принципиально держать в голове, что: во-1-х, потерянное время (как и коэффициент эффективности распараллеливания) рассчитывается, делая упор не на реальное время выполнения программки на одном микропроцессоре, а на прогнозируемое время. Этот прогноз может различаться от настоящего времени и в ту, и в другую сторону.
Реальное время быть может больше предсказуемого из-за того, что при выполнении программки на одном микропроцессоре одни и те же вычисления могут осуществляться медлительнее, чем при выполнении на нескольких микропроцессорах. Это разъясняется тем, что при изменении размера применяемых при вычислениях данных изменяется скорость доступа к ним через кэш-память. Так как производительность современных микропроцессоров очень зависит от эффективности использования кэш-памяти, то реальное время может приметно превысить прогнозируемое.
Реальное время быть может меньше предсказуемого, так как при прогнозе учитываются не все затратные расходы на поддержку выполнения параллельной программки. Эти неучтенные расходы, к примеру, поиск инфы в системных таблицах при выполнении неких нередко применяемых функций (замерять время выполнения которых нереально без внесения неприемлемых искажений в выполнение программки), могут существенно сократиться при уменьшении количества микропроцессоров до 1-го.
В итоге воздействия эффективности использования кэш-памяти и системных затратных расходов при выполнении программки на различных конфигурациях параллельной ЭВМ будут выдаваться разные значения полезного времени. Потому, если есть возможность выполнить программку на одном микропроцессоре (а она может добиваться еще больше оперативки, чем имеется на одном микропроцессоре), то лучше это создать для получения представления о различиях предсказуемых времен от настоящего времени.
Во-2-х, время выполнения параллельной DVM-программы на одном микропроцессоре может существенно различаться от времени ее выполнения как поочередной программки. Это быть может следствием последующих обстоятельств:
· Доступ к распределенным данным в параллельной программке различается от доступа к ним в поочередной программке. Доп затратные расходы, появляющиеся в параллельной программке, могут прирастить время ее выполнения на 10-30 процентов. Но в параллельной программке быть может проведена таковая оптимизация доступа к данным, которая для неких программ приведет к убыстрению их выполнения по сопоставлению с поочередным случаем.
· Трансформация программки в программку на обычных языках Фортран 77 либо Си может привести к различиям в оптимизации программ обычными компиляторами. В итоге, параллельная программка может производиться или медлительнее, или резвее. Индивидуальности оптимизации программ современными компиляторами значительно (10-ки и сотки процентов) определяют эффективность их выполнения.
· Некие затратные расходы на поддержку выполнения параллельной программки могут существенно замедлить ее выполнение (к примеру, операции запроса и освобождения памяти в поочередной программке могут перевоплотиться в параллельной программке в еще наиболее сложные операции сотворения и поражения распределенного массива).
Потому, если есть возможность выполнить программку как обыденную поочередную программку на одном микропроцессоре (если это недозволено создать на параллельной ЭВМ , то быть может это окажется вероятным на рабочей станции), то лучше это создать.
Все это юзеру нужно подразумевать, приступая к анализу потерянного времени и его компонент.
Поначалу следует оценить три составляющие потерянного времени для интервала нулевого уровня (всей программки). Более возможно, что основная толика потерянного времени приходится на одну из первых 2-ух компонент (недостающий параллелизм либо коммуникации).
В случае если предпосылкой оказался недостающий параллелизм
, нужно уточнить, на каких участках он найден – поочередных либо параллельных. В крайнем случае причина быть может весьма обычной – неправильное задание матрицы микропроцессоров при запуске программки либо неправильное распределение данных и вычислений. Если же недостающий параллелизм найден на поочередных участках, то предпосылкой этого, быстрее всего, является наличие поочередного цикла, выполняющего большенный размер вычислений. Устранение данной нам предпосылки может востребовать огромных усилий.
В том же случае, если главный предпосылкой утрат являются коммуникации
, то нужно, до этого всего, направить внимание на характеристику утраты из-за рассинхронизации
. Если ее разбалансировка
, так как конкретно разбалансировка вычислений в параллельном цикле является более возможной предпосылкой рассинхронизации и огромных утрат на коммуникациях. Если величина разбалансировки намного меньше величины синхронизации
, то нужно направить внимание на величину разброса времен
коллективных операций. Если рассинхронизация не является следствием разброса времен окончания коллективных операций, то ее вероятной предпосылкой могут быть разбалансировки неких параллельных циклов, которые на рассматриваемом интервале выполнения программки могли взаимно компенсироваться. Потому имеет смысл перейти к рассмотрению черт разбалансировки на интервалах наиболее низкого уровня.
2-ой возможной предпосылкой огромных утрат из-за рассинхронизации быть может рассинхронизация микропроцессоров, которая возникает при выдаче операций ввода-вывода. Это происходит из-за того, что основная работа (воззвание к функциям ввода-вывода операционной системы) делается на микропроцессоре ввода-вывода, а другие микропроцессоры в это время ожидают получения от него данных либо инфы о окончании коллективной операции. Эту причину утрат просто найти, обратив внимание на подобающую компоненту свойства коммуникации
– утраты из-за коммуникаций при вводе-выводе.
Еще одной предпосылкой огромных утрат из-за коммуникаций могут оказаться задержки при запуске коллективных операций в асинхронном режиме, возникающие из-за того, что некие реализации MPI не обеспечивают совмещение вычислений с обменами.
Вероятен и иной подход к анализу черт, когда поначалу анализируются коэффициенты эффективности и потерянное время на разных интервалах первого уровня, потом второго уровня, и т.д. В итоге определяется критичный участок программки, на анализ черт которого и направляются главные усилия. При всем этом нужно подразумевать, что предпосылкой утрат на данном интервале из-за рассинхронизации и простоев могут быть разбалансировки и разбросы времен не только лишь на этом интервале, да и на остальных, выполнявшихся до него интервалах.
При отладке производительности программки юзер не непременно должен запускать ее с тем огромным объемом вычислений, который будет характерен для использования программки при решении настоящих задач. Он может ограничить, к примеру, количество часто циклических наружных итераций до одной — 2-ух итераций. При всем этом коэффициент эффективности программки, значительно зависящий от утрат на тех участках программки, которые производятся до начала первой итерации либо опосля окончания крайней итерации, может существенно снизиться. Но юзер может оформить выполнение наружных итераций в виде отдельного интервала (но при всем этом нужно учесть тот факт, что выполнение первой итерации может сопровождаться значительными задержками из-за динамической подзагрузки программки из файловой системы) и отлаживать его производительность по той же методике, которая была описана выше применительно к программке полностью.
5. Средство анализа эффективности
MPI программ
5.1 Постановка задачки
В системе DVM есть развитые средства анализа эффективности выполнения параллельной DVM-программы. Эти средства являются наиболее массивными, чем те, которые есть для MPI-программ, так как почти все принципиальные свойства выполнения MPI-программ (к примеру, соотношение параллельных и поочередных вычислений) нереально найти из-за отсутствия нужной инфы. Не считая того, в истинное время при разработке MPI-программ у нас в стране фактически не употребляются инструментальные средства отладки эффективности. Это вызвано последующими главными факторами: — различные средства требуют от юзера познания их собственного интерфейса (отсутствие фактического эталона); — отсутствием совершенно каких-то инструментальных средств анализа эффективности на почти всех параллельных ЭВМ .
Потому принципиально сделать такие средства для получения черт эффективности MPI-программ, которые могли бы быть доступны юзерам на всех многопроцессорных ЭВМ .
Целью данной дипломной работы является создание экспериментальной системы отладки эффективности MPI-программ.
Входными данными для нее будут трассы, создаваемые DVM-системой для многофункциональной отладки MPI-программ. В этих трассах отражены воззвания к MPI-функциям и времена их работы. Для получения черт, подобных тем, которые выдаются для DVM-программ, от программера будет нужно доборная информация о том, какие вычисления являются параллельными, а какие поочередными (дублированными на любом микропроцессоре). Эти указания должны быть оформлены таковым образом, что их наличие в MPI-программе не мешало ее правильному и действенному выполнению на тех ЭВМ , где отсутствует данная система отладки эффективности MPI-программ. Таковым же образом должны оформляться и средства описания тех интервалов выполнения программки, для которых требуется раздельно собирать все свойства эффективности.
Этапы работы анализатора.
В работе анализатора можно выделить последующие этапы.
Шаг 1
Обработка трасс со всех микропроцессоров и вычисление для всякого интервала и всякого микропроцессора последующих черт:
Главные свойства и их составляющие
Коэффициент эффективности
(Parallelization
efficiency
) равен отношению полезного времени к общему времени использования микропроцессоров.
Время выполнения
(Execution
time
).
Число применяемых микропроцессоров
(Processors
).
Общее время использования микропроцессоров
(Total
time
) — произведение времени выполнения (Execution
time
) на число применяемых микропроцессоров (Processors
).
Полезное время
(Productive
time
) – прогнозируемое время выполнения на одном микропроцессоре
Потерянное время
(Lost
time
).
Коммуникации
(Communication
) и все составляющие.
Простои
(Idle
time
).
Разбалансировка
(Load
_
Imbalance
).
Потенциальные утраты из-за синхронизации
(Synchronization
) и все составляющие.
Потенциальные утраты из-за разброса времен
(Time
_
variation
) и все составляющие.
свойства выполнения программки на любом микропроцессоре
Потерянное время (Lost
time
) — сумма его составляющих – утрат из-за недостающего параллелизма (User
insufficient
_
par
), системных утрат из-за недостающего параллелизма (Sys
insufficient
_
par
), коммуникаций (Communication
) и простоев (Idle
time
).
Простои на данном микропроцессоре (Idle
time
) — разность меж наибольшим временем выполнения интервала (на каком-то микропроцессоре) и временем его выполнения на данном микропроцессоре.
Общее время коммуникаций (Communication
).
Настоящие утраты из-за рассинхронизации (Real
synchronization
).
Потенциальные утраты из-за разброса времен (Variation
).
Разбалансировка (Load
_
imbalance
) рассчитывается как разность меж наибольшим процессорным временем (CPU
+
MPI
) и подходящим временем на данном микропроцессоре.
время выполнения интервала (Execution
_
time
).
Полезное процессорное время (User
CPU_time
).
Полезное системное время (MPI
time
).
Число применяемых микропроцессоров для данного интервала (Processors
).
Времена коммуникаций для всех типов коллективных операций
Настоящие утраты из-за рассинхронизации для всех типов коллективных операций.
Потенциальные утраты из-за рассинхронизации для всех типов коллективных операций.
Потенциальные утраты из-за разброса времен для всех типов коллективных операций.
Шаг 2
Подготовка текстового представления вычисленных черт. Такое машина — комплекс технических средств, предназначенных для автоматической обработки информации в процессе решения вычислительных и информационных задач).
Шаг 3
Визуализация результатов анализа эффективности.
Подсистема визуализации обязана обеспечить графическое свойства.
5.3 Устройство анализатора
Итак, анализатор состоит из 3-х главных компонент.
1-ая – сбор инфы по трассе. 2-ая – анализ собранных данных. 3-я – визуализация.
5.3.1 Сбор трассы
При любом запуске параллельной программки в режиме трассировки, создается группа файлов с информацией обо всех главных событиях в трассе. здесь есть времена и характеристики всех событий, которые имели пространство при выполнении программки. К сиим данным есть возможность доступа через особые функции интерфейса. Также можно получить информацию для различного рода вспомогательных таблиц (имена применяемых функций, начальных файлов и т.п.).
Дальше приобретенные данные поступают на вход модулям анализа и сбора черт.
5.3.2 анализ
В согласовании с описанной в пт 4.2 методикой, вся программка будет разбита на систему интервалов, поточнее дерево интервалов. Корнем дерева будет вся программка, она считается интервалом нулевого уровня.
Дальше в согласовании с вложенностью интервалы первого уровня и т.д.
Как указать границы интервалов?
Для этого употребляются пара функций MPI_Send() и MPI_Recv() для указания начала интервала, и таковая же пара для указания его окончания. При всем этом посылка и прием сообщения происходят себе и от самого себя (имеется ввиду, что в качестве номера отправителя/получателя употребляется номер самого процесса). Не считая того, тэг сообщения имеет последующий вид:
TAG = 0x(aa)(id)(aa/bb).
Тэг является четырехбайтным целым числом. 1-ый б у «нашего» тэга – это 0xaa. Это дозволяет отличить его от обыденных посылок/приемов сообщений. Крайний б быть может 0xaa – символизирует начало интервала, 0xbb – конец интервала. Снутри особый идентификатор интервала (2 б), его можно применять, к примеру, для того, чтоб раздельно выделить итерации цикла.
Таковой метод выделения был избран поэтому, что:
· он постоянно попадает в трассировку (некие особые функции вроде MPI_Pcontrol() в текущей версии трассировщика не попадают).
· занимает относительно мало времени (порядка 100 тиков микропроцессора).
· прост в использовании и не просит доп средств, кроме обычных MPI-функций.
Таковым образом, программер может добавить в собственный код границы интересующих его областей программки (в нашей терминологии интервалы).
Дальше по сиим тэгам посреди всех событий будут найдены те, которые являются границами интервалов и будут определены их идентификаторы.
Для этого вводится особый класс:
Ифункция:
которая и вычисляет=> описывает нужные границы вкупе со всеми параметрами.
Опосля определения границ, создается структура дерево, в какой хранятся все данные обо всех интервалах.
Коротко о применяемых структурах данных.
Сотворен особый класс tree:
Этот класс содержит информацию обо всех свойствах данного интервала, обрисованных в 5.2. Не считая того, в нем есть информация о родительском узле дерева, также обо всех «листьях-потомках».
В этом классе в качестве вспомогательного употребляется класс
В этом классе содержатся простые составляющие всех компонент, собранные на любом интервале всякого микропроцессора.
Дальше, опосля определения границ интервалов, происходит создание дерева интервалов. В этом дереве и будет храниться информация обо всех интервалах.
Класс
включает способы, которые и собирают информацию из структур, собранных на трассе.
1-ая группа черт собирается в функции
Leave(int line, char* file, long index,unsigned int proc,unsigned long time).
· MPI_time Используем –
· SendRecv_time —
· CollectiveAll_time –
· AllToAll_time —
· Potent_sync —
· Time_variation —
· T_start —
Вычисление черт.
Происходит суммирование интервалов времени, занятых под MPI-функции (интервалы получаются как разность меж временем выхода и входа в MPI-функцию).
Происходит суммирование интервалов времени, вычисляемых как разность времени выхода из функции приема сообщения и времени входа в функцию посылки сообщения.
– Рассчитывается по-разному для операций одиночных посылок/приемов сообщений и коллективных операций. Сюда входят все случаи, когда Recv был выдан ранее Send’а. Эти «задержки» как раз и суммируются. Для коллективных же операций суммируется время «задержки» старта операции на неких микропроцессорах.
Рассчитывается время, рассинхронизации окончания коллективной операции.
Рассчитывается аналогично
лишь суммируются времена работы лишь не блокирующих операций.
Все эти свойства собираются на любом микропроцессоре для данного интервала. Прототипвсехфункцийодинаков:
Собранные «простые» свойства, потом собираются в наиболее общие по всему интервалу.
1-ая применяемая для этого функция – это функция
В данной нам функции собираются последующие свойства:
· CPU_time
· MPI_time
· SendRecv_time
· CollectiveAll_time
· AllToAll_time
· Comm_time(Общее время коммуникаций)
· Idle_time(время бездействия)
· Potent_sync
· Time_variation
· T_start
Они все уже являются чертами всего интервала.
Дальше происходит вычисление уже не общих, а сравнительных черт. Зная все эти составляющие на любом микропроцессоре для интервала, мы находим микропроцессоры с наибольшим, наименьшим значением по времени, также среднее значения всех черт.
Опосля функции
рассчитывается полезное время
позже время пуска —
эффективность распараллеливания
и, в конце концов, потерянное время –
На этом сбор и анализ инфы оканчиваются. Последующий шаг, это генерация соответственных текстовых выдач. Эти выдачи представляют собой текстовый файл и имеют последующий вид (Пример).
Пример. Текстовый файл с итоговыми чертами.
Interval (LineNumber = 153 SourceFile = exch.c) Level=0 EXE_Count=1
—Main Characteristics—
Parallelization Efficiency 0.978833
Execution Time 2.079975
Processors 4
Total Time 8.319900
Productive Time 8.143794 (CPU MPI)
MPI время на одном микропроцессоре считается полезным, а на других — потерянным
Lost Time 0.176106
—MPI Time 0.173490
—Idle Time 0.002616
Communication Time 0.076563
*****SendRecv Time 0.013295
*****CollectiveAll Time 0.063268
*****AllToAll Time 0.000000
Potential Sync. 0.068763
Time Variation 0.001790
Time of Start 0.000000
—Comparative Characteristics—
Tmin Nproc Tmax Nproc Tmid
Lost Time 0.033087 3 0.060057 0 0.044026
Idle Time 0.000000 1 0.000898 0 0.000654
Comm. Time 0.006597 3 0.034854 0 0.019140
MPI Time 0.032259 3 0.059159 0 0.043372
Potential Sync. 0.001800 0 0.029369 3 0.017190
Time variation 0.000161 1 0.000607 3 0.000447
Time of Start 0.000000 0 0.000000 0 0.000000
Для всякого интервала выдается последующая информация:
· название файла с начальным текстом MPI-программы и номер первого оператора интервала в нем (SourceFile, LineNumber);
· номер уровня вложенности (Level);
· количество входов (и выходов) в интервал (EXE_Count);
· главные свойства выполнения и их составляющие (Main characteristics);
· малые, наибольшие и средние значения черт выполнения программки на любом микропроцессоре (Comparative characteristics);
При выдаче черт их составляющие размещаются в той же строке (справа в скобках), или в последующей строке (справа от знаков “*” либо “-“).
информация о малых, наибольших и средних значениях черт оформлена в таблицу. Также есть информация обо всех свойствах на любом микропроцессоре.
5.3.3 Визуализация
Последующим шагом опосля того, как все нужные свойства собраны, является шаг
Этот шаг нужен, потому что хотя текстовый файл содержит всю нужную информацию, при большенном числе интервалов воспользоваться им не весьма комфортно. Кажется целесообразным, что, потому что интервалы “показывались” логически в виде дерева, то и визуализировать их необходимо в виде дерева. Было выбрана форма отображения, подобная древовидной организации файловой структуры данных на дисках. Соответственно, любой интервал доступен из собственного родителя, интервалы нижних уровней показываются правее. Также при нажатии на интервал, в текстовое поле
выводится информация обо всех свойствах конкретно этого интервала.
Это существенно упрощает поиск нужной для анализа области.
Рис.6. Окно программки анализа.
Также полезным для представления общей картины пуска является упорядоченный по времени перечень событий. При всем этом употребляется так именуемый (TimeLine), все действия показываются на полосы определенным цветом в согласовании с течением времени, когда они произошли. Это дозволяет выслеживать не попросту подходящую область, а буквально интересующее событие.
Используя механизм Tooltip’ов, юзер получает возможность выяснить тип действия (пользовательский (UserCode) либо MPI) и заглавие функции (для MPI — функций).
Рис.7. TimeLine
Выяснить это можно по цвету полосы с событием. Перечень цветов описан в Приложении 2.
Заключение
В данной работе исследовались способности анализа эффективности MPI-программ. Было создано собственное программное средство, использующее подходы, используемые в DVM-системе.
Ориентировочный размер программки на С++ в строчках кода = 6500 строк.
программка оттестирована на тестах, поставляемых с MPI – реализациями, также с тестами NAS (NPB2.3), с добавлением обрисованных выше директив для границ интервала.
В процессе дипломной работы были:
— Проанализированы современные средства анализа параллельных программ.
— Исследованы методы анализа и сбора черт.
— Реализовано программное средство со последующими способностями:
1. Отображение выполнения программки в виде дерева интервалов
2. Сбор и отображение черт избранного интервала.
3. Выдача общей инфы обо всех интервалах в текстовый файл.
4. Показtime-line.
· Отладка эффективности параллельных программ – процесс весьма непростой и трудозатратный
· Развитые средства анализа эффективности могут значительно убыстрить этот процесс.
· Нужна грамотная — приятная визуализация результатов.
· Для заслуги эффективности параллельной программки приходится неоднократно изменять программку, время от времени абсолютно меняя схему ее распараллеливания. Потому принципиально применять высокоуровневые средства разработки параллельных программ
· Нужно учесть разные эффекты, связанные с непостоянностью поведения параллельных программ.
В предстоящем планируется вести работу в направлении интеллектуализации системы. Лучше получение автоматических советов пользователю-программисту по улучшению эффективности программки. Это поможет упростить решение обычных сложностей, возникающих на пути отладки параллельной программки.
приложение
1
Модуль main
– вызов процедур сбора инфы, анализа и генерации результата. Compute
– вычисление все нужных черт трассы. Для этого употребляется модуль tree
, который отвечает за формирование дерева с данными о разыскиваемых свойствах. Модуль determine
дозволяет отыскивать и выделять интервалы в начальном коде и в трассе программки. Модуль visual
занимается графическим отображением приобретенных данных и состоит и timeline
– действия в трассе, и characteristics
– дерево интервалов с отображаемыми чертами.
приложение 2
1. Коллективные операции:
MPI_Barrier, MPI_Bcast, MPI_Gather, MPI_Gatherv, MPI_Scatter, MPI_Scatterv, MPI_Allgather, MPI_Allgatherv, MPI_Alltoall, MPI_Alltoallv, MPI_Reduce, MPI_Allreduce, MPI_Reduce_scatter, MPI_Scan
темный
2. Операции посылки
MPI_Send, MPI_Bsend, MPI_Ssend, MPI_Rsend
тёмно-зелёный
3. Неблокирующие операции посылки
MPI_Isend, MPI_Ibsend, MPI_Issend, MPI_Irsend
светло-зелёный
4. Операции получения/ожидания/посылки-получения с блокировкой MPI_Recv, MPI_Wait, MPI_Waitany, MPI_Waitall, MPI_Waitsome, MPI_Probe, MPI_Sendrecv, MPI_Sendrecv_replace
синий
5. Операции получения/проверки без блокировки
MPI_Irecv, MPI_Test, MPI_Testany, MPI_Testall, MPI_Testsome, MPI_Iprobe голубой
6. Остальные (малоиспользуемые) операции
MPI_Request_free, MPI_Cancel, MPI_Test_cancelled, MPI_Send_init, MPI_Bsend_init, MPI_Ssend_init, MPI_Rsend_init, MPI_Recv_init, MPI_Start, MPI_Startall
серый
7. Пользовательский код
светло-розовый
]]>