CC BY
81
Computational nanotechnology
4-2015
ISSN 2313-223X
1.2. СРАВНЕНИЕ ТЕХНОЛОГИЙ ПАРАЛЛЕЛЬНОГО ПРОГРАММИРОВАНИЯ MPI И CHARM++ НА ПРИМЕРЕ ЗАДАЧИ ПОСТРОЕНИЯ МИНИМАЛЬНОГО ОСТОВНОГО ДЕРЕВА В ГРАФЕ
Мазеев Артем Валерьевич, инженер-программист, АО «НИЦЭВТ». E-mail: a.mazeev@nicevt.ru
Семенов Александр Сегреевич, канд. техн. наук, начальник сектора, АО «НИЦЭВТ». E-mail: semenov@nicevt.ru
Фролов Александр Сегреевич, начальник отдела, АО «НИЦЭВТ». E-mail: frolov@nicevt.ru
Аннотация: В работе представлено исследование, как алгоритм GHS поиска минимального остовного дерева в графе может быть реализован при помощи модели передачи сообщений (библиотека MPI), модели с управлением потоком сообщений (язык Charm++), а также при реализации модели vertex-centric на языке Charm++. Оптимизированные реализации алгоритма GHS с использованием MPI и Charm++ демонстрируют приблизительно одинаковую производительность на 32-узловом вычислительном кластере, производительность реализации с подходом vertex-centric - на 1-2 порядка хуже.
Ключевые слова: графы, суперкомпьютеры, MPI, Charm++, MST, GHS
A COMPARISON OF MPI AND CHARM++ PARALLEL PROGRAMMING TECHNOLOGIES ON THE MINIMUM SPANNING TREE PROBLEM
Mazeev Artem Valerievich, software-engieer, JSCSRCECT. E-mail: a.mazeev@nicevt.ru
Semenov Alexander Sergeevich, Ph.D., head of sector, JSC SRCECT. E-mail: semenov@nicevt.ru
Frolov Alexander Sergeevich, head of department, JSC SRCECT. E-mail: frolov@nicevt.ru
Abstract: The paper presents implementations of the GHS minimum spanning tree algorithm developed using message passing model (MPI library), message-driven model (Charm++ language), and vertex-centric model in Charm++. The optimized GHS implementations using MPI and Charm++ have approximately the same performance on 32-node cluster, the performance degradation of the implementation in Charm++ vertex-centric model is of 1-2 orders of magnitude.
Index terms: graphs, supercomputers, MPI, Charm++, MST, GHS
1. Введение
Одна из ключевых проблем при создании суперкомпьютерных комплексов экзафлоп-сной производительности - разработка программных моделей и инструментальных средств программирования, позволяющих эффективно решать прикладные задачи в масштабах систем, состоящих из десятков тысяч вычислительных узлов, обладающих гибридной архитектурой, которая объединяет разнородные вычислители (процессоры, ускорители на СБИС и ПЛИС), многоуровневой иерархической памятью и высокоскоростной коммуникационной сетью.
Традиционная программная модель двусторонней передачи сообщений (стандарт библиотеки MPI 1) уже долгое время подвергается критике из-за низкой продуктивности про-
граммирования. Для задач обработки больших графов, которые характеризуются интенсивным нерегулярным доступом к памяти всего суперкомпьютера, применение MPI особенно неудобно. Поэтому для таких задач на суперкомпьютерных комплексах экзафлоп-сной производительности необходимо создание новых альтернативных моделей вычислений, отражающих как специфику графовых задач, так и архитектурные особенности экза-флопсных систем.
В данной работе рассматривается вопрос применения языка параллельного программирования Charm++ с управлением асинхронным потоком сообщений для решения задач обработки графов. В статье будет приведено сравнение технологий параллельного программирования MPI и Charm++ на примере
18
СРАВНЕНИЕ ТЕХНОЛОГИЙ ПАРАЛЛЕЛЬНОГО ПРОГРАММИРОВАНИЯ MPIИ CHARM++
НА ПРИМЕРЕ ЗАДАЧИ ПОСТРОЕНИЯ МИНИМАЛЬНОГО ОСТОВНОГО ДЕРЕВА В ГРАФЕ
Мазеев А. В., Семенов А. С., Фролов А. С.
задачи построения минимального остовного дерева в графе, а также первые результаты применения библиотеки uChareLib, которая является расширением языка Charm++ и помогает удобнее решать графовые задачи.
2. Модели программирования MPI и Charm++
В модели передачи сообщений, которую реализует библиотека MPI (Message Passing Interface) [1], параллельная программа представляет собой множество процессов, каждый из которых имеет собственное локальное адресное пространство. Взаимодействие процессов - обмен данными и синхронизация - осуществляется посредством передачи сообщений. Обобщение и стандартизация различных библиотек передачи сообщений привели в 1994 году к появлению стандарта MPI (Message Passing Interface).
Одним из основных недостатков MPI является низкий уровень программирования, который выражается в необходимости детального управления распределением массивов, организацией вычислений и обменом между процессами. Это приводит к высокой трудоемкости разработки программ.
Язык параллельного программирования Charm++ является расширением языка C++ и основан на объектно-ориентированной модели с управлением асинхронным потоком сообщений [2].
Программа на Charm++ выполняется в модели вычислений, управляемых сообщениями (message driven). Программа организована в виде набора объектов (или chare-объектов), которые общаются между собой путем асинхронной передачи сообщений. Вычисление в объекте инициируется приходом сообщения и после этого не прерывается, пока объект сам не закончит вычисление. Обработчики сообщений оформлены как подпрограммы («методы») объектно-ориентированной программы.
Кроме того, в Charm++ поддерживается автоматическая динамическая балансировка нагрузки на вычислительные узлы, что реализуется на уровне runtime-системы за счет пе-
ремещения chare-объектов между вычислительными узлами. Для прикладного программиста данная возможность совершенна прозрачна, так как программная модель Charm++ не специфицирует расположение chare-объектов в вычислительной системе, и все объекты адресуются в едином адресном пространстве.
Программная модель языка параллельного программирования Charm++ естественным образом подходит для создания параллельных графовых приложений [3], так как многие из графовых алгоритмов могут быть выражены в модели vertex-centric [4] (VC-модель) и достаточно просто реализованы на Charm++. Так, каждая вершина графа может быть представлена в виде chare-объекта, состояние вершины описывается данными, привязанными к chare-объекту, а программа состоит из множества параллельных процессов, порождающих активные сообщения (в модели Charm++ активные сообщения реализованы в виде вызовов entry-методов).
Для того чтобы оптимизировать хранение очень большого количества chare-объектов и обеспечить наиболее эффективное планирование выполнения методов, возникла идея классификации chare-объектов по гранулярности параллелизма. В разработанном расширении Charm++ в язык интерфейса вводится ключевое слово uchare (микро-chare), а разработанная библиотека uChareLib поддерживает работу таких микро-объектов.
В uChareLib поддерживается автоматическая агрегация сообщений, реализовано два способа - собственная реализация и использование немного модифицированной библиотеки TRAM [5]. В данной работе представлены результаты, полученные для версии с TRAM.
3. Алгоритм GHS построения минимального остовного дерева в графе
Рассматривается задача Minimum Spanning Tree (MST) построения минимального остовного дерева в неориентированном графе с весами, значения которых являются действительными неотрицательными числами.
19
Computational nanotechnology
4-2015
ISSN 2313-223X
Существует большое количество алгоритмов, решающих задачу MST. Наиболее известными являются алгоритмы Прима [6] и Крускала [7], однако эти алгоритмы по своей сути являются последовательными. Среди параллельных алгоритмов наиболее известен алгоритм Борув-ки [8], однако для параллельной реализации на распределенной памяти разработаны специальные алгоритмы, например, GHS [9] и Авербуха [10]. Алгоритм Авербуха является оптимизацией и надстройкой над алгоритмом GHS, на первой фазе алгоритма Авербуха работает алгоритм GHS, поэтому GHS был выбран для исследования как базовый и более простой. Временная сложность алгоритма GHS составляет O(Nlog2N), необходимое количество коммуникационных сообщений -5Nlog2N+2E, где N и E - количество вершин и ребер в графе.
Алгоритм GHS (по именам авторов Gallager, Humblet, Spira) [9] очень хорошо описывается в модели vertex-centric. Кратко идея алгоритма состоит в следующем. Все вершины графа выполняют одну и ту же процедуру, которая заключается в отправке, приеме и обработке сообщений от смежных вершин. По каждому ребру графа сообщения передаются независимо в обоих направлениях, не обгоняя друг друга в рамках одного направления по ребру.
В каждый момент времени множество вершин графа представляется в виде объединения некоторого количества фрагментов, то есть непересекающихся множеств вершин. Изначально каждая вершина является фрагментом. Каждый фрагмент находит среди ребер, исходящих из него в другие фрагменты, ребро с минимальным весом (минимальное исходящее ребро). Далее, по этим ребрам фрагменты объединяются.
Рёбра, по которым происходят объединения фрагментов, будут составлять минимальное остовное дерево, когда для связного графа останется ровно один фрагмент, включающий в себя все вершины.
Рассмотрим работу алгоритма подробнее.
Существует три возможных состояния вершины: Sleeping - начальное состояние, Find -когда вершина участвует в поиске минималь-
ного исходящего из фрагмента ребра, и Found - в остальных случаях.
У каждого фрагмента есть переменная L, характеризующая его уровень. Изначально уровень каждого фрагмента равен 0. Два фрагмента с одинаковым уровнем L могут объединиться во фрагмент с уровнем L+1. Фрагмент не может присоединиться к фрагменту с меньшим уровнем.
Опишем подробнее, как происходит поиск минимального исходящего ребра во фрагменте. В тривиальном случае, когда фрагмент состоит из одной вершины, и его уровень равен 0, вершина локально находит минимальное исходящее ребро, помечает его как часть минимального остовного дерева и отправляет сообщение Connect по этому ребру и переходит в состояние Found.
Теперь рассмотрим случай, когда уровень фрагмента больше 0. Предположим, что два фрагмента уровня L-1 объединились во фрагмент уровня L по одному исходящему ребру. Ребро, по которому объединились два фрагмента, становится ядром нового фрагмента. Вес ядра используется в качестве идентификатора фрагмента.
Далее сообщение Initiate рассылается по всему фрагменту, начиная от вершин, смежных с ядром. Сообщение Initiate рассылается по фрагменту для того, чтобы все вершины получили новый уровень и идентификатор фрагмента, а также установили свое состояние в Find. Когда вершина получает сообщение Initiate, она начинает участвовать в поиске минимального исходящего ребра.
Каждое ребро графа может быть в одном из трех состояний: Branch - ребро принадлежит минимальному остовному дереву, Rejected -не принадлежит, Basic - в случае, если пока не известно, будет это ребро принадлежать минимальному остовному дереву или нет. Чтобы найти минимальное исходящее ребро, в некоторой вершине v поочередно перебираются, начиная с самого легкого, ребра, находящиеся в состоянии Basic. Для каждого такого ребра происходит проверка при помощи посылки по нему сообщений типа Test.
20
СРАВНЕНИЕ ТЕХНОЛОГИЙ ПАРАЛЛЕЛЬНОГО ПРОГРАММИРОВАНИЯ MPIИ CHARM++
НА ПРИМЕРЕ ЗАДАЧИ ПОСТРОЕНИЯ МИНИМАЛЬНОГО ОСТОВНОГО ДЕРЕВА В ГРАФЕ
Мазеев А. В., Семенов А. С., Фролов А. С.
Сообщение Test передает уровень и идентификатор фрагмента. Когда вершина и принимает сообщение Test, она сравнивает свой идентификатор фрагмента с принятым в сообщении. Если идентификаторы равны, тогда вершина и отправляет в ответ сообщение Reject, и после этого обе вершины устанавливают состояние ребра в Reject. В этом случае вершина v, которая отправила сообщение Test, продолжает поиск, анализируя следующее наилучшее ребро и так далее. Если идентификатор фрагмента в полученном сообщении Test отличен от идентификатора фрагмента принимающей вершины и, и если уровень фрагмента у принимающей вершины больше либо равен, чем в сообщении Test, тогда в ответ отправляется сообщение Accept. Состояние ребра у вершины v в этом случае меняется на Branch. Однако если уровень фрагмента вершины и меньше, чем в пришедшем сообщении, тогда сообщение откладывается, пока уровень фрагмента принимающей вершины и не поднимется до нужного значения.
Рис. 1. Схема работы алгоритма GHS, отправка сообщений Report.
Ребра, которые представлены сплошными линиями, находятся в состоянии Branch.
В конечном итоге, каждая вершина находит минимальное исходящее ребро, если такое имеется. Теперь вершины посылают сообщения Report (см. рис. 1), чтобы найти минимальное исходящее ребро всего фрагмента. Если ни одна из вершин графа не имеет исходящих ребер в состоянии Basic, то алгоритм
завершается, а ребра в состоянии Branch являются минимальным остовным деревом.
Отправка Report происходит по следующим правилам. Каждая листовая вершина фрагмента отправляет сообщение Report(w) по единственному инцидентному ребру в состоянии Branch (w - вес минимального исходящего ребра из вершины или бесконечность, если исходящих ребер нет). Каждая внутренняя вершина находит свое собственное минимальное исходящее ребро и ждет прибытия всех сообщений от всех поддеревьев. Затем вершина выбирает минимальный вес из всех значений весов. Если минимум достигается на значении, которое пришло из поддеревьев, то в переменную вершины best_edge записывается номер исходящей ветви (поддерева), иначе записывается номер минимального исходящего ребра. Это делается для того, чтобы в дальнейшем можно было легко восстановить путь, двигаясь туда, куда указывает best_edge. Далее происходит отправка Report вверх по дереву фрагмента с аргументом, равным уже найденному минимальному значению среди всех значений весов. Когда вершина отправляет сообщение Report, она также переходит в состояние Found. В конечном итоге, две вершины, инцидентные ядру, отправляют сообщения Report вдоль ядра и определяют вес минимального исходящего ребра, и с какой стороны от ядра оно находится.
Чтобы попытаться присоединить фрагмент к другому по найденному минимальному исходящему ребру фрагмента, можно воспользоваться переменной best_edge в каждой вершине, чтобы проследить путь от ядра до минимального исходящего ребра. Для этого от одной из ядровых вершин, которая ближе к минимальному исходящему ребру, посылается сообщение Change core (см. рис. 2). Вершина, получившая это сообщение, посылает его дальше в соответствии со своим значением best_edge, и так далее. Когда сообщение достигает вершины с минимальным исходящим ребром, корнем дерева, которое образует фрагмент, становится эта
21
Computational nanotechnology
4-2015
ISSN 2313-223X
вершина. Эта вершина посылает сообщение Connect(L) по минимальному исходящему ребру, где L - это уровень фрагмента. Если два фрагмента уровня L имеют одно и то же минимальное исходящее ребро, то каждый из них отправляет сообщение Connect(L) вдоль этого ребра, и это ребро становится ядром нового фрагмента уровня L+1, которое сразу начнет рассылать по всему фрагменту сообщение Initiate, с новым номером уровня и идентификатором.
Когда сообщение Connect отправляет фрагмент с уровнем L и идентификатором F, во фрагмент с уровнем L' > L и идентификатором F'. Больший фрагмент отправит сообщение Initiate с L' и F' в меньший фрагмент.
В данном описании разобраны не все возникающие случаи, а лишь основные. Подробнее можно прочитать в статье [9].
Рис. 2. Схема работы алгоритма GHS, отправка сообщения Change core в сторону с минимальным исходящим ребром фрагмента.
4. Реализации алгоритма GHS
4.1 Реализация с использованием библиотеки MPI
При реализации на суперкомпьютере количество вершин в графе значительно больше, чем вычислительных узлов, поэтому в памяти каждого вычислительного узла обычно хранится много вершин и вся относящаяся к ним информация. Схема реализации основной части алгоритма GHS с использованием библиотеки MPI приведена на рис. 3. В каждом MPI-процессе поддерживается очередь, в которую
вершины могут откладывать сообщение, если это необходимо. Для ускорения работы в реализации реализована агрегация сообщений. Кроме того, сообщения Test откладываются в отдельную очередь, которая обрабатывается реже, чем основная. Эта оптимизация также улучшает производительность, так как сообщения Test часто откладываются, попытка обработки происходит не один раз, поэтому лучше уменьшить количество лишней работы.
Важно отметить, что алгоритм требует, чтобы исходный граф был связным. В представленной реализации это не обязательно, так как алгоритм будет работать до тех пор, пока в сети не наступит состояние тишины, когда все очереди пусты, все сообщения обработаны, в сети нет сообщений.
while (true) {
/* прием сообщений и запись в очередь, сообщения Test записываются в отдельную очередь */
read_msgs ();
/* обработка основной очереди, отправка сообщений (запись в буфер) */
if (time_to_process_main_queue) { process_queue ();
}
/* обработка очереди с сообщениями Test, отправка сообщений (запись в буфер) */
if (time_to_process_test_queue) { process_test_queue ();
}
if (time_to_send) {
/* отправка всех накопленных сообщений */ send_all_bufs ();
}
check_finish (); /* проверка на завершение при помощи MPI_Allreduce */
}______________________________________________________
Рис. 3. Схема реализации основной части алгоритма GHS с использованием библиотеки MPI.
4.2 Реализация на языке Charm++
Рассмотрим реализацию алгоритма GHS на языке Charm++, основные методы этой реализации put и do_it приведены на рис. 4. Один chare-объект хранит некоторое количество вершин (зависит от количества chare-объектов). Как и у каждого процесса в MPI-версии, у каждого chare-объекта есть очередь, а для увеличения производительности также используется агрегация сообщений, и для сообщений Test заведена отдельная очередь и используются эвристики (time_to_process _ma i n_queue, time_to_process_test_queue, time_to_send) для определения моментов, когда выполнять обработку основной очереди,
22
СРАВНЕНИЕ ТЕХНОЛОГИЙ ПАРАЛЛЕЛЬНОГО ПРОГРАММИРОВАНИЯ MPIИ CHARM++
НА ПРИМЕРЕ ЗАДАЧИ ПОСТРОЕНИЯ МИНИМАЛЬНОГО ОСТОВНОГО ДЕРЕВА В ГРАФЕ
Мазеев А. В., Семенов А. С., Фролов А. С.
очереди Test или принудительно отправлять все сообщения.
Однако есть существенная разница в организации работы двух программ. В реализации на Charm++ если chare-объект узнает, что ему незачем работать (если очереди пусты, или все, что можно было обработать на текущий момент, уже обработано), он «засыпает», и «про-
сыпается» только при появлении новых входящих сообщений при вызове извне метода
put. Программа завершается, когда в сети наступает «тишина» (то есть когда в Charm++ срабатывает Quiescence Detection: все сообщения обработаны, в сети сообщений нет).
Заметим, что такое описание очень близко к идее алгоритма и удобно для программиста.
void put (pack_of_msgs) {
if (sleep_state) {
sleep_state = False; thisChare.do_it ();
}
push_in_queue (pack_of_msgs);
}
void do_it () {
if (time_to_process_main_queue) { process_queue ();
}
if (time_to_process_test_queue) { process_test_queue ();
}
if (time_to_send) {
send_all_bufs ();
}
if (can_still_do_something) { ThisChare.do_it ();
} else {
}
sleep_state = True;
}
Рис. 4. Схема реализации алгоритма GHS на языке Charm++.
4.3 Реализации на языке Charm++ в модели vertex-centric
Организация программы в модели vertexcentric похожа на ту, которая изображена на рис. 4., однако в методе put каждая пришедшая вершина обрабатывается сразу же и только в случае невозможности обработки кладется в очередь. Также отсутствует агрегация сообщений.
В работе рассматриваются две реализации в модели vertex-centric: с использованием стандартного языка Charm++ и с использованием расширения Charm++ - библиотеки uChareLib.
Две эти реализации отличаются только тем, что в случае Charm++ используются chare-объекты, uchare-объекты - в случае uChareLib.
5. Измерение производительности
Исследование производительности разработанных вариантов реализации алгоритма GHS проводилось на кластере с сетью «Ангара». Кластер состоит из 36 узлов, объединенных сетью «Ангара» [11, 12]. В кластере два типа узлов: 24 узла с двумя процессорами Intel Xeon E5-2630 (по 6 ядер, 2.3 ГГц) и 12 узлов с одним процессором Intel Xeon E5-2660 (8 ядер, 2.2 ГГц). Память каждого узла — 64 ГБ. Узлы объединены сетью «Ангара» с топологией 3D-тор 3x3x4. В исследовании использовалась библиотека MPI, основанная на MPICH версии 3.0.4.
В исследовании использовались синтетические графы типа RMAT [13], со средней связностью вершин 32, в качестве весов дуг брались случайные действительные числа в диапазоне [0; 1). Генератор графа реализован авторами статьи, вершины после генерации случайно и поровну распределялись по процессам или объектам.
Все реализации запускались при использовании 8-ми ядер на каждом вычислительном узле. Для оптимизированной версии на Charm++, рассмотренной в разделе 4.2, использовалось по 8 chare-объектов на вычислительный узел - столько, сколько использовалось же ядер при запуске. Реализации в модели vertex-centric запускались с количеством объектов, равным количеству вершин в графе.
В табл. 1 приведено время работы рассматриваемых реализаций на RMAT-графе (N=221) в зависимости от количества узлов кластера с сетью «Ангара». В табл. 2 приведено время работы рассматриваемых реализаций в зависимости от размеров RMAT-графов на 32 узлах кластера с сетью «Ангара».
Стоит обратить внимание, что оптимизированная версия на Charm++, в основном работает чуть медленнее, чем версия с использованием MPI. Реализация на Charm++ быстрее MPI только на небольших графах или на од-
23
Computational nanotechnology
4-2015
ISSN 2313-223X
ном вычислительном узле. Причины этого предстоит выяснить.
Реализации в модели vertex-centric ожидаемо показывают значительно худшие результаты, это плата за удобство программирования. Библиотека uChareLib позволяет снизить эти накладные расходы, однако снижение недостаточно, и оно незначительно при большом числе узлов, поэтому необходимы работы по оптимизации uChareLib.
Табл. 1.
Результаты выполнения (в секундах) реализаций алгоритма GHS на RMAT-графе (количество вершин N=221), выполненных при помощи различных технологий в зависимости от числа узлов
кластера с сетью «Ангара».
Реализа- ция/Кол-во узлов 1 2 4 8 16 32
vertex-centric Charm++ 1458,09 674,12 263,96 118,46 64,06 45,91
vertex-centric uChareLib 311,42 208,98 144,63 104,12 80,81 38,50
opt Charm++ 11,27 6,19 2,92 1,53 0,92 1,12
opt MPI 11,55 5,75 2,83 1,33 0,84 1,09
Табл. 2.
Результаты выполнения (в секундах) реализаций алгоритма GHS, выполненных при помощи различных технологий, на 32 узлах кластера с сетью «Ангара» в зависимости от s, где N=2s -
количество вершин в RMAT-графе.
Реализа-ция/Размер графа s 19 20 21 22 23 24
vertex- centric Charm++ 9,14 18,86 45,91 115,21 297,50 дол го
vertex- centric uChareLib 10,09 18,90 38,73 77,98 274,27 дол го
opt Charm++ 0,59 0,91 1,12 1,38 2,88 4,38
opt MPI 0,61 0,74 1,09 1,54 2,30 4,12
6. Заключение
В работе представлено исследование, как алгоритм GHS поиска минимального остов-ного дерева в графе с весами может быть реализован при помощи библиотеки MPI, языка параллельного программирования Charm++, а также в модели vertex-centric на
языке Charm++ и с использованием библиотеки uChareLib - расширения Charm++.
Модель Charm++ более удобна для реализации алгоритма GHS: runtime-система
Charm++ берет на себя работу по определению состояния «тишины», когда все коммуникационные сообщения обработаны, и в сети нет сообщений. В случае использования библиотеки MPI программисту приходится самому реализовывать определения состояния «тишины». Определение состояния «тишины» характерно для задач обработки графов, так как графы имеют нерегулярную структуру, и никогда заранее неизвестно, сколько сообщений в какой момент времени будет послано на каждый из вычислительных узлов распределенной системы.
Оптимизированные реализации алгоритма GHS с использованием библиотеки MPI и Charm++ включают агрегацию вершин графа в каждом вычислительном процессе и «ручную» агрегацию сетевых сообщений. Реализация алгоритма GHS на MPI демонстрирует немного лучшую производительность на 32-узловом вычислительном кластере по сравнению с Charm++, возможно требуется дополнительная оптимизация реализации на Charm++. Также преимущества Charm++ могут проявиться на большом числе узлов, так как в Charm++ реализована автоматическая балансировка нагрузки.
Наиболее естественна и проста для программиста реализация в модели vertex-centric, когда каждой вершине соответствует отдельный вычислительный процесс. В работе рассмотрено две реализации алгоритма GHS в модели vertex-centric, одна с использованием Charm++, другая с использованием разработанного авторами расширения Charm++ - библиотеки uChareLib, которая оптимизирует хранение и управление большого количества мелких объектов в один chare-объект Charm++ с автоматической агрегацией сообщений.
Подход vertex-centric ожидаемо показывает на 1-2 порядка худшую производительность по сравнению с рассмотренными выше оптимизированными реализациями на MPI и Charm++. Библиотека uChareLib обеспечива-
24
СРАВНЕНИЕ ТЕХНОЛОГИЙ ПАРАЛЛЕЛЬНОГО ПРОГРАММИРОВАНИЯ MPIИ CHARM++
НА ПРИМЕРЕ ЗАДАЧИ ПОСТРОЕНИЯ МИНИМАЛЬНОГО ОСТОВНОГО ДЕРЕВА В ГРАФЕ
Мазеев А. В., Семенов А. С., Фролов А. С.
ет некоторое улучшение результатов, однако улучшение недостаточно, требуются работы по оптимизации uChareLib.
Работа выполнена при поддержке гранта РФФИ №15-07-09368.
Список литературы:
1. Message Passing Interface Homepage. URL: http://www.mpi-forum.org (дата обращения: 16.12.2015).
2. Kale L. Charm++: A portable concurrent object oriented system based on C++ / L. Kale, S. Krishnan // SIGPLAN Not. - 1993. - 28(10). - P. 91-108.
3. Фролов А.С. Использование Charm++ для решения графовых задач в масштабах экзафлопсных вычислений / Фролов А.С., А.С. Семенов // Современные информационные технологии и ИТ-образование. - 2015. - Том 2(№11). - С. 608-614.
4. McCune R. Thinking Like a Vertex: a Survey of Vertex-Centric Frameworks for Large-Scale Distributed Graph Processing / McCune R., Weninger T., Madey G. // ACM Comput. Surv. - 2015. - 48(2).
5. Wesolowski L. et al. Tram: Optimizing fine-grained communication with topological routing and aggregation of messages // Parallel Processing (ICPP), 2014 43rd International Conference on. - IEEE, 2014. - C. 211-220.
6. Prim R. C. Shortest connection networks and some generalizations // Bell system technical journal. -1957. - Т. 36. - №. 6. - С. 1389-1401.
7. Kruskal J. B. On the shortest spanning subtree of a graph and the traveling salesman problem // Proceedings of the American Mathematical society. - 1956. -Т. 7. - №. 1. - С. 48-50.
8. Boruvka O. O jistem problemu minimalniim (about a certain minimal problem) // Praca Moravske Prirod-ovedecke Spolecnosti. v3. - 1926. - С. 37-58.
9. Gallager R. G. A distributed algorithm for minimum-weight spanning trees / Gallager R. G., Humblet P. A., Spira P. M. // ACM Transactions on Programming Languages and systems (TOPLAS). - 1983. - Т. 5. - №. 1. - С. 66-77.
10. Awerbuch B. Optimal distributed algorithms for minimum weight spanning tree, counting, leader election, and related problems // Proceedings of the nineteenth annual ACM symposium on Theory of computing. - ACM, 1987. - С. 230-240.
11. Симонов А.С. и др. Первое поколение высокоскоростной коммуникационной сети «Ангара» //
Наукоемкие технологии. - 2014. - Т. 15, №1. - С. 21-28.
12. Слуцкин А.И. и др. Разработка межузловой коммуникационной сети ЕС8430 «Ангара» для перспективных суперкомпьютеров // Успехи современной радиоэлектроники. - 2012. - №1. - С. 6-10.
13. Chakrabarti D. R-MAT: A Recursive Model for Graph Mining / Chakrabarti D., Zhan Y., Faloutsos // SDM. - 2004. - Т. 4. - С. 442-446.
25
