u_course

ту их надлежит организовать так, чтобы ни одному не пришлось действовать «по обстановке»: и личные действия каждого, и взаимодействия должны быть строго расписаны по шагам. Также представим себе, что каждый из них ничем не отличается от другого в части способностей к работе любого рода, и будем называть их «первый», «второй» и «третий». Каким образом можно поставить им такую задачу?

Оценив общий объем работ, разделим его на некоторые крупные этапы (декомпозиция на основе логики действий), например: копание ямы, обустройство ямы, уборка мусора. Каждый этап разделим на три равных и по возможности непересекающихся части, так, чтобы можно было работать втроем одновременно (декомпозиция на основе логики данных, исключение или минимизация межзадачных связей). После этого можно составить три различных руководства, подписав на них «первому», «второму», «третьему», и присесть в тени – любоваться слаженным трудом нашего коллектива.

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

1.Наличный объем работ разбивается на такое (неизвестное заранее) количество частей, сколько рабочих выделено для его исполнения.

2.В одном руководстве приведены как указания, относящиеся ко всем исполнителям одновременно, так и касающиеся только первого, второго и т.п. При выборе своих частей каждый исполнитель руководствуется своим номером, который он узнаёт перед началом работы, а также общим количеством исполнителей, которое также становится известно всем перед стартом. Проще говоря, рабочие в самом начале «рассчитываются по порядку».

3.Рабочие обмениваются между собой информацией и материалами с помощью некоторых приемов и средств установленного образца. Назовем эти процедуры «обменом сообщениями».

Эти принципы и представляют собой архитектурную основу стандарта MPI. На скольких бы компьютерах не запускалась программа – пишется одна программа, в которой реализуются ветвления вида «если я – номер второй, то выполнить этот блок, иначе пропустить», «если я – номер первый, то подметать, иначе вместе со всеми собирать мусор» и так далее. Избыточность этого подхода окупается его масштабируемостью и гибкостью, а неэффективность в большинстве случаев оказывается кажущейся.

Дотошность и последовательность, проявленная разработчиками стандарта, способна отпугнуть начинающего от его изучения: настолько велико количество типов сообщений и вариантов их комбинирования, а также других возможностей. Конечно, никто не принуждает разработчика пользоваться

ненужными ему возможностями, и ничто не помешает составить такую параллельную программу с использованием MPI, которая будет работать только на конкретном количестве узлов, или же на некотором их множестве (например, на четном количестве узлов, или на количестве узлов, равном квадрату любого натурального числа).

Особо следует подчеркнуть принципиальную неразличимость и взаимозаменяемость исполнителей. Никогда не известно перед началом работы программы, на каких именно компьютерах кластера она будет исполняться, каким номером будет считать себя каждый из них. Стандарт гарантирует только наличие заказанного количества исполнителей. Такое ограничение напрямую связано с тем, что любой суперкомпьютер является устройством коллективного пользования, то есть на нем работают и запускают свои задачи множество различных людей. Естественно, что постоянный конфликт, в котором находятся их интересы, подлежит регулированию. Это делается с помощью некоторой системы запуска параллельных задач. Стандарт MPI почти не касается этого аспекта, предоставляя алгоритм и способ работы такой системы на откуп разработчикам конкретных реализаций, и специфицируя только синтаксис некоторых команд общего характера. Однако именно принцип неразличимости исполнителей, заложенный в стандарте, делает возможной более или менее эффективную работу этих систем.

MPI и крупноблочное распараллеливание

Разумеется, стандарт возник не на пустом месте. Помимо прочих оснований его фундаментом является архитектура массивно-параллельных ЭВМ (MPP), для работы на которых, он в целом и предназначен. Напомним, что MPP-система представляет собой множество вычислительных узлов, каждый из которых имеет свою локальную память, однако, узлы не имеют прямого доступа к локальной памяти друг друга. Связь между ними осуществляется с помощью некоторой коммуникационной сети. Простейший вариант MPPсистемы – компьютерный класс: N обычных компьютеров, соединенных локальной сетью. Обмен между узлами может быть организован множеством способов, однако наиболее общим является передача сообщений, которая бывает либо типа «точка-точка» (то есть один узел – другому), либо «коллективного» типа (с участием более чем двух узлов).

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

В предыдущем разделе мы интуитивно раздали нашим рабочим крупные и по возможности непересекающиеся части общего дела: было бы очевидной практической нелепостью предлагать им копать яму, держась втроем за одну лопату. Но для этого нам пришлось разделить области приложения их усилий. Аналог такого подхода в вычислениях и называется блочным рас-

параллеливанием: каждый вычислительный узел получает в свое распоряжение некоторую часть данных задачи и оперирует с ними, при необходимости обмениваясь с остальными недостающими данными. Очевидно, что чем больше эти объемы и чем реже происходят обмены, тем эффективнее процесс распараллеливания. Поэтому-то, как правило, и говорят о крупноблочном распараллеливании. Его противоположность – мелкозернистое распараллеливание – как правило, реализуется на архитектурах, отличных от MPP, иными, нежели MPI, средствами.

Итак, к чему же мы пришли? К алгоритму распараллеливания некоторого (весьма обширного) класса вычислительных задач, который характеризуется а) необходимостью обработки больших объемов данных и б) возможностью обрабатывать различные данные одновременно (хотя бы частично). Алгоритм повторяет общий подход ДСС (декомпозиция – связь – стнхронизация), описанный в главе 1 и неоднократно применяемый нами при проектировании параллельных приложений для архитектур с общей памятью. Алгоритм прост: разрежем область данных на блоки, раздадим на вычислительные узлы, организуем обработку данных (счет), по необходимости организуем обмены и соберем результаты счета.

Рассмотрим некоторые подробности каждого из этих этапов.

Разбиение на подобласти

Итак, пусть мы имеем N вычислительных узлов и некоторое количество данных. Предположим для определенности, что данные представляют собой значения в узлах сетки, а область будет двумерной и однородной.

Такое множество данных можно разделить на блоки многими способами. Рассмотрим только разбиения на связные (не содержащие разрывов внутри) или даже просто выпуклые блоки равного размера (в данном случае

– содержащие равное количество точек сетки).

Наиболее легкий путь – это просто разрезать область на полосы (ленты) и раздать их по узлам. Его преимущество – простота, приводящая к следующим обстоятельствам:

у каждого узла всего два соседа, чьи номера легко вычисляются;

в зависимости от языка (Си или Фортран) можно разрезать область по строкам либо столбцам, в соответствии со способом хранения в памяти массивов, что впоследствии облегчит обмены;

добиться приблизительного равенства количеств данных на узлах несложно, даже если соответствующая характеристика области (длина или ширина) не делится нацело на количество вычислительных узлов.

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

При чём же тут периметр? Дело в том, что в большинстве практических сеточных (и не только) задач необходимость в обменах с соседями возникает

именно на границах областей, и именно от периметра зависит общий объем данных, которые придется принять и передать данному узлу.

Простейший способ привести периметр к практическому минимуму – это использовать не ленточное, а квадратное разбиение: при равной площади периметр квадрата меньше периметра прямоугольника. Кроме того, квадратное разбиение выгоднее с точки зрения борьбы с известным эффектом деградации эффективности (уменьшением параллельной эффективности с ростом количества узлов при сохранении размера задачи): для ленты время совершения обменов не зависит от количества узлов, а для квадрата – уменьшается

пропорционально 1 p . Однако и сложность конструирования такого раз-

биения растет.

Почему же не пойти дальше, к минимуму отношения площади и периода – кругу? Конечно, кругами нельзя покрыть плоскость, но это можно сделать пятиугольниками. Однако мы недаром подчеркнули выше практичность минимума квадратного разбиения. Пятиугольник непрактичен по многим причинам; некоторые из них мы укажем в дальнейшем, здесь же напомним лишь о том, что наша сетка – дискретна и прямоугольна. Пока границы областей совпадают с линиями сетки, мы встречаем ожидаемое согласие между аналитическими оценками тех же периметров и площадей и поточечной реальностью. Как только границы областей начинают идти под углом, начинаются расхождения, которые могут не только свести на нет предполагавшиеся выгоды, но и сильно увеличить время отладки программы.

Усложним теперь наши условия: пусть сетка станет неоднородной, имеющей сгущения и разрежения. В таких условиях все будет зависеть от рисунка изолиний густоты сетки. Например, в некоторых задачах, моделирующих слоистые среды, бывает естественным изменять густоту сетки согласно расположению соответствующих слоев. В других задачах сетка может сгущаться к границам области или же к середине. Во всех случаях при разбиении на блоки необходимо добиваться соблюдения следующих условий:

равенства площадей (объемов – в трехмерном случае) в смысле количества точек сетки для обеспечения равномерной вычислительной нагрузки на узлы;

уменьшения количества соседей для каждого узла;

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

Может оказаться, что некоторые из этих пунктов противоречат друг другу. В результате поиск баланса, оптимального с точки зрения главного критерия – времени счета – составляет плохо формализуемую, творческую часть процесса распараллеливания.

Распределение данных по узлам

Итак, мы определили, как именно должна быть разрезана область на p подобластей. Теперь необходимо проинициализировать области на узлах на-

чальными значениями (или, что хуже, результатами предыдущей счетной итерации), а по окончании счета – выгрузить с узлов посчитанные значения.

Кластерные системы обычно предоставляют доступ к домашнему каталогу пользователя со всех вычислительных узлов; местонахождение этого каталога зависит от «бюджетности» кластера и может варьироваться от обычного жесткого диска или файлового массива до специализированного файлового хранилища. И, если размеры данных действительно невелики, то каждому вычислительному узлу будет совсем не трудно открыть нужный файл и прочесть либо записать его. Однако по мере роста количества данных, подлежащих чтению или записи, ситуация ухудшается стремительно и может стать катастрофической, особенно если попутно растет количество узлов, желающих сделать это одновременно, так как производительности дисковых интерфейсов и коммуникационных сред, которыми эти интерфейсы соединены с узлами, скорее всего, являются величинами одного порядка. Прибавив к этому тот факт, что на кластере работает не только наша программа, и не только она может занимать файловый сервер и канал к нему, легко попасть в ситуацию, когда сохранение результатов счета на диск окажется занятием намного более долгим, чем сам счет.

Есть вещи, которые не стоит делать в любом случае. Первое, чего следует избегать – чтения или записи одного файла многими процессами одновременно. Файловая и сетевая подсистемы, скорее всего, справятся с этой задачей, но производительность существенно пострадает. Ненамного лучше – чтение/запись в большое количество файлов одновременно. Помимо потери производительности в узких местах при передаче данных, в такой ситуации возникнет необходимость в постобработке созданных файлов, например, в нетривиальной их склейке. Это может оказаться неожиданно затруднительной задачей, если, к примеру, результирующий файл попросту не помещается в памяти на одном узле, или если он вместе с исходными файлами, удвоив собой их объем, превысит дисковую квоту. Все это говорит о том, что работа с загрузкой и выгрузкой данных должна быть тщательно и аккуратно продумана еще на этапе проектирования архитектуры.

Какими средствами можно воспользоваться? Во-первых, стандарт MPI- 2, расширение стандарта MPI, предоставляет в распоряжение пользователя средства работы с файлами. Использовать их или нет, следует решать, сообразуясь с архитектурой кластера и самой задачи.

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

В-третьих, известное и популярное решение – это выделение отдельного узла-диспетчера, занятого исключительно обслуживанием ввода-вывода и

прочими вещами, не имеющими прямого отношения к параллельному счету. Например, управляющему процессу может поручить следующие действия.

1.Загрузка данных из хранилища (линейным чтением большими блоками, с максимальной скоростью) и раздача их по вычислительным узлам (используя высокоскоростную сеть передачи данных).

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

3.Сбор (по сети передачи данных) результатов счета, организация временного хранения собранных данных, преобразование промежуточных данных (непараллельный постпроцессинг, визуализация, сжатие и т.п.).

4.Выгрузка промежуточных и финальных результатов на диск.

Преимущества использования отдельного узла для решения задач 3 и 4 состоят в том, что эти задачи могут решаться независимо от вычислительного процесса, в течение счетной итерации. Лишь бы узел-диспетчер успевал за счетом. Если не успевает один – можно использовать два или более. Основной же недостаток, в общем-то, один: при всей полезности такого узладиспетчера, он не занят вычислительной работой и при честном подсчете эффективности портит цифры.

Впрочем, подсчет эффективности работы программы – это отдельный и весьма тонкий вопрос. Эффективность – это отношение ускорения к количеству узлов, на котором оно достигнуто. Однако возникает вопрос, в сравнении с чем, вычислять ускорение? «Честный» подсчет предполагает, сравнение с наилучшей последовательной программой, решающей ту же задачу, что и наша, на одном узле данного кластера. Вместо этого в большинстве случаев сопоставляются наша параллельная программа с нашей же программой, запущенной на одном узле – если она, конечно, допускает такой режим запуска. Наряду с этой уловкой, часто не учитывают время на загрузку-выгрузку данных, или наличие несчитающих узлов. Впрочем, мы не полагаем эти уловки существенным криминалом: оценки эффективности обычно малоинтересны как таковые. Интересна бывает – для оценки перспективности программы либо подхода, реализованного в ней – динамика эффективности с ростом количества задействованных узлов или с ростом размера данных задачи, а эта асимптотика проявляет себя одинаково вне зависимости от учета тех или иных констант.

Организация вычислений

Итак, мы подошли к самому главному: к организации обменов данными в процессе вычислений. Рассмотрим основные этапы, из которых состоит процесс обмена, и средства MPI, которые позволяют реализовать их.

Основные вопросы, на которые нужно найти ответ, таковы: на передающей стороне – куда, что и как передать; на принимающей стороне – от кого, что и как принять.

1. «Куда и от кого». На понятийном уровне отвечать на эти вопросы легко: соседу слева, соседу справа, всем счетным узлам… Однако на практике для этого нужно знать номера этих соседей в некоторой группе MPIпроцессов. Номера, которые присваиваются процессам в группе, создаваемой по умолчанию, могут мало соответствовать реальной топологии, например, квадратному разбиению с узлом-диспетчером. Какие средства предлагает MPI для облегчения задачи адресации пересылок?

Создание отдельных групп процессов. Полезность этой возможности на практике зачастую недооценивается. Между тем, освоив её, мы сможем применять богатый арсенал групповых операций к ограниченному числу процессов, сильно упрощая и оптимизируя наш код. Упрощая – потому что вместо циклов и последовательностей приемов-передач можно будет написать один вызов. Оптимизируя – потому что групповые обмены наверняка реализованы внутри MPI-системы лучше, чем это удалось бы нам самостоятельно. Некоторые сложности, однако, возникают с пониманием того, как это можно делать. Семантика вызовов соответствующих функций MPI действительно немного запутана, поэтому, не вдаваясь в подробности и минуя терминологические дебри, приведем несколько практических примеров. Некоторые используемые в примерах функции и понятия более подробно описаны ниже, описание более специальных функций выходит за рамки нашего подробного обсуждения и их следует искать в стандарте MPI и, например, в монографиях [2,4].

Прежде всего, не следует забывать, что создание группы и связанного с ней интракоммуникатора (далее будем говорить просто «коммуникатора») является коллективной операцией, и она должна быть вызвана всеми членами текущей группы. Например, используем MPI_Comm_split() для создания группы с семантикой «все счетные узлы». Пусть мы решили выделить узел с номером 0 (это – номер процесса в группе по умолчанию, и хранится он, например, в переменной id) под задачи диспетчеризации, а все остальные узлы предназначили для счета. Тогда нужно на каждом узле (и на диспетчере, и на остальных) сказать примерно следующее:

MPI_Comm C_Group; // Эти описания должны быть глобальными! int c_size, c_num;

MPI_Comm_split(MPI_COMM_WORLD, id==0 ? 0 : 1, 0, &C_Group ); \\ (1)

Строка (1) указывает системе, что происходит разбиение группы MPI_COMM_WORLD на несколько новых. Каким образом? Первый параметр определяет, в какую новую группу желает попасть данный процесс. Будет

создано столько групп, сколько разных значений этого параметра окажется. В нашем случае это, как нетрудно видеть, значения 0 для нулевого процесса и 1 для всех остальных. Второй же параметр указывает желаемый номер процесса в новой группе. Мы не захотели заказать их явно (все процессы передали одинаковый номер – ноль), так что система сама раздаст нашим процессам новые номера, основываясь на старой нумерации: в нашем случае номером каждого процесса в C_Group должно стать значение (id-1).

Итак, создано две группы процессов, и на каждом процессе стал доступен коммуникатор C_Group. Упоминание его вместо MPI_COMM_WORLD в любом последующем MPI-вызове приведет к тому, что вызов будет касаться только тех процессов, которые входят в ту же группу, что и он сам. Так, про- цесс-диспетчер, используя C_Group, не сможет увидеть никого, кроме себя, а счетные узлы в рамках C_Group смогут обмениваться между собой, не включая в обмен диспетчера. Строки (2) и (3) сообщают процессам их номера в новой группе и размер этой группы. По окончании работы с группой не забудем вызвать MPI_Comm_free(C_Group) для освобождения коммуникатора.

Далее пусть наша область разбита на l1 блоков по вертикали и l2 блока по горизонтали, l1 × l2 = p, где p – это количество счетных узлов. Тогда найти соседей нетрудно:

int left, right, upper, bottom;

if (c_num%l2==0) left=MPI_PROC_NULL; else left=c_num;

if (c_num%l2==l2-1) right=MPI_PROC_NULL; else right=c_num+1; if (c_num/l2==0) upper=MPI_PROC_NULL; else upper=c_num-l2;

if (c_num/l2==l1-1) bottom=MPI_PROC_NULL; else bottom=c_num+l2;

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

В этом примере мы использовали фиктивный номер процесса MPI_PROC_NULL для тех случаев, когда соответствующий процесс-сосед отсутствует. Его семантика – отсутствующий узел. Фиктивный номер можно использовать при вызовах функций приема/передачи так же, как и обычный номер процесса: отличие только в том, что с данными при этом ничего не произойдет.

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

Решение с помощью виртуальных топологий состоит в следующем. Создать из группы C_Group новую группу с ассоциированной с ней декартовой топологией. Один раз или каждый раз перед обменом данными определять в новой группе абсолютные номера процессов-соседей с помощью вы-

зова MPI_Cart_shift().

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

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

MPI_Type_contiguous (k2+2, mpi_real, &lineh); MPI_Type_commit (&lineh);

MPI_Type_hvector (k1+2, 1, pt1-pt0, lineh, &AllData); MPI_Type_commit (&AllData);

Эти вызовы делаются на всех узлах – и на счетных, и на диспетчере. Разница только лишь в том, что на диспетчере массив data имеет размер не

[k1+2][k2+2], а [N+2][N+2], где N – это общая размерность задачи, N = k1*l1 = k2*l2.

По окончании работы с программой будет правильно освободить все созданные типы от необходимости существовать далее. Это делается с по-

мощью вызова вида MPI_Type_free(&line).

3. «Как». Передача сообщения – это, в общем-то, основной предмет рассмотрения стандарта. Есть две большие группы функций приемапередачи: функции типа «точка-точка», вовлекающие в процесс только два различных узла (назовем их парными), и групповые функции, вовлекающие в обмен всю группу.

Парные функции, в свою очередь, можно разделить по двум характеристикам: режим работы и наличие блокировки. Неблокирующей функцией приема-передачи называют такую, которая всегда сначала возвращает управление в программу, а потом начинает заниматься передачей данных. Возврат из такой функции говорит лишь о том, что наша заявка на прием или передачу учтена системой и когда-нибудь будет исполнена, а мы в это время вольны заняться чем-либо еще. Для получения действительного статуса процесса передачи есть ряд функций MPI_Wait*() и MPI_Test*(). Таким образом, корректное программирование неблокирующей передачи обычно предполагает два действия: инициализацию передачи (приема) и проверку факта ее завершения. Для указания на неблокирующий характер функции к ней приписывают префикс «I», например, MPI_Isend() – неблокирующий вариант функции

MPI_Send().

Неблокирующая функция приема (MPI_IRecv()) сообщает системе, что можно начать (или ожидать) прием в фоновом режиме. Завершен ли этот прием необходимо проверить дополнительно.

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

Режимов существует четыре. Синхронная передача (MPI_Ssend()): возврат из функции передачи означает, что данные уже начали передаваться получателю – непосредственно из того участка в памяти, где они лежат. Если это блокирующий вызов, то по возвращении из него известно, что буфер передачи уже можно использовать. Буферизованная передача (MPI_Bsend()): возврат из функции передачи происходит, когда передаваемое сообщение взято в системный или пользовательский буфер, буфер передачи также готов к по-