Программирование для многопроцессорных систем в стандарте MPI - Шпаковский Г.И., Серикова Н.В.. Программирование для многопроцессорных систем в стандарте MPI -. Организация вычислений в многопроцессорных системах
 Скачать 1.61 Mb.
|
|
Глава 2. РЕАЛИЗАЦИИ ИНТЕРФЕЙСА ПРОГРАММИРОВАНИЯ MPI 2.1. MPICH – ОСНОВНАЯ РЕАЛИЗАЦИЯ MPI MPI – это описание библиотеки функций, которые обеспечивают в первую очередь обмен данными между процессами. Следовательно, чтобы такая библиотека работала в некоторой исполнительной среде, необходимо между описанием библиотеки и исполнительной средой иметь промежуточный слой, который называется реализацией MPI для данной исполнительной среды. Под реализацией обычно понимают программные средства, обеспе- чивающие выполнение всех функций MPI в исполнительной среде. Эти процедуры обеспечивают парные и коллективные обмены, реали- зуют коммуникаторы, топологию, средства общения с исполнитель- ной средой, средства профилирования и множество вспомогательных операций, связанных, например, с запуском вычислений, оценкой эффективности параллельных вычислений и многое другое. Возможны два способа построения реализаций: прямая реализация для конкретной ЭВМ и реализация через ADI (Abstract Device Interface – интерфейс для абстрактного прибора). Поскольку имеется большое количество типов реальных параллельных систем, то количе- ство реализаций в первом случае будет слишком велико. Во втором случае строится реализация только для одного ADI, а затем архитек- тура ADI поставщиками параллельного оборудования реализуется в конкретной системе (как правило, программно). Такая двухступенча- тая реализация MPI уменьшает число вариантов реализаций и обеспе- чивает переносимость реализации. Поскольку аппаратно зависимая 29 часть этого описания невелика, то использование метода ADI позво- ляет создать пакет программ, который разработчики реальных систем могут использовать практически без переделок. Основной объем работ по разработке стандарта MPI и построению его реализаций выполняется в Аргоннской национальной лаборатории США [1]. Здесь подготовлены и получили широкое распространение реализации MPI, получившие название MPICH (добавка CH взята из названия пакета Сhameleon, который ранее использовался для систем с передачей сообщений, многое из этого пакета вошло в MPIСH). Имеется три поколения MPIСH, связанных с развитием ADI. Пер- вое поколение ADI-1 было спроектировано для компьютеров с массо- вым параллелизмом, где механизм обмена между процессами принад- лежал системе. Этот ADI обеспечивал хорошие характеристики с ма- лыми накладными расходами, такая версия MPICH была установлена на параллельных компьютерах: Intel iPSC/860, Delta, Paragon, nCUBE. Второе поколение − ADI-2 – было введено, чтобы получить боль- шую гибкость в реализациях и эффективно поддерживать коммуника- ционные механизмы с большим объемом функций. Третье поколение − ADI-3 – было спроектировано, чтобы обеспе- чить большее соответствие появляющимся сетям с удаленным досту- пом, многопоточной исполнительной среде и поддержке операций MPI-2, таких как удаленный доступ к памяти и динамическое управ- ление процессами. ADI-3 есть первая версия MPICH, в которой при проектировании не ставилась задача близкого соответствия другим библиотекам с обменом сообщениями (в частности, PVM [16]), по- скольку MPI вытеснил большинство систем с обменом сообщениями в научных вычислениях. ADI-3 подобно предыдущим ADI спроектиро- ван так, чтобы содействовать переносу MPICH на новые платформы и коммуникационные методы. ADI для обмена сообщениями должен обеспечивать четыре набора функций: • для описания передаваемых и получаемых сообщений; • для перемещения данных между ADI и передающей аппаратурой; • для управления списком зависших сообщений (как посланных, так и принимаемых); • для получения основной информации об исполнительной среде и ее состоянии (например, как много задач выполняется). MPICH ADI выполняет все эти функции; однако многие аппаратные средства для передачи сообщений не могут обеспечить, например, 30 списковое управление или возможности сложной передачи данных. Эти функции эмулируются путем использования вспомогательных процедур. Следовательно, ADI – это совокупность определений функций (ко- торые могут быть реализованы как функции С или макроопределения) из пользовательского набора MPI. Если так, то это создает протоко- лы, которые отличают MPICH от других реализаций MPI. В частно- сти, уровень ADI содержит процедуры для упаковки сообщений и подключения заголовочной информации, управления политикой бу- феризации, для установления cоответствия запущенных приемов при- ходящих сообщений и др. Для того чтобы понять, как работает MPICH, рассмотрим в каче- стве примера реализацию простых функций посылки и приема MPI_Send и MPI_Recv . Для этой цели могут использоваться два протокола: Eager и Rendezvous. Eager. При посылке данных MPI вместе с адресом буфера должен включить информацию пользователя о тэге, коммуникаторе, длине, источнике и получателе сообщения. Эту дополнительную информа- цию называют оболочкой (envelope). Посылаемое сообщение состоит из оболочки, которая следует за данными. Метод посылки данных вместе с оболочкой называется eager («жадным») протоколом. Когда сообщение прибывает, возможны два случая: либо соответ- ствующая приемная процедура запущена, либо нет. В первом случае предоставляется место для приходящих данных. Во втором случае си- туация много сложнее. Принимающий процесс должен помнить, что сообщение прибыло, и где-то его сохранить. Первое требование вы- полнить относительно легко, отслеживая очередь поступивших сооб- щений. Когда программа выполняет MPI_Recv , она прежде всего проверяет эту очередь. Если сообщение прибыло, операция выполня- ется и завершается. Но с данными может быть проблема. Что, напри- мер, будет, если множество подчиненных процессов почти одновре- менно пошлют главному процессу свои длинные сообщения (напри- мер, по 100 МВ каждое) и места в памяти главного процесса для их размещения не хватит? Похожая ситуация возникает, например, при умножении матриц. Стандарт MPI требует, чтобы в этой ситуации прием данных выполнялся, а не выдавался отказ. Это и приводит к буферизации. Rendezvous. Чтобы решить проблему доставки большого объема данных по назначению, нужно контролировать, как много и когда эти 31 данные прибывают на процесс-получатель. Одно простое решение со- стоит в том, чтобы послать процессу-получателю только оболочку. Когда процесс-получатель потребует данные (и имеет место для их размещения), он посылает отправителю сообщение, в котором гово- рится: “теперь посылай данные”. Отправитель затем пошлет данные, будучи уверен, что они будут приняты. Этот метод называется прото- колом “рандеву”. В этом случае получатель должен отводить память только для хранения оболочек, имеющих очень небольшой размер, а не для хранения самих данных. Причина для разработки многих вариаций режимов передачи те- перь довольно ясны. Каждый режим может быть реализован с помо- щью комбинации “жадного” и “рандеву” протоколов. Некоторые ва- рианты представлены в таб. 2.1. Таблица 2.1 Режимы send с протоколами Eager и Rendezvous Вызов MPI Размер сообщения Протокол MPI_Ssend any Rendezvous всегда MPI_Rsend any Eager всегда MPI_Send < =16 KB Eager MPI_Send >16 KB Rendezvous Главное преимущество протокола «рандеву» состоит в том, что он позволяет принимать произвольно большие сообщения в любом коли- честве. Но этот метод невыгодно использовать для всех сообщений, поскольку, например, «жадный» протокол быстрее, в частности, для коротких сообщений. Возможно большое количество других протоко- лов и их модификаций. Канальный интерфейс является одним из наиболее важных уровней иерархии ADI и может иметь множественные реализации. На рис. 2.1. имеется два ADI: р4 – для систем с передачей сообще- ний, и p2 – для систем с разделяемой памятью. Реализация Chameleon создана давно, построена на базе интерфейса p4, многие ее элементы частично использовались на начальной стадии реализации MPICH. Поэтому в MPICH также используется интерфейс p4, который перене- сен поставщиками аппаратуры на ряд машин, что и показано на ри- сунке. Интерфейс p2 также адаптирован для ряда систем. Однако на рисунке представлены и примеры прямой реализации MPI без промежуточного ADI. Так, ряд машин напрямую использует макросы, из которых состоит сама реализация Chameleon. 32 Рис. 2.1. Нижние слои MPICH Другим примером непосредственной реализации канального ин- терфейса являются машины, использующие коммуникационные сети SCI. Рис. 2.1. характеризует гибкость в построении канального интер- фейса. Это, в частности, относится к машинам SGI. MPICH стал ис- пользоваться на машинах SGI с самого начала. Это отмечено блоком SGI(0). Затем стала использоваться усовершенствованная версия SGI(1), использующая интерфейс разделяемой памяти. SGI (2) являет- ся прямой реализацией канального интерфейса, использующей ряд новых механизмов. Затем появились еще более совершенные вариан- ты SGI(3) и SGI(4), которые обходят канальный интерфейс и ADI. MPI в зависимости от версии содержит 150 – 200 функций, и все эти функции должны быть реализованы с помощью MPICH. Часто реализация полного набора функций растянута во времени и занимает достаточно длительный период. MPICH является переносимой реализацией полного описания MPI для широкого круга параллельных вычислительных сред, включая кластеры рабочих станций и массово-параллельные системы. MPICH содержит кроме самой библиотеки функций MPI программную среду для работы с программами MPI. Программная среда включает мо- бильный механизм запуска, несколько профилирующих библиотек для изучения характеристик MPI–программ и интерфейс для всех других средств. Канальный интерфейс Chameleon p2 SGI(2) SCI Convex nx mpl p4 rs6000, Sun, Dec, HP, SGI(0) SGI(1) Solaris Nexus 33 2.2. СПОСОБЫ ЗАПУСКА ПРИЛОЖЕНИЙ В MPICH Запуск приложений выполняется с помощью MPICH. В этом разде- ле описаны некоторые наиболее распространенных способы запуска приложений. Подробная информация о способах запуска находится в папке www/nt/ любой версии MPICH [1]. 2.2.1. Запуск с помощью MPIRun. exe Это наиболее распространенный способ запуска приложений. Ко- манда MPIRun.exe находится в [MPICH Launcher Home]\bin directory. Использование команды: 1. MPIRun configfile [-logon] [args ...] 2. MPIRun -np #processes [-logon][-env "var1=val1|var2=val2..."] executable [args ...] 3. MPIRun -localonly #processes [-env "var1=val1|var2=val2..."]executable [args ...] Аргументы в скобках являются опциями. Формат файла конфигурации config следующий: exe c:\somepath\myapp.exe или \\host\share\somepath\myapp.exe [args arg1 arg2 arg3 ...] [env VAR1=VAL1|VAR2=VAL2|...|VARn=VALn] hosts hostA #procs [path\myapp.exe] hostB #procs [\\host\share\somepath\myapp2.exe] hostC #procs Можно описать путь к исполняемому коду отдельной строкой для каждого хоста, тем самым вводя MPMD–программирование. Если путь не описывается, тогда используется по умолчанию путь из стро- ки exe. Приведем пример простого файла конфигурации: exe c:\temp\slave.exe env MINX=0|MAXX=2|MINY=0|MAXY=2 args -i c:\temp\cool.points hosts fry 1 c:\temp\master.exe fry 1 #light 1 jazz 2 Во втором случае запускается количество процессов, равное #processes, начиная с текущей машины и затем по одному процессу на 34 каждую следующую машину, описанную на этапе инсталляции, пока все процессы не исчерпаны. Если процессов больше, чем машин, то распределение повторяется по циклу. В третьем случае команда запускает выполнение нескольких про- цессов на локальной машине, использующей устройство разделяемой памяти. -env "var1=val1|var2=val2|var3=val3|...varn=valn" Эта опция устанавливает переменные среды, описанные в строке, перед запуском каждого процесса. Следует помнить, что надо взять в кавычки строку, чтобы приглашение команды не интерпретировало вертикальные линии как конвейерную команду. -logon Эта опция mpirun приглашает установить имя пользователя (account) и пароль (password). Если использовать эту опцию, можно описать исполняемую программу, которая размещена в разделяемой памяти. Если не применять –logon, то исполняемая программа должна находиться на каждом хосте локально. Необходимо использовать mpiregister.exe, чтобы закодировать имя и пароль в регистре и избе- жать приглашения. 2.2.2. Процедура MPIConfig. exe Чтобы выполнять приложение на различных хостах без описания их в конфигурационном файле, процедура запуска должна знать, ка- кие хосты уже инсталлированы. MPIConfig.exe – это простая про- грамма, которая находит хосты, где процедура запуска уже установ- лена, и записывает этот список хостов в регистр, который представлен в специальном окне “MPI Configuration Tool”. По этой информации MPIRun может выбрать из списка в окне хосты, где следует запустить процессы. Операции с окном следующие: Refresh опрашивает сеть для обновления списка имен хостов. Find подключается к регистру на каждом хосте и определяет по списку, успешно ли уже установлена процедура запуска. Когда он за- канчивается, то избранные хосты такие, где эта процедура установле- на. Verify приводит к тому, что mpiconfig подключается к каждому из избранных хостов и убеждается, что DCOM–сервер достижим. Эта особенность еще не реализована. 35 Set приводит к тому, что вызывается окно – “MPICH Registry settings” – и выполняется следующий диалог: • Если выбрать "set HOSTS", mpiconfig создаст группу из всех из- бранных хостов и запишет этот список имен в регистр на каждом хосте. Когда MPIRun выполняется из любого хоста группы с опци- ей –np, хосты будут выбираться из этого списка. • Если выбрать "set TEMP", mpiconfig запишет этот директорий в регистр каждого хоста. remote shell server должен создать времен- ный файл для связи с первым запущенным процессом, и этот файл должен располагаться в ячейке, которая пригодна для read/write как для remote shell service, так и для процедуры запуска mpich приложения. remote shell server использует этот вход, чтобы опре- делить, где записать этот файл. По умолчанию устанавливается C:\ • Позиция “launch timeout” указывает, как долго MPIRun будет ждать, пока не убедится, что процесс запустить нельзя. Время за- дается в миллисекундах. 2.2.3. Процедура MPIRegister. exe Процедура MPIRegister.exe используется для того, чтобы закодиро- вать имя и пароль в регистр для текущего пользователя. Он находится в [MPICH Launcher Home]\bin directory. Эта информация используется командой MPIRun.exe для запуска приложений в контексте этого пользователя. Если mpiregister не используется, то mpirun будет по- стоянно приглашать ввести имя и пароль. Использование: • MPIRegister • MPIRegister -remove Сначала команда MPIRegister попросит ввести имя пользователя. Введите имя в форме [Domain\]Account, где domain name есть опция (например, mcs\ashton or ashton). Затем дважды выполнится пригла- шение для ввода пароля. Затем последует вопрос, желаете ли Вы хра- нить эти параметры постоянно. Если Вы говорите “да”, то эти данные будут сохранены на жестком диске. Если “нет “, данные останутся только в памяти. Это означает, что Вы можете запускать mpirun много раз и при этом не потребуется вводить имя и пароль. Однако при пе- резагрузке машины и использовании mpirun опять возникнет пригла- шение для ввода имени и пароля. remove приводит к удалению ин- формации из регистра. 36 2.3. БИБЛИОТЕКА MPE И ЛОГФАЙЛЫ Библиотека MPE (Multi-Processing Environment) содержит проце- дуры, которые находятся “под рукой” и облегчают написание, отлад- ку и оценку эффективности MPI–программ. MPE–процедуры делятся на несколько категорий [19]. Параллельная графика ( Parallel X graphics ). Эти процедуры обеспечивают доступ всем процессам к разделяемому Х–дисплею. Они создают удобный вывод для параллельных программ, позволяют чертить текст, прямоугольники, круги, линии и так далее. Регистрация ( Logging ). Одним из наиболее распространенных средств для анализа характеристик параллельных программ является файл трассы отмеченных во времени событий – логфайл (logfile). Библиотека MPE создает возможность легко получить такой файл в каждом процессе и собрать их вместе по окончанию работы. Она так- же автоматически обрабатывает рассогласование и дрейф часов на множественных процессорах, если система не обеспечивает синхро- низацию часов. Это библиотека для пользователя, который желает создать свои собственные события и программные состояния. Последовательные секции ( Sequential Sections ). Иногда секция кода, которая выполняется на ряде процессов, должна быть выполне- на только по одному процессу за раз в порядке номеров этих процес- сов. MPE имеет функции для такой работы. Обработка ошибок ( Error Handling). MPI имеет механизм, кото- рый позволяет пользователю управлять реакцией реализации на ошибки времени исполнения, включая возможность создать свой соб- ственный обработчик ошибок. Далее будут преимущественно рассмотрены средства регистрации (logging) для анализа эффективности параллельных программ. Анализ результатов регистрации производится после выполнения вычисле- ний. Средства регистрации и анализа включают ряд профилирующих библиотек, утилитных программ и ряд графических средств. Первая группа средств − профилирование. Библиотечные ключи обеспечивают собрание процедур, которые создают логфайлы. Эти логфайлы могут быть созданы вручную путем размещения в MPI– программе обращений к MPE, или автоматически при установлении связи с соответствующими MPE–библиотеками, или комбинацией этих двух методов. В настоящее время MPE предлагает следующие три профилирующие библиотеки: 37 1. Tracing Library (библиотека трассирования) – трассирует все MPI–вызовы. Каждый вызов предваряется строкой, которая со- держит номер вызывающего процесса в MPI_COMM_WORLD и сопровождается другой строкой, указывающей, что вызов завер- шился. Большинство процедур send и receive также указывают значение count , tag и имена процессов, которые посылают или принимают данные. 2. Animation Libraries ( анимационная библиотека ) – простая форма программной анимации в реальном времени, которая требует про- цедур Х–окна. 3. Logging Libraries (библиотека регистрации) – самые полезные и широко используемые профилирующие библиотеки в MPE. Они формируют базис для генерации логфайлов из пользовательских программ. Сейчас имеется три различных формата логфайлов, до- пустимых в MPE. По умолчанию используется формат CLOG. Он содержит совокупность событий с единым отметчиком времени. Формат ALOG больше не развивается и поддерживается для обес- печения совместимости с ранними программами. И наиболее мощным является формат – SLOG (для Scalable Logfile), который может быть конвертирован из уже имеющегося CLOG–файла или получен прямо из выполняемой программы (для этого необходимо установить пременную среды MPE_LOG_FORMAT в SLOG). Набор утилитных программ в MPE включает конверторы лог- форматов (например, clog2slog), печать логфайлов (slog_print), обо- лочки средств визуализации логфайлов, которые выбирают коррект- ные графические средства для представления логфайлов в соответст- вии с их расширениями. Далее будут рассмотрены только библиотеки регистрации Logging Libraries Результаты расчета времени дают некоторое представление об эффективности программы. Но в большинстве случаев нужно под- робно узнать, какова была последовательность событий, сколько вре- мени было потрачено на каждую стадию вычисления и сколько вре- мени занимает каждая отдельная операция передачи. Чтобы облегчить их восприятие, нужно представить их в графической форме. Но для этого сначала нужно создать файлы событий со связанными времен- ными отметками, затем исследовать их после окончания программы и только затем интерпретировать их графически на рабочей станции. Такие файлы ранее уже названы логфайлами. Способность автомати- 38 чески генерировать логфайлы является важной компонентой всех средств для анализа эффективности параллельных программ. Далее в этой главе будут описаны некоторые простые инструмен- тальные средства для создания логфайлов и их просмотра. Библиотека для создания логфайлов отделена от библиотеки обмена сообщениями MPI. Просмотр логфайлов независим от их создания, и поэтому могут использоваться различные инструментальные средства. Библиотека для создания логфайлов MPE разработана таким образом, чтобы со- существовать с любой MPI–реализацией и распространяется наряду с модельной версией MPI. Чтобы создать файл регистрации, необходимо вызвать процедуру MPE_Log_event . Кроме того, каждый процесс должен вызвать проце- дуру MPE_Init_log , чтобы приготовиться к регистрации, и MPE_Finish_log , чтобы объединить файлы, сохраняемые локально при каждом процессе в единый логфайл. MPE_Stop_log используется, чтобы приостановить регистрацию, хотя таймер продолжает работать. MPE_Start_log возобновляет регистрацию. Программист выбирает любые неотрицательные целые числа, же- лательные для типов событий; система не придает никаких частных значений типам событий. События рассматриваются как не имеющие продолжительность. Чтобы измерить продолжительность состояния программы, необходимо, чтобы пара событий отметила начало и окончание состояния. Состояние определяется процедурой MPE_Describe_state , которая описывает начало и окончание типов событий. Процедура MPE_Describe_state также добавляет название состояния и его цвет на графическом представлении. Соответствую- щая процедура MPE_Describe_event обеспечивает описание события каждого типа. Используя эти процедуры, приведем пример вычисле- ния числа π. Для этого оснастим программу вычисления числа π со- ответствующими операторами. Важно, чтобы регистрация события не создавала больших накладных расходов. MPE_Log_event хранит не- большое количество информации в быстрой памяти. Во время выпол- нения MPE_Log_event эти буфера объединяются параллельно и ко- нечный буфер, отсортированный по временным меткам, записывается процессом 0. #include "mpi.h" #include "mpe.h" #include #include 39 int main(int argc, char *argv[ ]) { int n, myid, numprocs; double PI25DT = 3.141592653589793238462643; double mypi, pi, h, sum, x, startwtime = 0.0, endwtime; int event1a, event1b, event2a, event2b,event3a, event3b, event4a, event4b; char processor_name[MPI_MAX_PROCESSOR_NAME]; MPI_Init(&argc,&argv); MPI_Comm_size(MPI_COMM_WORLD,&numprocs); MPI_Comm_rank(MPI_COMM_WORLD,&myid); MPE_Init_log(); /* Пользователь не дает имена событиям, он получает их из MPE */ /* определяем 8 событий для 4 состояний Bcast”,”Compute”,”Reduce” ,”Sync” */ event1a = MPE_Log_get_event_number(); event1b = MPE_Log_get_event_number(); event2a = MPE_Log_get_event_number(); event2b = MPE_Log_get_event_number(); event3a = MPE_Log_get_event_number(); event3b = MPE_Log_get_event_number(); event4a = MPE_Log_get_event_number(); event4b = MPE_Log_get_event_number(); if (myid == 0) { /* задаем состояние "Bcast" как время между событиями event1a и event1b. */ MPE_Describe_state(event1a, event1b, "Broadcast", "red"); /* задаем состояние "Compute" как время между событиями event2a и vent2b. */ MPE_Describe_state(event2a, event2b, "Compute", "blue"); /* задаем состояние "Reduce" как время между событиями event3a и event3b. */ MPE_Describe_state(event3a, event3b, "Reduce", "green"); /* задаем состояние "Sync" как время между событиями event4a и event4b. */ MPE_Describe_state(event4a, event4b, "Sync", "orange"); } if (myid == 0) { n = 1000000; startwtime = MPI_Wtime(); } MPI_Barrier(MPI_COMM_WORLD); MPE_Start_log(); /* регистрируем событие event1a */ MPE_Log_event(event1a, 0, "start broadcast"); MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD); /* регистрируем событие event1b */ MPE_Log_event(event1b, 0, "end broadcast"); /* регистрируем событие event4a */ MPE_Log_event(event4a,0,"Start Sync"); MPI_Barrier(MPI_COMM_WORLD); /* регистрируем событие event4b */ 40 MPE_Log_event(event4b,0,"End Sync"); /* регистрируем событие event2a */ MPE_Log_event(event2a, 0, "start compute"); h = 1.0 / (double) n; sum = 0.0; for (i = myid + 1; i <= n; i += numprocs) { x = h * ((double)i - 0.5); sum += (4.0 / (1.0 + x*x)); } mypi = h * sum; /* регистрируем событие event2b */ MPE_Log_event(event2b, 0, "end compute"); /* регистрируем событие event3a */ MPE_Log_event(event3a, 0, "start reduce"); MPI_Reduce(&mypi,&pi,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD); /* регистрируем событие event3b */ MPE_Log_event(event3b, 0, "end reduce"); MPE_Finish_log("cpilog"); if (myid == 0) { endwtime = MPI_Wtime(); printf("pi is approximately %.16f, Error is %.16f\n", pi, fabs(pi - PI25DT)); printf("wall clock time = %f\n", endwtime-startwtime); } MPI_Finalize(); return(0); } Важный вопрос – доверие к локальным часам. На некоторых парал- лельных компьютерах часы синхронизированы, но на других − толь- ко приблизительно. В локальных сетях рабочих станций ситуация на- много хуже, и генераторы тактовых импульсов в разных компьютерах иногда «плывут» один относительно другого. Анализ логфайлов. После выполнения программы MPI , которая содержит процедуры MPE для регистрации событий, директорий, где она выполнялась, содержит файл событий, отсортированных по вре- мени, причем время скорректировано с учетом «плавания» частоты генераторов. Можно написать много программ для анализа этого фай- ла и представления информации. Например, одна из реализаций MPE содержит короткую програм- му, называемую states . Если мы выполняем ее с логфайлом, который описали выше, мы получим: 41 Состояние: Время: Broadcast 0.000184 Compute 4.980584 Reduce 0.000248 Sync 0.000095 Сумма: 4.981111 Такая итоговая информация является довольно рaспространенной, но грубой формой профилирования; она сообщает только, где про- грамма тратит время. Значительно информативнее графическое пред- ставление, обеспечиваемое специализированными программами, на- пример, upshot и jampshot Входные процедуры MPE используются, чтобы создать логфай- лы (отчеты) о событиях, которые имели место при выполнении парал- лельной программы. Форматы этих процедур представлены ниже. Форматы для С int MPE_Init_log (void) int MPE_Start_log (void) int MPE_Stop_log (void) int MPE_Finish_log (char *logfilename) int MPE_Describe_state (int start, int end, char *name, char *color) int MPE_Describe_event (int event, char *name) int MPE_Log_event (int event, int intdata char *chardata) Форматы для Fortran MPE_INIT_LOG( ) MPE_FINISH_LOG (LOGFILENAME) CHARACTER*(*) LOGFILENAME MPE_START_LOG ( ) MPE_STOP_LOG ( ) MPE-DESCRIBE_STATE(START, END, NAME, COLOR) INTEGER START, END CHARACTER*(*) NAME, COLOR MPE_DESCRIBE_EVENT(EVENT, NAME) INTEGER EVENT CHARACTER*(*) NAME MPE_LOG_EVENT(EVENT, INTDATA, CHARDATA) INTEGER EVENT, INTDATA CHARACTER*(*) CHARDATA Эти процедуры позволяют пользователю включать только те со- бытия, которые ему интересны в данной программе. Базовые проце- дуры − MPE_Init_log , MPE_Log_event и MPE_Finish_log 42 MPE_Init_log должна вызываться всеми процессами, чтобы ини- циализировать необходимые структуры данных. MPE_Finish_log со- бирает отчеты из всех процессов, объединяет их, выравнивает по об- щей шкале времени. Затем процесс с номером 0 в коммуникаторе MPI_COMM_WORLD записывает отчет в файл, имя которого указа- но в аргументе. Одиночное событие устанавливается процедурой MPE_Log_event , которая задает тип события (выбирает пользова- тель), целое число и строку для данных. Чтобы разместить логфайл, который будет нужен для анализа или для программы визуализации (подобной upshot), процедура MPE_Describe_state позволяет доба- вить события и описываемые состояния, указать точку старта и окон- чания для каждого состояния. При желании для визуализации отчета можно использовать цвет. MPE_Stop_log и MPE_Start_log предна- значены для того, чтобы динамически включать и выключать созда- ние отчета. Эти процедуры используются в одной из профилирующих библио- тек, поставляемых с дистрибутивом для автоматического запуска со- бытий библиотечных вызовов MPI. Две переменные среды TMPDIR и MPE LOG FORMAT нужны пользователю для установки некоторых параметров перед генерацией логфайлов. MPE LOG FORMAT – определяет формат логфайла, полученного после исполнения приложения, связанного с MPE–библиотекой. MPE LOG FORMAT может принимать только значения CLOG , SLOG и ALOG . Когда MPE LOG FORMAT установлен в NOT , предполага- ется формат CLOG TMPDIR – описывает директорий, который используется как вре- менная память для каждого процесса. По умолчанию, когда TMPDIR есть NOT , будет использоваться “ /tmp ”. Когда пользователю нужно получить очень длинный логфайл для очень длинной MPI–работы, пользователь должен убедиться, что TMPDIR достаточно велик, что- бы хранить временный логфайл, который будет удален, если объеди- ненный файл будет создан успешно. 2.4. СРЕДСТВА ПРОСМОТРА ЛОГФАЙЛОВ Существует четыре графических средства визуализации, распро- страняемых вместе с MPE: upshot, nupshot, Jumpshot-2 и Jumpshot-3. Из этих четырех просмотрщиков логфайлов только три построены с помощью MPE. Это upshot, Jumpshot-2 и Jumpshot-3. 43 Upshot и Nupshot. Один из используемых инструментов называет- ся upshot. Самый простой вид экрана Upshot показан на рис. 2.2. Ре- зультат представлен в виде полос, по одной полосе на каждый про- цесс. Каждая полоса состоит из участков разного цвета (для черно- белых мониторов цвет заменяется различными штриховками). Каж- дому цвету соответствует состояние процесса определенного типа. Внизу приведены отметки времени, начинающиеся от нуля. Такое представление позволяет визуально определить состояние любого процесса в любой момент времени. Рис. 2.2. Представление результатов профилирования с помощью upshot Существуют и более сложные изображения окон, которые позволяют менять размер изображения по горизонтали или вертикали, центрировать на любой точке дисплея, выбранной мышью. Jumpshot-2 и Jumpshot-3. Существует еще две версии, постав- ляемых вместе с MPE. Это Jumpshot-2 и Jumpshot-3, развившиеся из Upshot и Nupshot. Обе написаны на Java и являются графическими средствами визуализации для интерпретации двоичных файлов трасс, которые показывают их на дисплее. Конкретные сведения по средствам просмотра обычно представ- лены в соответствующей реализации MPICH. КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАНИЯ К ГЛАВЕ 2 Контрольные вопросы к 2.1 1. Что такое реализация MPI? 2. Что такое MPICH? 3. Укажите основные функции MPICH. 4. Дайте определение интерфейса абстрактного прибора ADI. 44 5. Какие типы ADI известны? 6. Что такое канальный интерфейс? 7. Что такое прямая реализация MPICH? 8. Какие протоколы используются для обмена сообщениями между процессами? Контрольные вопросы к 2.2 1. Как производится запуск с помощью команды MPIRun? 2. Как задается число процессов при запуске с MPIRun? 3. Что выполняет опция –localonly? 4. Для чего используется процедура MPIConfig? 5. Для чего используется команда MPIRegister? Контрольные вопросы к 2.3 1. Что такое библиотека MPE, ее назначение? 2. Основные функции MPE? 3. Что такое профилирование? 4. Какова методика оценки эффективности вычислений? 5. Что такое регистрация, логфайлы? 6. Как создается файл регистрации? 7. Какие процедуры используются при создании логфайлов? 8. Опишите процесс создания логфайлов на примере программы вычисления числа π. Контрольные вопросы к 2.4 1. Какие способы анализа логфайлов Вы знаете? 2. Какое различие между форматами логфайлов ALOG, CLOG и SLOG? 3. Какие средства просмотра логфайлов графического типа Вы знаете? 4. Объясните структуру изображения, создаваемого инструментом upshot? |