Шпаковский Г.И., Серикова Н.В. Программирование для многопроцессорных систем в стандарте MPI

Подождите немного. Документ загружается.

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.

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 и Jump-

shot-3. Из этих четырех просмотрщиков логфайлов только три

построены с помощью MPE. Это upshot, Jumpshot-2 и Jumpshot-3.

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.

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. Какие средства просмотра логфайлов графического типа Вы знаете?

Р А З Д Е Л 2. БИБЛИОТЕКА ФУНКЦИЙ MPI

Глава 3. ПАРНЫЕ МЕЖПРОЦЕССНЫЕ ОБМЕНЫ

3.1. ВВЕДЕНИЕ

Главы 3 − 6 написаны в соответствии со стандартом MPI-1.2 [20,

11], также использовались книги [4, 5, 6,7] и другие документы.

Передача и прием сообщений процессами – это базовый коммуни-

кационный механизм

MPI. Основными операциями парного обмена

являются операции

send (послать) и receive (получить). Их исполь-

зование иллюстрируется следующим примером:

#include "mpi.h"

main( argc, argv ) 7

int argc;

char **argv;

{ char message[20];

int myrank;

MPI_Status status;

MPI_Init( &argc, &argv );

MPI_Comm_rank( MPI_COMM_WORLD, &myrank );

if (myrank == 0) /* код для процесса 0 */

{ strcpy(message,"Hello, there");

MPI_Send(message,strlen(message),MPI_CHAR,1,99,

MPI_COMM_WORLD);

}

else /* код для процесса 1 */

{ MPI_Recv(message, 20, MPI_CHAR, 0, 99, MPI_COMM_WORLD,

&status);

printf("received :%s:\n", message);

}

MPI_Finalize();

}

В этом примере процесс с номером 0 (myrank = 0) посылает со-

общение процессу с номером 1, используя операцию посылки

MPI_Send. Эта операция описывает буфер посылающего процесса, из

которого извлекаются посылаемые данные. В приведенном примере

посылающий буфер состоит из накопителя в памяти процесса 0, со-

держащего переменную

message. Размещение, размер и тип буфера

посылающего процесса описываются первыми тремя параметрами

операции

send. Посланное сообщение будет содержать 13 символов

этой переменной. Операция посылки также связывает с сообщением

его атрибуты. Атрибуты определяют номер процесса-получателя со-

общения и содержат различную информацию, которая может быть

использована операцией

receive, чтобы выбрать определенное сооб-

щение среди других. Последние три параметра операции посылки

описывают атрибуты посланного сообщения. Процесс 1 (

myrank = 1)

получает это сообщение, используя операцию приема

MPI_Recv, и

данные сообщения записываются в буфер процесса-получателя. В

приведенном примере буфер получателя состоит из накопителя в па-

мяти процесса один, содержащего строку

message. Первые три пара-

метра операции приема описывают размещение, размер и тип буфера

приема. Следующие три параметра необходимы для выбора входного

сообщения. Последний параметр необходим для возврата информации

о только что полученном сообщении.

3.2. ОПЕРАЦИИ БЛОКИРУЮЩЕЙ ПЕРЕДАЧИ

И БЛОКИРУЮЩЕГО ПРИЕМА

3.2.1. Блокирующая передача

MPI_SEND(buf, count, datatype, dest, tag, comm)

IN buf начальный адрес буфера посылки сообщения (альтернатива)

IN count число элементов в буфере посылки (неотрицательное целое)

IN datatype тип данных каждого элемента в буфере передачи (дескриптор)

IN dest номер процесса-получателя (целое)

IN tag тэг сообщения (целое)

IN comm коммуникатор (дескриптор)

int MPI_Send (void* buf, int count, MPI_Datatype datatype, int dest, int tag,

MPI_Comm comm)

MPI_SEND(BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR)

<type> BUF(*)

INTEGER COUNT, DATATYPE, DEST, TAG, COMM, IERROR

void MPI::Comm::Send (const void* buf, int count, const MPI::Datatype& datatype,

int dest, int tag) const

Семантика этого блокирующего вызова описана в 3.4.

3.2.2. Данные в сообщении

Буфер посылки описывается операцией MPI_SEND, в которой

указано количество последовательных элементов, тип которых указан

в поле

datatype, начиная с элемента по адресу buf. Длина сообщения

задается числом элементов, а не числом байт.

Число данных count в сообщении может быть равно нулю, это оз-

начает, что область данных в сообщении пуста. Базисные типы дан-

ных в сообщении соответствуют базисным типам данных используе-

мого языка программирования. Список возможного соответствия этих

типов данных для языка Fortran и MPI представлен ниже.

MPI datatype Fortran datatype

MPI_INTEGER INTEGER

MPI_REAL REAL

MPI_DOUBLE_PRECISION DOUBLE PRECISION

MPI_COMPLEX COMPLEX

MPI_LOGICAL LOGICAL

MPI_CHARACTER CHARACTER(1)

MPI_BYTE

MPI_PACKED

Список соответствия типов данных для языка С и MPI дан ниже.

MPI datatype C datatype

MPI_CHAR signed char

MPI_SHORT signed short int

MPI_INT signed int

MPI_LONG signed long int

MPI_UNSIGNED_CHAR unsigned char

MPI_UNSIGNED_SHORT unsigned short int

MPI_UNSIGNED unsigned int

MPI_UNSIGNED_LONG unsigned long int

MPI_FLOAT float

MPI_DOUBLE double

MPI_LONG_DOUBLE long double

MPI_BYTE

MPI_PACKED

Типы MPI_BYTE и MPI_PACKED не имеют соответствия в язы-

ках С или Fortran. Значением типа

MPI_BYTE является байт. Байт не

интерпретируется и отличен от символа. Различные машины могут

иметь различное представление для символов или могут использовать

для представления символов более одного байта. С другой стороны,

байт имеет то же самое двоичное значение на всех машинах.

3.2.3. Атрибуты сообщения

В дополнение к описанию данных сообщение несет информацию,

которая используется, чтобы различать и выбирать сообщения. Эта

информация состоит из фиксированного количества полей, которые в

совокупности называются

атрибутами сообщения. Эти поля таковы:

source, destination, tag, communicator (номер процесса-отправителя

сообщения, номер процесса-получателя, тэг, коммуникатор).

Целочисленный аргумент тэг используется, чтобы различать типы

сообщений. Диапазон значений тэга находится в пределах 0,…,UB,

где верхнее значение UB зависит от реализации. MPI требует, чтобы

UB было не менее 32767.

Аргумент comm описывает коммуникатор, который используется

в операции обмена. Коммуникатор описывает коммуникационный

контекст коммуникационной операции. Сообщение всегда принима-

ется внутри контекста, в котором оно было послано; сообщения, по-

сланные в различных контекстах, не взаимодействуют.

Коммуникатор также описывает ряд процессов, которые разделя-

ют этот коммуникационный контекст. Эта группа процессов упоря-

дочена, и процессы определяются их номером внутри этой группы:

диапазон значений для

dest есть 0,...,n-1, где n есть число процессов в

группе

В MPI предопределен коммуникатор MPI_COMM_WORLD. Он

разрешает обмен для всех процессов, которые доступны после ини-

циализации MPI, и процессы идентифицируются их номерами в груп-

пе

MPI_COMM_WORLD.

3.2.4. Блокирующий прием

MPI_RECV (buf, count, datatype, source, tag, comm, status)

OUT buf начальный адрес буфера процесса-получателя (альтернатива)

IN count число элементов в принимаемом сообщении (целое)

IN datatype тип данных каждого элемента сообщения (дескриптор)

IN source номер процесса-отправителя (целое)

IN tag тэг сообщения (целое)

IN comm коммуникатор (дескриптор)

OUT status параметры принятого сообщения (статус)

int MPI_Recv (void* buf, int count, MPI_Datatype datatype, int source, int tag,

MPI_Comm comm, MPI_Status *status)

MPI_RECV(BUF, COUNT, DATATYPE, SOURCE, TAG, COMM, STATUS,

IERROR)

<type> BUF(*)

INTEGER COUNT, DATATYPE, SOURCE, TAG, COMM,

STATUS(MPI_STATUS_SIZE), IERROR

void MPI::Comm::Recv (void* buf, int count, const MPI::Datatype& datatype,

int source, int tag) const

Буфер получения состоит из накопителя, содержащего последова-

тельность элементов, размещенных по адресу

buf.

Тип элементов указан в поле datatype. Длина получаемого сооб-

щения должна быть равна или меньше длины буфера получения, в

противном случае будет иметь место ошибка переполнения. Если со-

общение меньше размера буфера получения, то в нем модифицируют-

ся только ячейки, соответствующие длине сообщения.

Прием сообщения осуществляется, если его атрибуты соответст-

вуют значениям источника, тэга и коммуникатора, которые указаны в

операции приема. Процесс-получатель может задавать значение

MPI_ANY_SOURCE для отправителя и/или значение

MPI_ANY_TAG для тэга, определяя, что любой отправитель и/или

тэг разрешен. Нельзя задать произвольное значение для

comm. Следо-

вательно, сообщение может быть принято, если оно адресовано дан-

ному получателю и имеет соответствующий коммуникатор.

Тэг сообщения задается аргументом tag операции приема. Аргу-

мент отправителя, если он отличен от

MPI_ANY_SOURCE, задается

как номер внутри группы процессов, связанной с тем же самым ком-

муникатором. Следовательно, диапазон значений для аргумента от-

правителя есть

{0,...,n-1} U {MPI_ANY_SOURCE}, где n есть количе-

ство процессов в этой группе.

Отметим ассиметрию между операциями посылки и приема. Опе-

рация приема допускает получение сообщения от произвольного от-

правителя, в то время как в операции посылки должен быть указан

уникальный получатель.

Допускается ситуация, когда имена источника и получателя сов-

падают, то есть процесс может посылать сообщение самому себе (это

небезопасно, поскольку может привести к дедлоку (

deadlock)).

3.2.5. Возвращаемая статусная информация

Источник или тэг принимаемого сообщения могут быть неизвест-

ны, если в операции приема были использованы значения типа

ANY.

Иногда может потребоваться возвратить различные коды ошибок

для каждого запроса. Эта информация возвращается с помощью аргу-

мента

status операции MPI_RECV.

Тип аргумента status определяется MPI. Статусные переменные

размещаются пользователем явно, то есть они не являются системны-

ми объектами.

В языке С status есть структура, которая содержит три поля, назы-

ваемые

MPI_SOURCE, MPI_TAG и MPI_ERROR. Следовательно,

status.MPI_SOURCE, status.MPI_TAG и status.MPI_ERROR со-

держат источник, тэг и код ошибки принятого сообщения.

В языке Fortran status есть массив целых значений размера

MPI_STATUS_SIZE. Константы MPI_SOURCE, MPI_TAG и

MPI_ERROR определяют объекты, которые хранят поля источника,

тэга и ошибки. Следовательно,

status(MPI_SOURCE),

status(MPI_TAG)

и status(MPI_ERROR) содержат соответственно

источник, тэг и код ошибки принимаемого сообщения.

Вызовы передачи сообщений не модифицируют значения полей

кода ошибки статусных переменных. Статусный аргумент также воз-

вращает информацию о длине принятого сообщения. Эта информация

не является доступной непосредственно, как поле статусной перемен-

ной, и требуется вызов

MPI_GET_COUNT, чтобы «декодировать»

эту информацию.

MPI_GET_COUNT(status, datatype, count)

IN status статус операции приема (статус )

IN datatype тип данных каждого элемента приемного буфера (дескриптор)

OUT count количество полученных единиц (целое)

int MPI_Get_count (MPI_Status *status,MPI_Datatype datatype, int *count)

MPI_GET_COUNT(STATUS, DATATYPE, COUNT, IERROR)

INTEGER STATUS(MPI_STATUS_SIZE), DATATYPE, COUNT, IERROR

int Status :: Get_count (const MPI :: Datatype& datatype) const

Операция MPI_GET_COUNT возвращает число полученных эле-

ментов. Аргумент

datatype следует сопоставлять с аргументом из

операции приема, которая устанавливает статусную переменную.

3.3. СООТВЕТСТВИЕ ТИПОВ ДАННЫХ

И ПРЕОБРАЗОВАНИЕ ДАННЫХ

3.3.1. Правила соответствия типов данных

Передача данных содержит следующие три фазы:

1) данные выталкиваются из буфера процесса-отправителя, и части

сообщения объединяются;

2) сообщение передается от отправителя к получателю;

3) данные выделяются из получаемого сообщения и помещаются в

буфер получателя.

Соответствие типов должно отслеживаться на каждой из трех фаз:

• тип каждой переменной в буфере посылки должен соответствовать

типу, указанному для этого элемента в операции посылки;

• тип, описанный в операции посылки, должен соответствовать ти-

пу, указанному в операции приема;

• тип каждой переменной в приемном буфере должен соответство-

вать типу, указанному для нее в операции приема.

Программа, в которой не соблюдаются эти три правила, является

неверной.

Типы отправителя и получателя (фаза два) соответствуют друг

другу, если обе операции используют одинаковые названия. Это озна-

чает, что

MPI_INTEGER соответствует MPI_INTEGER, MPI_REAL

соответствует MPI_REAL, и так далее.

Тип переменной в хост–программе (главной программе) соответ-

ствует типу, указанному в операции обмена, если название типа дан-

ных, используемое этой операцией, соответствует базисному типу пе-

ременной хост–программы. Например, элемент с названием типа

MPI_INTEGER соответствует в языке Fortran переменной типа

INTEGER. Таблица, описывающая соответствие для языков Fortran и

C, представлена в параграфе 3.2.2.

Имеется два исключения из этого последнего правила: элемент с

названием типа

MPI_BYTE или MPI_PACKED может соответство-

вать любому байту памяти (на байт-адресуемой машине), без учета

типа переменной, которая содержит этот байт. Тип

MPI_PACKED

используется для передачи данных, которые были явно упакованы,

или для получения данных, которые будут явно распакованы (3.10).

Тип

MPI_BYTE позволяет передавать двоичное значение байта из

памяти.