4. Коллективные операции и их исполнение
Коллективные операции в MPI выполняют следующие функции:
Помимо встроенных, пользователь может определять использовать свои собственные коллективные операции. Для этого служат функции MPI_Op_create и MPI_Op_free, а также специальный тип данныхMPI_Usr_function.
Алгоритм исполнения всех коллективных функций одинаков: в каждом процессе имеется массив с данными и над элементами с одинаковым номеров в каждом из процессов производится одна и та же операция (сложение, произведение, вычисление максимума/минимума и т.п.). Встроенные коллективные функции отличаются друг от друга способом размещения результатов в процессах.
MPI_Reduce
Данная функция выполняет коллективную операцию во всех процессах группы и помещает результат в процесс с рангом root.
Формат вызова:
Пример поэлементного суммирования массивов:
Встроенных коллективных операций в MPI насчитывается 12:
Эти функции могут работать только со следующими типами данных (и только ними):
MPI_Allreduce
Применяет коллективную операцию и рассылает результат всем процессам в группе.
Формат вызова:
MPI_Reduce_scatter
Функция применяет вначале коллективную операцию к векторам всех процессов в группе, а затем результирующий вектор разбивается на непересекающиеся сегменты, которые распределяются по процессам.
Формат вызова:
MPI_Scan
Данная операция аналогична функции MPI_Allreduce в том отношении, что после ее выполнения каждый процесс получает результирующий массив. Главное отличие данной функции состоит в том, что содержимое результирующего массива в процессе i является результатом выполнения коллективной операции над массивами из процессов с номерами от 0 до i включительно.
Формат вызова:
6. Организация логических топологий процессов
В терминах MPI, виртуальная топология описывает отображениеMPI процессов на некоторую геометрическую конфигурацию процессоров.
В MPI поддерживается два основных типа топологий – декартовые (решеточные) топологии и топологии в виде графа.
MPI-топологии являются виртуальными – связь между физической структурой параллельной машины и топологией MPI-процессов может и отсутствовать.
Виртуальные топологии строятся на основе групп и коммуникаторов, и “программируется” разработчиком параллельного приложения.
Смысл использования виртуальных топологий заключается в том, что они в некоторых случаях удобны для задач со специфической коммуникационной структурой. Например, декартова топология удобна для задач, в которых обрабатывающие элементы в процессе вычислений обмениваются данными только со своими 4-мя непосредственными соседями.
В примере, показанном ниже, создается декартова топология 4 х 4 из 16 процессов, и каждый процесс сообщает свой ранг своим соседям, получая от них их собственные ранги.
Вывод данной программы на консоль будет следующим:
rank= 0 coords= 0 0 neighbors(u,d,l,r)= -3 4 -3 1
rank= 0 inbuf(u,d,l,r)= -3 4 -3 1
rank= 1 coords= 0 1 neighbors(u,d,l,r)= -3 5 0 2
rank= 1 inbuf(u,d,l,r)= -3 5 0 2
rank= 2 coords= 0 2 neighbors(u,d,l,r)= -3 6 1 3
rank= 2 inbuf(u,d,l,r)= -3 6 1 3
. . . . .
rank= 14 coords= 3 2 neighbors(u,d,l,r)= 10 -3 13 15
rank= 14 inbuf(u,d,l,r)= 10 -3 13 15
rank= 15 coords= 3 3 neighbors(u,d,l,r)= 11 -3 14 -3
rank= 15 inbuf(u,d,l,r)= 11 -3 14 -35.4. Формирование сообщений при помощи упаковки и распаковки данных
Наряду с рассмотренными в п. 5.5.2 методами конструирования производных типов в MPI предусмотрен и явный способ сборки и разборки сообщений, содержащих значения разных типов и располагаемых в разных областях памяти.
Для использования данного подхода должен быть определен буфер памяти достаточного размера для сборки сообщения. Входящие в состав сообщения данные должны быть упакованы в буфер при помощи функции:
где
data – буфер памяти с элементами для упаковки,
count – количество элементов в буфере,
type – тип данных для упаковываемых элементов,
buf – буфер памяти для упаковки,
buflen – размер буфера в байтах,
bufpos – позиция для начала записи в буфер (в байтах от начала буфера),
comm – коммуникатор для упакованного сообщения.
Функция MPI_Pack упаковывает count элементов из буфера data в буфер упаковки buf, начиная с позиции bufpos. Общая схема процедуры упаковки показана на
рис.
5.8а.
Начальное значение переменной bufpos должно быть сформировано до начала упаковки и далее устанавливается функцией MPI_Pack. Вызов функции MPI_Pack осуществляется последовательно для упаковки всех необходимых данных.
bufpos = 0; MPI_Pack(a,1,MPI_DOUBLE,buf,buflen,&bufpos,comm); MPI_Pack(b,1,MPI_DOUBLE,buf,buflen,&bufpos,comm); MPI_Pack(n,1,MPI_INT,buf,buflen,&bufpos,comm);
Для определения необходимого размера буфера для упаковки может быть использована функция:
которая в параметре size указывает необходимый размер буфера для упаковки count элементов типа type.
После упаковки всех необходимых данных подготовленный буфер может быть использован в функциях передачи данных с указанием типа MPI_PACKED.
После получения сообщения с типом MPI_PACKED данные могут быть распакованы при помощи функции:
где
buf – буфер памяти с упакованными данными,
buflen – размер буфера в байтах,
bufpos – позиция начала данных в буфере (в байтах от начала буфера),
data – буфер памяти для распаковываемых данных,
count – количество элементов в буфере,
type – тип распаковываемых данных,
comm – коммуникатор для упакованного сообщения.
Функция MPI_Unpack распаковывает начиная с позиции bufpos очередную порцию данных из буфера buf и помещает распакованные данные в буфер data. Общая схема процедуры распаковки показана на
рис.
5.8б.
Начальное значение переменной bufpos должно быть сформировано до начала распаковки и далее устанавливается функцией MPI_Unpack. Вызов функции MPI_Unpack осуществляется последовательно для распаковки всех упакованных данных, при этом порядок распаковки должен соответствовать порядку упаковки. Так, для ранее рассмотренного примера упаковки для распаковки упакованных данных необходимо выполнить:
bufpos = 0; MPI_Pack(buf,buflen,&bufpos,a,1,MPI_DOUBLE,comm); MPI_Pack(buf,buflen,&bufpos,b,1,MPI_DOUBLE,comm); MPI_Pack(buf,buflen,&bufpos,n,1,MPI_INT,comm);
В заключение выскажем ряд рекомендаций по использованию упаковки для формирования сообщений. Поскольку такой подход приводит к появлению дополнительных действий по упаковке и распаковке данных, то данный способ может быть оправдан при сравнительно небольших размерах сообщений и при малом количестве повторений.
7.1. Декартовы топологии (решетки)
Декартовы топологии, в которых множество процессов представляется в виде прямоугольной решетки (см. п. 1.4.1 и рис. 5.7), а для указания процессов используется декартова система координат, широко применяются во многих задачах для описания структуры имеющихся информационных зависимостей.
Для создания декартовой топологии (решетки) в MPI предназначена функция:
где:
oldcomm – исходный коммуникатор,
ndims – размерность декартовой решетки,
dims – массив длины ndims, задает количество процессов в каждом
измерении решетки,
periods – массив длины ndims, определяет, является ли решетка
периодической вдоль каждого измерения,
reorder – параметр допустимости изменения нумерации процессов,
cartcomm – создаваемый коммуникатор с декартовой топологией процессов.
Операция создания топологии является коллективной и, тем самым, должна выполняться всеми процессами исходного коммуникатора.
Для пояснения назначения параметров функции MPI_Cart_create рассмотрим пример создания двухмерной решетки 4×4, в которой строки и столбцы имеют кольцевую структуру (за последним процессом следует первый процесс):
Следует отметить, что в силу кольцевой структуры измерений сформированная в рамках примера топология является тором.
Для определения декартовых координат процесса по его рангу можно воспользоваться функцией:
где:
comm – коммуникатор с топологией решетки,
rank – ранг процесса, для которого определяются декартовы координаты,
ndims – размерность решетки,
coords – возвращаемые функцией декартовы координаты процесса.
Обратное действие – определение ранга процесса по его декартовым координатам – обеспечивается при помощи функции:
где
comm – коммуникатор с топологией решетки,
coords – декартовы координаты процесса,
rank – возвращаемый функцией ранг процесса.
Полезная во многих приложениях процедура разбиения решетки на подрешетки меньшей размерности обеспечивается при помощи функции:
где:
comm – исходный коммуникатор с топологией решетки,
subdims – массив для указания, какие измерения должны остаться в создаваемой подрешетке,
newcomm – создаваемый коммуникатор с подрешеткой.
Операция создания подрешеток также является коллективной и, тем самым, должна выполняться всеми процессами исходного коммуникатора. В ходе своего выполнения функция MPI_Cart_sub определяет коммуникаторы для каждого сочетания координат фиксированных измерений исходной решетки.
Для пояснения функции MPI_Cart_sub дополним ранее рассмотренный пример создания двухмерной решетки и определим коммуникаторы с декартовой топологией для каждой строки и столбца решетки в отдельности:
В приведенном примере для решетки размером 4х4 создаются 8 коммуникаторов, по одному для каждой строки и столбца решетки. Для каждого процесса определяемые коммуникаторы RowComm и ColComm соответствуют строке и столбцу процессов, к которым данный процесс принадлежит.
Дополнительная функция MPI_Cart_shift обеспечивает поддержку процедуры последовательной передачи данных по одному из измерений решетки (операция сдвига данных – см. раздел 3). В зависимости от периодичности измерения решетки, по которому выполняется сдвиг, различаются два типа данной операции:
Функция MPI_Cart_shift обеспечивает получение рангов процессов, с которыми текущий процесс (процесс, вызвавший функцию MPI_Cart_shift) должен выполнить обмен данными:
где:
comm – коммуникатор с топологией решетки,
dir – номер измерения, по которому выполняется сдвиг,
disp – величина сдвига (<0 – сдвиг к началу измерения),
source – ранг процесса, от которого должны быть получены данные,
dst – ранг процесса которому должны быть отправлены данные.
Следует отметить, что функция MPI_Cart_shift только определяет ранги процессов, между которыми должен быть выполнен обмен данными в ходе операции сдвига. Непосредственная передачами данных, может быть выполнена, например, при помощи функции MPI_Sendrecv.
7.2. Топологии графа
Сведения по функциям MPI для работы с виртуальными топологиями типа граф будут рассмотрены более кратко – дополнительная информация может быть получена, например, Немнюгин и Стесик (2002), Group, et al. (1994), Pacheco (1996).
Для создания коммуникатора с топологией типа граф в MPI предназначена функция
где:
oldcomm – исходный коммуникатор,
nnodes – количество вершин графа,
index – количество исходящих дуг для каждой вершины,
edges – последовательный список дуг графа,
reorder – параметр допустимости изменения нумерации процессов,
cartcomm – создаваемый коммуникатор с топологией типа граф.
Операция создания топологии является коллективной и, тем самым, должна выполняться всеми процессами исходного коммуникатора.
Для примера создадим топологию графа со структурой, представленной на
рис.
5.9. В этом случае количество процессов равно 5, порядки вершин (количества исходящих дуг) принимают значения (4,1,1,1,1), а матрица инцидентности (номера вершин, для которых дуги являются входящими) имеет вид:
Для создания топологии с графом данного вида необходимо выполнить следующий программный код:
// создание топологии типа звезда
int index[] = { 4,1,1,1,1 };
int edges[] = { 1,2,3,4,0,0,0,0 };
MPI_Comm StarComm;
MPI_Graph_create(MPI_COMM_WORLD, 5, index, edges, 1, &StarComm);Приведем еще две полезные функции для работы с топологиями графа. Количество соседних процессов, в которых от проверяемого процесса есть выходящие дуги, может быть получено при помощи функции:
Получение рангов соседних вершин обеспечивается функцией:
где mneighbors есть размер массива neighbors.
Установка и конфигурирование средств отладки в visual studio 2005
Visual Studio 2005 Professional Edition и Visual Studio 2005 Team System позволяют отлаживать приложения, включая и параллельные приложения, в удаленном режиме. При отладке MPI-приложений в рамках Visual Studio используются следующие средства:
- Msvsmon – монитор удаленной отладки
- Smpd – процесс-демон, который запускает приложение Mpishim.exe
- Mpishim – приложение, которое связывается с Msvsmon и запускает процедуру Mpiexeс.
- Mpiexec – процедура запуска приложения пользователя в виде MPI-задания.
Общие шаги по установке и конфигурированию средств отладки MPI приложений в рамках Visual Studio состоят в следующем:
- Установить и сконфигурировать MS MPI на каждом узле кластера. MS MPI включен в пакет Windows Compute Cluster Server 2003, но поддерживаются и другие версии MPI.
- Установить Mpishim.exe на каждом узле кластера в одной и той же директории на каждом из узлов. Например, можно поместить Mpishim.exe в директорию C:Windowssystem32 на каждом узле кластера.
- Установить монитор удаленной отладки (Msvsmon.exe) на каждом узле кластера.
- Установить на компьютере, с которого будет производиться удаленная отладка, достаточные привилегии для запуска заданий на кластере. Этот компьютер должен находиться в таком сегменте сети и в такой подсети, чтобы с него был возможен доступ к вычислительным узлам кластера.
Чтобы установить все требуемые компоненты для удаленной отладки, на каждом вычислительном узле необходимо выполнить следующие действия:
- Вставить в дисковод последний из установочных дисков Visual Studio 2005.
- Отыскать на нем директорию Remote Debuggerx64.
- Запустить из нее файл rdbgsetup.exe для установки компонент для удаленной отладки.
Дополнительные замечания:
- При большом количестве узлов на вычислительном кластере, рекомендуется скопировать содержимое папки Remote Debuggerx64 на диск, доступный всем узлам, и запускать процедуру установки оттуда.
- Пользователь, задействованный в сессии отладки MPI-приложений в Visual Studio 2005, должен также быть пользователем, запустившим Msvsmon.exe на удаленных машинах, поскольку Visual Studio проверяет, чтобы пользователь, выполняющий отладку, и пользователь, запустивший процессы на удаленных компьютерах, совпадали.