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

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

101

Контрольные вопросы к 3.6.

1. Необходимы ли функции, описанные в данном разделе, при стандартном

коммуникационном режиме? Почему?

2. Что произойдет при вызове функции MPI_Buffer_attach, если недостаточно

памяти для буфера?

3. Сколько буферов можно присоединить к процессу за один вызов

MPI_Buffer_attach?

4. В каком режиме должны быть посланы сообщения для использования буфера

в MPI_Buffer_attach?

5. Когда функция MPI_Buffer_detach может быть вызвана?

Контрольные вопросы к 3.7.

1. В чем различие между блокирующим и неблокирующим обменом?

2. Что такое скрытые запросы?

3. Верен ли вызов функции MPI_IRecv(buf, 1, MPI_INT, 3, tag, comm, &status);

для того, чтобы принять одно целое число от процесса 3 (считаем, что все пе-

ременные описаны корректно, значение переменной tag – правильное)?

4. Определите понятие “завершение операции посылки” для разных коммуника-

ционных режимов.

5. Определите понятие “завершение операции приема” для разных коммуника-

ционных режимов.

6. Что такое активный и неактивный дескриптор?

7. В чем различие использования MPI_Wait и MPI_Test?

8. Означает ли возврат из функции MPI_Wait, что все процессы дошли до барье-

ра или отправитель вернулся из функции MPI_Send, или получатель вернулся

из функции MPI_Recv, или закончилась асинхронно запущенная операция?

9. Как изменится код программы в примере 3.10, если вместо MPI_Wait исполь-

зовать MPI_Test?

10. Какие значения имеет status в примере 3.10 при вызове MPI_Wait?

11. Какие свойства неблокирующего парного обмена должны быть гарантирова-

ны правильной реализацией MPI?

12. Что произойдет при выполнении программы из примера 3.11, если не будет

выполняться свойство очередности?

13. Что произойдет при выполнении программы из примера 3.12, если не будет

выполняться свойство продвижение обмена?

14. Закончилась одна или все из асинхронно запущенных операций, ассоцииро-

ванных с указанными в списке параметров идентификаторами requests, если

значение параметра flag равно 1 при возврате из функции MPI_TestAll?

15. В чем различие использования функций MPI_Waitany, MPI_Waitall,

MPI_Waitsome?

16. В чем различие использования функций MPI_Waitany, MPI_Testany?

17. Если несколько операций из массива активных запросов могут завершиться

одновременно при вызове MPI_Waitany, какой номер процесса будет выбран?

18. Что означает код MPI_ERR_Pending в статусе при выполнении функции

MPI_Waitall?

102

19.

Почему код, в примере 3.14 с использованием MPI_Waitsome дает правиль-

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

MPI_Waitany, при котором имеет место невозможность обмена?

Контрольные вопросы к 3.8

1. В каком случае возникает необходимость проверять входные сообщения без

их реального приема?

2. Какая функция позволяет отменить ждущие сообщения? В каких ситуациях

это необходимо?

3. В чем различие в использовании MPI_Probe и MPI_Iprobe?

4. Что может произойти при выполнении кода в примере 3.15, если не исполь-

зовать блокируемую пробу для ожидания входного сообщения?

5. Что произойдет при выполнении программы в примере 3.15, если количество

процессов будет 1 , 2, больше 3?

6. Как изменить код программы в примере 3.16, чтобы она была корректна и

выполнялась для количества процессов больше 3?

7. Как завершить операцию обмена, которую маркирует функция MPI_Cancel?

8. Как определить, что операция обмена была отменена функцией MPI_Cancel?

Контрольные вопросы к 3.9

1. Может ли быть получателем и отправителем один и тот же процесс в комби-

нируемой операции send–receive?

2. Может ли быть получено сообщение обычной операцией приема, если оно по-

слано операцией send–receive?

3. Какой режим обменов осуществляет операция send–receive – блокирующий

или неблокирующий?

4. В чем отличие функций MPI_Sendrecv и MPI_Sendrecv_replace?

5. В каком случае может понадобиться "фиктивный" отправитель или получа-

тель для коммуникаций?

6. Каков результат обмена с процессом, который имеет значение

MPI_PROC_NULL?

7. Каковы значения статуса и тэга, если прием происходит от процесса, который

имеет значение MPI_PROC_NULL?

Контрольные вопросы к 3.10

1. Как осуществить обмен данными, которые не непрерывно расположены в па-

мяти, не используя производные типы данных?

2. Почему лучше один раз вызвать функцию приемопередачи со сложным ти-

пом, чем много раз с простым?

3. Есть ли различие при пересылке массива следующими двумя способами:

MPI_Send( a, 16, MPI_INT, ... );

MPI_Send( a, 1, intArray16, ... );

если

int a[16];

MPI_Datatype intArray16;

MPI_Type_contiguous( 16, MPI_INT, &intArray16 )

103

MPI_Type_commit( &intArray16 )?

4. Опишите структуру данных, которая создается при вызове:

MPI_Type_vector( 5, 1, 7, MPI_DOUBLE, &newtype );

5. Эквивалентны ли следующие обращения ( n – произвольно):

MPI_Type_contiguous (count, oldtype, newtype);

MPI_Type_vector (count, 1, 1, oldtype, newtype);

MPI_Type_vector (1, count, n, oldtype, newtype);

6. В чем различие между производными типами, созданными двумя способами?

MPI_Type_vector ( 5, 1, 7, MPI_DOUBLE, &newtype );

MPI_Type_hvector( 5, 1, 7, MPI_DOUBLE, &newtype );

7. Опишите параметры функции

MPI_Type_struct(3, block_lengths, displs, typelist,message_typ);

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

данных следующего типа:

typedef struct { float a; float b; int n; } INDATA_TYPE

8. Какая операция в С эквивалентна вызову функции MPI_Address?

9. Функция MPI_Type_size возвращает размер элемента в байтах или в количе-

стве элементов старого типа, содержащегося в новом?

10. Нужно ли перед вызовом функции MPI_Type_struct обратиться к функции

MPI_Type_commit?

11. Когда и почему необходимо использовать функцию MPI_Type_free?

12. Обьясните разные результаты, полученные функциями MPI_GET_COUNT и

MPI_GET_ELEMENTS в примере 3.20.

13. Эквивалентен ли вызов

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

вызовам

MPI_Type_contiguous(count, datatype, newtype)

MPI_Type_commit(newtype)

MPI_Send(buf, 1, newtype, dest, tag, comm)?

14. Сколько производных типов данных создается в примере 3.21? Предложите

вариант эквивалентного кода, заменив MPI_TYPE_HVECTOR на

MPI_TYPE_VECTOR.

15. Предложите другие способы задания типа, эквивалентные по результату

функции MPI_TYPE_INDEXED в примере 3.22.

16. Какое значение получаем при вызове

CALL MPI_TYPE_EXTENT ( MPI_REAL, sizeofreal, ierr)

в примере 3.23?

17. Сравните программы в примерах 3.23 и 3.24 для решения одной и той же за-

дачи транспонирования матриц. Какой вариант предпочтительнее? Почему?

18. Как выполнить посылку массива структур из примера 3.25, не используя

MPI_Type_struct?

19. Как измениться код в примере 3.26, если в union будет полей больше?

Контрольные вопросы к 3.11

1. Какие возможности обеспечивают функции pack/unpack, которые недоступны

в MPI другим способом?

104

Укажите разницу при использовании параметра count в разных функциях:

MPI_Recv (…, count, …) и MPI_Unpack (…,count,…) .

3. Можно ли распаковывать результат как один упакованный объект, если пе-

ред посылкой происходила упаковка двух объектов?

4. Предложите вариант посылки данных в примере 3.26 без использования

MPI_Pack.

5. Почему в примере 3.27 не нужно вызывать функцию MPI_Unpack после

приема результата?

6. Почему в пример 3.28 используется две функции MPI_Unpack при приеме,

если при посылке использовали одну функцию MPI_Pack?

Задания для самостоятельной работы

3.1. Напишите программу, в которой каждый процесс MPI печатает “Hello

Word from process i for n”, где i – номер процесса в MPI_COMM_WORLD, а n –

размер MPI_COMM_WORLD.

3.2. Напишите программу, в которой определено только два процесса. В од-

ном из них осуществляется генерация случайных чисел, количество которых за-

дает пользователь. Второй процесс получает эти числа, складывает их, посылает

результат в первый процесс. Результат выводится на экран.

3.3. Напишите программу, которая рассылает данные от процесса с номером 0

всем другим процессам по конвейеру. Этот означает, что процесс i должен при-

нять данные от i-1 и послать их процессу i + 1, и так до тех пор, пока не будет

достигнут последний процесс. Процесс с номером 0 читает данные (целые) от

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

3.4. Выполните задание 3.3, замкнув вычисления по кругу, т.е. последний про-

цесс передает данные нулевому, который выводит их на экран.

3.5. Выполните задание 3.3, используя обмен MPI_Sendrecv.

3.6. Напишите программу, которая проверяет, в каком порядке осуществляет-

ся передача сообщений. Для этого можно допустить, что все процессы за исклю-

чением процесса 0 посылают 100 сообщений процессу 0. Пусть процесс 0 распе-

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

MPI_ANY_TAG в MPI_Recv.

3.7. Выполните задание 3.6, используя неблокируемый прием MPI_IRecv.

3.8. Напишите программу для измерения времени передачи вещественных

данных двойной точности от одного процесса другому. Для усреднения наклад-

ных расходов следует: повторить достаточное количество операций пересылок

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

100000/size итераций для целых size), повторить тестирование несколько раз (на-

пример, 10) и усреднить результаты.

3.9. Выполните задание 3.8, используя MPI_SSend. Сравните характеристики

с теми, которые получаются при иcпользовании MPI_Send.

3.10. Выполните задание 3.8, используя MPI_BSend. Сравните характеристики

с теми, которые получаются при иcпользовании MPI_Send.

3.11. Выполните задание 3.8, используя MPI_RSend. Сравните характеристики

с теми, которые получаются при иcпользовании MPI_Send .

3.12. Выполните задание 3.8, используя MPI_ISend, MPI_IRecv, MPI_Wait.

Сравните характеристики с теми, которые получаются при иcпользовании

105

MPI_Send и MPI_Recv. Этот тест измеряет эффективную полосу пропускания и

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

3.13. Напишите программу для измерения времени, необходимого для выпол-

нения пересылки вектора из 1000 элементов MPI_DOUBLE со страйдом 24 между

элементами. Используйте MPI_Type_vector для описания данных. Используйте те

же приемы, как в задании 3.8 для усреднения вариаций и накладных расходов.

3.14. Выполните задание 3.13, используя MPI_Type_struct, чтобы сформиро-

вать структуру со страйдом. Сравните результаты с результатами в 3.13.

3.15. Выполните задание 3.13, используя MPI_DOUBLE и цикл для самостоя-

тельной упаковки и распаковки (то есть не используйте типы данных MPI). Срав-

ните результаты с результатами в 3.13, 3.14.

3.16. Напишите программу, которая пересылает процессу (можно самому се-

бе) часть трехмерного массива (задаются значения для каждой размерности), ис-

пользуя производные типы данных MPI_Type_vector, MPI_Type_Hvector.

3.17. Выполните задание 3.16, используя MPI_Pack, MPI_Unpack.

3.18. Напишите программу, которая позволяет копировать нижнюю треуголь-

ную часть массива A в нижнюю треугольную часть массива B, используя

MPI_Type_indexed.

3.19. Напишите программу транспонирования матрицы, используя типы дан-

ных MPI_Type_vector, MPI_Type_Hvector.

3.20. Напишите программу транспонирования матрицы, используя производ-

ные типы данных MPI_Type_struct.

Глава 4. КОЛЛЕКТИВНЫЕ ВЗАИМОДЕЙСТВИЯ

ПРОЦЕССОВ

4.1. ВВЕДЕНИЕ

К операциям коллективного обмена относятся (рис. 4.1):

• Барьерная синхронизация всех процессов группы (параграф 4.2.1).

• Широковещательная передача (broadcast) от одного процесса всем

остальным процессам группы (параграф 4.2.2).

• Сбор данных из всех процессов группы в один процесс (параграф

4.2.3).

• Рассылка данных одним процессом группы всем процессам груп-

пы (параграф 4.2.4).

• Сбор данных, когда все процессы группы получают результат (па-

раграф 4.2.5). Этот вариант представлен на рис. 4.1 как “allgather”.

• Раздача/сбор данных из всех процессов группы всем процессам

группы (параграф 4.2.6). Этот вариант называется также полным

обменом или all-to-all.

• Глобальные операции редукции, такие как сложение, нахождение

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

106

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

процесс (параграф 4.3).

• Составная операция редукции и раздачи (параграф 4.3.5).

• Префиксная операция редукции, при которой в процессе i появля-

ется результат редукции 0, 1, …, i, i ≤ n, где n – число процессов в

группе (параграф 4.3.6).

Рис. 4.1. Операции коллективного обмена.

В каждом случае строка прямоугольника представляет данные одного процесса, поэтому, напри-

мер, в операции broadcast сначала один процесс содержит A0, но после операции все процессы

содержат это значение.

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

сами в группе коммуникационных функций с соответствующими ар-

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

данных, и они должны совпадать у процесса-отправителя и процесса-

получателя. Один из ключевых аргументов – это коммуникатор, кото-

рый определяет группу участвующих в обмене процессов и обеспечи-

вает контекст для этой операции.

Различные коллективные операции (широковещание, сбор дан-

ных) имеют единственный процесс-отправитель или процесс-

получатель. Такие процессы называются корневыми (root). Некоторые

A0 A1 A2 A3

A B C D

A0 A1 A2 A3

B0 B1 B2 B3

C0 C1 C2 C3

D0 D1 D2 D3

A0 B0 C0 D0

A1 B1 C1 D1

A2 B2 C2 D2

A3 B3 C3 D3

broadcast

scatter

athe

allgather

alltoall

107

аргументы в коллективных функциях определены как “существенные

только для корневого процесса” и игнорируются для всех других уча-

стников операции.

Условия соответствия типов для коллективных операций более

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

коллективных операций количество посланных данных должно точно

соответствовать количеству данных, описанных в процессе-получа-

теле. Вызов коллективной функции может возвращать управление

сразу, как только его участие в коллективной операции завершено.

Завершение вызова показывает, что процесс-отправитель может обра-

щаться к буферу обмена. Это не означает, что другие процессы в

группе завершили операцию. Таким образом, вызов операции коллек-

тивного обмена может иметь эффект синхронизации всех процессов в

группе. Это утверждение не относится к барьерной функции.

Вызовы коллективных операций могут использовать те же комму-

никаторы, что и парный обмен, при этом MPI гарантирует, что сооб-

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

сообщениями, созданными парным обменом.

Ключевым понятием в коллективных функциях является группа

участвующих процессов, но в качестве явного аргумента выступает

коммуникатор. Коммуникатор понимается как идентификатор груп-

пы, связанный с контекстом. Не разрешается использовать в качестве

аргумента коллективной функции интер-коммуникатор (коммуника-

тор, соединяющий две группы).

4.2. КОЛЛЕКТИВНЫЕ ОПЕРАЦИИ

4.2.1. Барьерная синхронизация

MPI_BARRIER (comm)

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

int MPI_Barrier (MPI_Comm comm)

MPI_BARRIER (COMM, IERROR)

INTEGER COMM, IERROR

void MPI::Intracomm::Barrier() const

Функция барьерной синхронизации MPI_BARRIER блокирует

вызывающий процесс, пока все процессы группы не вызовут ее. В ка-

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

цессы в группе вызовут процедуру.

108

4.2.2. Широковещательный обмен

Функция широковещательной передачи MPI_BCAST посылает

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

себя. Она вызывается всеми процессами группы с одинаковыми аргу-

ментами для

comm, root. В момент возврата управления содержимое

корневого буфера обмена будет уже скопировано во все процессы.

MPI_BCAST(buffer, count, datatype, root, comm )

INOUT buffer адрес начала буфера (альтернатива)

IN count количество записей в буфере (целое)

IN datatype тип данных в буфере (дескриптор)

IN root номер корневого процесса (целое)

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

int MPI_Bcast(void* buffer, int count, MPI_Datatype datatype, int root,

MPI_Comm comm )

MPI_BCAST(BUFFER, COUNT, DATATYPE, ROOT, COMM, IERROR)

<type> BUFFER(*)

INTEGER COUNT, DATATYPE, ROOT, COMM, IERROR

void MPI::Intracomm::Bcast(void* buffer, int count,

const Datatype& datatype,int root) const

В аргументе datatype можно задавать производные типы данных.

Сигнатура типа данных

count, datatype любого процесса обязана сов-

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

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

попарно для корневого и каждого другого процессов. Такое ограниче-

ние имеют и все другие коллективные операции, выполняющие пере-

мещение данных.

Пример 4.1. Широковещательная передача 100 целых чисел от про-

цесса 0 каждому процессу в группе.

MPI_Comm comm;

int array[100];

int root = 0;

MPI_Bcast( array, 100, MPI_INT, root, comm );

4.2.3. Сбор данных

При выполнении операции сборки данных MPI_GATHER каждый

процесс, включая корневой, посылает содержимое своего буфера в

корневой процесс.

109

Корневой процесс получает сообщения, располагая их в порядке

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

бы каждый из n процессов группы (включая корневой процесс) вы-

полнил вызов

MPI_Send (sendbuf, sendcount, sendtype, root, …),

и корневой процесс выполнил n вызовов

MPI_Recv(recvbuf + i * recvcount * extent(recvtype), recvcount, recvtype, i, …),

где extent(recvtype) – размер типа данных, получаемый с помощью

MPI_Type_extent().

MPI

GATHER( sendbuf, sendcount, sendt

pe, recvbuf, recvcount,

recvtype, root, comm)

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

IN sendcount количество элементов в отсылаемом сообщении (целое)

IN sendtype тип элементов в отсылаемом сообщении (дескриптор)

OUT recvbuf

начальный адрес буфера процесса сборки данных (альтерна-

тива, существенен только для корневого процесса)

IN recvcount

количество элементов в принимаемом сообщении (целое, имеет

значение только для корневого процесса)

IN recvtype

тип данных элементов в буфере процесса-получателя

(дескриптор)

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

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

int MPI_Gather(void* sendbuf, int sendcount, MPI_Datatype sendtype, void* recvbuf,

int recvcount, MPI_Datatype recvtype, int root, MPI_Comm comm)

MPI_GATHER(SENDBUF, SENDCOUNT, SENDTYPE, RECVBUF, RECVCOUNT,

RECVTYPE, ROOT, COMM, IERROR)

<type> SENDBUF(*), RECVBUF(*)

INTEGER SENDCOUNT, SENDTYPE, RECVCOUNT, RECVTYPE, ROOT,

COMM, IERROR

void MPI::Intracomm::Gather(const void* sendbuf, int sendcount, const Datatype&

sendtype, void* recvbuf, int recvcount, const Datatype& recvtype, int root) const

В общем случае как для sendtype, так и для recvtype разрешены

производные типы данных. Сигнатура типа данных

sendcount,

sendtype

у процесса i должна быть такой же, как сигнатура recvcount,

recvtype

корневого процесса. Это требует, чтобы количество послан

110

ных и полученных данных совпадало попарно для корневого и каж-

дого другого процессов. Разрешается различие в картах типов между

отправителями и получателями.

В корневом процессе используются все аргументы функции, в то

время как у остальных процессов используются только аргументы

sendbuf, sendcount, sendtype, root, comm. Аргументы comm и root

должны иметь одинаковые значения во всех процессах.

Описанные в функции MPI_GATHER количества и типы данных

не должны являться причиной того, чтобы любая ячейка корневого

процесса записывалась бы более одного раза. Такой вызов является

неверным.

Аргумент recvcount в главном процессе показывает количество

элементов, которые он получил от каждого процесса, а не общее ко-

личество полученных элементов.

MPI_GATHERV ( sendbuf, sendcount, sendtype, recvbuf, recvcounts, displs,

recvtype, root, comm)

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

IN sendcount количество элементов в отсылаемом сообщении (целое)

IN sendtype тип элементов в отсылаемом сообщении (дескриптор)

OUT recvbuf

начальный адрес буфера процесса сборки данных (альтер-

натива, существенно для корневого процесса)

IN recvcounts

массив целых чисел (по размеру группы), содержащий ко-

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

цессов (используется корневым процессом)

IN displs

массив целых чисел (по размеру группы). Элемент i опре-

деляет смещение относительно recvbuf, в котором размещаются

данные из процесса i (используется корневым процессом)

IN recvtype

тип данных элементов в буфере процесса-получателя

(дескриптор)

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

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

int MPI_Gatherv(void* sendbuf, int sendcount, MPI_Datatype sendtype, void* recvbuf,

int *recvcounts, int *displs, MPI_Datatype recvtype, int root, MPI_Comm comm)

MPI_GATHERV(SENDBUF, SENDCOUNT, SENDTYPE, RECVBUF,

RECVCOUNTS, DISPLS, RECVTYPE, ROOT, COMM, IERROR)

<type> SENDBUF(*), RECVBUF(*)

INTEGER SENDCOUNT, SENDTYPE, RECVCOUNTS(*), DISPLS(*),

RECVTYPE, ROOT, COMM, IERROR