CC BY
97
Computational nanotechnology
4-2015
ISSN 2313-223X
1. ТЕХНОЛОГИИ ВЫЧИСЛИТЕЛЬНОЙ ОБРАБОТКИ
1.1. ОБЗОР ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ
_ _ W
ПАРАЛЛЕЛЬНЫХ ГРАФОВЫХ ПРИЛОЖЕНИИ ДЛЯ СУПЕРКОМПЬЮТЕРНЫХ КОМПЛЕКСОВ
Фролов Александр Сегреевич, начальник отдела, АО «НИЦЭВТ». E-mail: [email protected]
Семенов Александр Сегреевич, канд. техн. наук, начальник сектора, АО «НИЦЭВТ». E-mail: se-menov@nicevt. ru
Марков Александр Сегреевич, д-р физ.-мат. наук, профессор, АО «НИЦЭВТ». E-mail: [email protected]
Аннотация: В статье рассматриваются инструментальные средства - языки программирования, библиотеки, ориентированные на обработку задач с интенсивной работой с данными, в том числе больших графов, с использованием суперкомпьютеров. Для анализа были выбраны следующие программные системы: Parallel Boost Graph Library, Active Pebbles, Grappa, Parallex/HPX-5 и Charm++. Приводится анализ как программных моделей, так и наиболее важных аспектов их реализации для современных массово -параллельных высокопроизводительных систем.
Ключевые слова: параллельная обработка графов, программные модели, вычислительные модели, суперкомпьютеры, экзафлопс.
SURVEY OF LARGE-SCALE GRAPH PROCESSING MODELS FOR HIGH PERFOMANCE
COMPUTING SYSTEMS
Frolov Alexander Sergeevich, head of department, JSC SRCECT. E-mail: [email protected]
Semenov Alexander Sergeevich, Ph.D., head of sector, JSC SRCECT. E-mail: [email protected]
Markov Alexander Sergeevich, Ph. D., professor, JSC SRCECT. E-mail: [email protected]
Abstract: In the paper a survey of perspective programming models for large-scale graph processing is presented. For analysis the following models have been selected: Parallel Boost Graph Library, Active Pebbles, Grappa, Par-allex/HPX-5, and Charm++. Programming models as well as most important aspects of its implementation are presented in the analysis.
Index terms: parallel graph computation, program models, computation models, supercomputers, exascale.
Введение
Параллельная обработка больших графов -относительно новая, динамично развивающаяся область приложений суперкомпьютерных комплексов. Основные проблемы параллельной обработки графов с использованием суперкомпьютеров сформулированы в статье [1]. Ниже приводятся основные из них:
- вычисления в графовых задачах сильно зависят от потоков данных внутри задачи, которые определяются структурой графа и, как следствие, не известны до момента начала выполнения программы;
- нерегулярная структура графов сильно осложняет распределение данных по узлам вычисли-
тельной системы, что приводит к несбалансированной нагрузке на вычислительные узлы; повышение качества распределения требует выполнения предобработки графа, а также, возможно, искусственного изменения его структуры (методы «разрезания» вершин с высокой степенью (vertex splitting или vertex-cut) [2,3]);
- нерегулярная структура графов приводит к низкой локализации при работе с данными, что, с одной стороны, порождает большое количество коротких сообщений, передаваемых по коммуникационной сети, с другой - нерегулярную работу с локальной памятью, что приводит к неэффективному использованию подсистемы памяти вследствие частых промахов в кэши дан-
6
ОБЗОР ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ ПАРАЛЛЕЛЬНЫХ ГРАФОВЫХ ПРИЛОЖЕНИЙ
ДЛЯ СУПЕРКОМПЬЮТЕРНЫХ КОМПЛЕКСОВ Фролов А. С., Семенов А. С., Марков А. С.
ных, TLB, низкой эффективности механизма предвыборки данных;
- преобладание операций с памятью над вычислениями (т. е. арифметическими операциями).
Использование традиционных технологий параллельного программирования, таких как MPI [4] и OpenMP [5] приводит к высокой сложности создания параллельных программ обработки графов, так как в них отсутствует какая-либо поддержка нерегулярной работы с большими данными, и прикладной программист вынужден вручную выполнять работу по оптимизации программ (например, агрегацию коротких сообщений и совмещение вычислений с коммуникациями).
Как следствие, возникла потребность в создании специализированных программных моделей, в которых были бы заложены конструкции для максимально простого выражения параллелизма с очень мелкой гранулярностью, а ответственность за эффективность выполнения лежала бы на системе поддержки выполнения параллельных программ (или runtime-системе).
Другими предпосылками появления новых программных моделей стали следующие архитектурные особенности существующих параллельных вычислительных систем. Во-первых, современные процессоры способны выполнять тысячи операций в каждом ядре за время выполнения одного обращения к удаленной памяти, которое может составлять до нескольких микросекунд. Во-вторых, современные коммуникационные сети имеют относительно низкий темп передачи коротких сообщений и высокую пропускную способность при передаче длинных, таким образом, передача длинных сообщений более эффективна.
Принимая во внимание тот факт, что нерегулярные приложения, характеризуются интенсивным потоком коротких сообщений, необходимо максимально совмещать вычисления с коммуникациями, а также эффективно агрегировать короткие сообщения, что возможно только при наличии достаточно большого количества параллелизма. Таким образом, представленные ниже программ-
ные модели нацелены главным образом на максимальное облегчение выражения параллелизма для конечных пользователей.
В данной статье рассматриваются программные модели Charm++, Active Pebbles, Parallex/HPX-5, Grappa, которые позволяют адресовать перечисленные выше проблемы и предназначены для суперкомпьютерных комплексов. Также для сравнения в анализ включена библиотека графовых алгоритмов Parallel BGL, использующая хорошо известную BSP-модель (Bulk Syncrhonous Parallel) для организации параллельного выполнения программ.
Parallel BGL
Библиотека Parallel Boost Graph Library (Parallel BGL, PBGL) [6,7,8] разработана в Индианском университете в Блумингтоне и включена в состав набора библиотек Boost для C++.
Также как и библиотека последовательных графовых алгоритмов Boost Graph Library (BGL), на основе интерфейса которой построен интерфейс Parallel BGL, в Parallel BGL активно используются шаблоны (по сути BGL и PBGL являются библиотеками шаблонов типов данных, необходимых для представления графа, и алгоритмов обработки графов), что позволяет использовать реализованные в Parallel BGL алгоритмы как с типами данных (распределенными представлениями графов), реализованными в Parallel BGL, так и с представлениями, реализованными пользователем.
Одним из наиболее распространённых представлений графов в Parallel BGL является список смежных вершин, доступный в виде шаблона adjacency_list. Данное представление подходит практически для всех графов, за исключением очень плотных графов, а также совместимо с большинством алгоритмов, реализованных в Parallel BGL. С помощью данного шаблона можно варьировать структуры данных для хранения вершин и ребер, указывать свойства ребер и вершин.
7
Computational nanotechnology
4-2015
ISSN 2313-223X
Например, структура данных для хранения представления графа в BGL может быть следующей:
typedef adjacency_list<listS, // хранение вершин vecS, // хранение ребер bidirectionalS, // направленность property<vertex_distance_t, double>, property<edge_weight_t, double> > Graph;
Первый параметр определяет структуру данных, в которой будут храниться вершины графа, в данном случае используется listS, что означает, что вершины будут храниться в связанном списке. Второй параметр определяет структуру для хранения ребер, vecS -вектор из STL. Параметр bidirectionalS означает, что граф ориентированный. Также допустимы другие типы данных: множества (setS и multisets) и хеш-таблицы (hash_setS, hash_mapS и др.).
Последние два параметра определяют наборы свойств для вершин и ребер. В данном случае каждой вершине будет сопоставлен параметр vertex_distance - вещественное число, определяющее расстояние вершины от какой-либо другой вершины (в зависимости от конкретного алгоритма), аналогично каждому ребру будет сопоставлен вес.
сунка, вершины графа распределены равными блоками (по три вершины) между тремя процессами. Вся информация о ребрах вершины хранится вместе с вершиной. Кроме того, параметры вершин и ребер (расстояние, вес и т. п.) также хранятся вместе с вершиной в одном процессе, что обеспечивает локальную работой с памятью при обработке вершин.
Доступ к вершинам возможен с помощью функции vertex(). При этом возвращается дескриптор вершины:
graph_traits<Graph>::vertex_descriptor s = vertex(i,G)
В данном случае i - глобальный идентификатор вершины.
Для хранения параметров вершин и ребер используются специальные таблицы (для каждого параметра своя таблица), реализация которых определяется через шаблонный класс property_map. Как уже было сказано, распределение записей таблиц по процессам соответствует распределению вершин (и ребер) графа. Так, доступ к таблице, содержащей параметр вершины расстояние (distance), осуществляется следующим образом:
property_map<Graph, vertex_distance_t>::type
В Parallel BGL для распределения вершин по параллельным процессам используется соответствующий селектор distributedS<...>. Таким образом, распределенный вариант предыдущего графа выглядит следующим образом:
typedef adjacency_list<listS,
distributedS<mpi::bsp_process_group,
vecS>,
bidirectionalS,
property<vertex_distance_t, double>, property<edge_weight_t, double> > Graph;
Первый параметр в distributedS<...> указывает тип группы процессов (process group) для выполнения параллельного алгоритма. В данном случае используется модель Bulk Synchronous Parallel (BSP) [9], реализованная с помощью MPI.
На рисунке 1 показан пример распределения вершин по процессам. Как видно из ри-
distance = get(vertex_distance, G);
' ь
(б)
Рис. 1. Распределение графа в Parallel BGL (а - граф, б - представление графа).
Доступ к записям распределенной таблицы с параметрами вершин (ребер) осуществляется с помощью следующих функций:
- функция get(p,k) считывает запись в таблице р, ассоциированную с ключем k. Если запись нахо-
8
ОБЗОР ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ ПАРАЛЛЕЛЬНЫХ ГРАФОВЫХ ПРИЛОЖЕНИЙ
ДЛЯ СУПЕРКОМПЬЮТЕРНЫХ КОМПЛЕКСОВ Фролов А. С., Семенов А. С., Марков А. С.
дится локально (т. е. в том же процессе, в котором инициирован вызов функции get), то значение будет возвращено немедленно, в противном случае значение будет считано из так называемой «теневой» записи (ghost cell), если таковая существует. Если теневой записи нет, то она будет создана с значением по умолчанию (может быть определено пользователем). После чего значение в теневой записи будет синхронизировано со значением записи непосредственно в таблице p (т. е. значением записи, содержащимся в процессе, которому принадлежит запись). Таким образом гарантируется консистентность таблицы и всех ее теневых записей (по сути являющимся распределенным программным кэшем таблицы).
- функция put(p,k,v) записывает новое значение v в запись в таблице p, ассоциированную с клю-чем k. Если запись находится локально, то операция будет выполнена немедленно, в противном случае будет отправлено сообщение с v процессу, в котором находится запись с адресом k.
Таким образом, в Parallel BGL реализован набор алгоритмов для параллельной обработки графов, которые могут быть использованы с различными представлениями графа, как входящими в состав Parallel BGL, так и определяемые пользователем. Параллельная обработка графов выполняется в соответствии с моделью BSP [9], то есть состоит из итераций, в каждой итерации выполняются вычисления и передача данных. Между итерациями выполняется глобальная барьерная синхронизация.
Active Pebbles
Библиотека Active Pebbles [10,11,12], также как и Parallel BGL, разрабатывается в университете Индианы, однако в отличие от Parallel BGL нацелена на отработку новых принципов построения программных и вычислительных моделей, ориентированных на более широкий спектр приложений, характеризующихся
интенсивной работой с данными (data-centric или DIS-задачи).
В основе модели Active Pebbles лежат следующие принципы:
- мелко-зернистый параллелизм, выраженный в виде глобально адресуемых активных сообщений (в терминах модели Active Pebbles такие сообщения называются Pebbles, для удобства восприятия в данной статей будет использоваться термин p-сообщение);
- агрегация сообщений, стандартный механизм объединения коротких сообщений для повышения эффективности использования пропускной способности коммуникационной сети; параметры механизма агрегации сообщений (количество коротких сообщений в одном агрегированном сообщении), как правило, отражают некоторый оптимальный баланс между задержкой и пропускной способностью с целью повышения темпа выдачи сообщений;
- активная маршрутизация, внесение искусственных ограничений на топологию (вместе с программной маршрутизацией сообщений) для повышения реальной пропускной способности передачи сообщений за более гибкого распределения трафика по узлам коммуникационной сети;
- редукция сообщений, анализ и обработка сообщений в узлах-источниках и на промежуточных (транзитных) узлах во время маршрутизации сообщений;
- автоматическое определение окончания выполнения программы, предоставление средств настройки и контроля условий завершения программы.
В основе модели Active Pebbles (см. рисунок 2) лежат два типа объектов: p-
сообщения (от pebbles) и t-объекты (от targets). P-сообщения - «легковесные» сообщения, которые обрабатываются в t-объектах. T-объекты образуются посредством объединения данных и обработчиков сообщений. P-сообщения обладают свойством «неупорядоченности», то есть обрабатываются в произвольном порядке.
9
Computational nanotechnology
4-2015
ISSN 2313-223X
Рис. 2. Вычислительная модель Active Pebbles.
Распределение t-объектов по процессам определяется пользователем. Каждый t-объект имеет идентификатор (или адрес), который однозначно определяет t-объект. Множество идентификаторов формирует глобальное адресное пространство (аналогично другим моделям, поддерживающим глобальную адресацию памяти и/или объектов).
Модель Active Pebbles допускает использование как статического распределения t-объектов по процессам, так и динамического. В случае статического распределения функция вычисления местоположения t-объекта (т. е. номера процесса, в котором находится t-объект) требует константное количество времени и памяти. В отличие от моделей Charm++ и X10, объекты которых могут мигрировать между процессами runtime-системы и, как следствие, вычисление физического адреса объекта имеет сложность O(n), вычисление адреса в Active Messages занимает O(1) времени (т. е. не зависит от числа t-объектов).
Агрегация сообщений - одна из основных особенностей модели Active Pebbles. Использование агрегации сообщений - стандартный прием для повышения эффективности использования коммуникационной сети, заключается в объединении некоторого количества коротких сообщений в одно и отправку его по ком-
муникационной сети. Агрегация сообщений позволяет за счет увеличения задержки передачи коротких сообщений повысить эффективность использования пропускной способности коммуникационной сети.
Размер агрегированного сообщения (т. е. количество коротких сообщений) является параметром и может изменяться динамически пользователем в процессе выполнения.
Одним из типичных вопросов реализации агрегации сообщений является определение момента окончания потока коротких сообщений. Одним из решений может являться использование таймера для отправки накопленных сообщений. Также в Active Pebbles предоставляется возможность принудительной отправки сообщений через вызов функции flush().
Другой вопрос, связанный с агрегацией сообщений, - это организация буферов для хранения агрегированных сообщений на стороне отправителя. Наиболее простое решение - использование N-1 буферов, где N - количество процессов, на которых запущена задача (т. е. runtime-система), такое решение практично только при небольшом N, так как для большого количества процессов объем памяти для хранения буферов может быть недопустимо большим.
10
ОБЗОР ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ ПАРАЛЛЕЛЬНЫХ ГРАФОВЫХ ПРИЛОЖЕНИЙ
ДЛЯ СУПЕРКОМПЬЮТЕРНЫХ КОМПЛЕКСОВ Фролов А. С., Семенов А. С., Марков А. С.
Кроме того, такой способ агрегации не позволяет добиться плотной упаковки коротких сообщений, так как при равномерном распределении вероятности обмена сообщениями между процессами (например, при шаблоне все-всем) вероятность обмена между двумя процессами обратно пропорциональна N. Соответственно, если процесс выдает M сообщений, то каждому из процессов будет отправлено M/N, что при фиксированном M и увеличении N (случай strong-scaling масштабирования) означает уменьшение размера агрегированного сообщения и уменьшение эффективности агрегации в целом.
Решение данной проблемы возможно с использованием программной маршрутизацией сообщений. В модели Active Messages такой подход называется активной маршрутизацией (active routing). Суть метода заключается в построении виртуальной сети из участвующих в выполнении процессов runtime-системы. В модели Active Pebbles для данной цели поддерживается топология гиперкуб, но могут быть реализованы и другие топологии. Далее процессы могут обмениваться сообщениями только с соседями по виртуальной сети. С одной стороны, такой подход ограничивает маршрутизацию сообщений выбранной виртуальной топологией, с другой стороны, программная агрегация работает намного эффективнее, чем в случае использования N буферов.
Второй задачей активной маршрутизации в Active Pebbles является редукция сообщений в промежуточных узлах виртуальной сети, а также в узлах-источниках. Для редукции сообщений в каждом узле (процессе) содержится программно-реализованная кэш-таблица, которая просматривается при пересылке каждого сообщения. Для эффективной передачи сообщений поиск в кэш-таблице должен занимать константное время, поэтому в Active Pebbles используется кэш-таблица с прямой адресацией, размер таблицы может изменяться динамически. Промах в таблицу инициирует замену старой записи на новую.
Для определения момента завершения выполнения программы в Active Pebbles введены
два взаимодополняющих механизма. Первый основан на SKR-алгоритме [22], использующем неблокирующую операцию allreduce(). SKR-алгоритм используется в случаях, когда структура программы с точки зрения цепочек сообщений может быть произвольная. Второй метод может быть применен в случаях, когда заранее можно оценить длину «коммуникационных цепочек», то есть количество сообщений передаваемых между t-объектами. В таком случае, для обнаружения момента окончания вычислений можно использовать алгоритмы, учитывающие общее количество пересылок между t-объектами.
Итак, в Acitive Pebbles реализована асинхронная программная модель с управлением потоком данных, активной маршрутизацией и гибким автоматическим определением момента завершения выполнения программы. В настоящий момент разрабочиками исследуется возможность реализации алгоритмов из Parallel BGL на модели Active Pebbles.
Charm++
Язык параллельного программирования Charm++ [13,14] является расширением языка C++ и основан на объектно-ориентированной модели с управлением асинхронным потоком сообщений.
Базовым объектом в Charm++ является chare (или chare-объект), обладающий помимо всех свойств объектов в С++ (инкапсулированными данными, множеством публичных и приватных методов и т. п.) интерфейсом из специальных entry-методов, вызовы которых соответствуют передаче данных (т. е. сообщений) между chare-объектами.
Приложение в Charm++ состоит из множества chare-объектов, обменивающихся между собой данными посредством вызовов entry-методов. Кроме того, вызов entry-метода порождает выполнение непосредственно самого метода на том узле, где находится chare-объект, entry-метод которого был вызван, то есть таким образом реализуется концепция управления потоком данных или активных сообщений.
11
Computational nanotechnology
4-2015
ISSN 2313-223X
В процессе выполнения entry-метода могут быть изменены только данные, принадлежащие chare-объекту. Одновременно у chare-объекта может выполняться не более одного entry-метода, что позволяет избежать про-
блемы обеспечения атомарности изменения данных, принадлежащих chare-объекту, и значительно упрощает программирование. Схематически программная модель Charm++ представлена на рисунке 3.
Charm++ RTS Msg Queue Charm++ RTS Msg Queue
Machine Layer ■■■■■■ Machine Layer
Interconnect
Рис.3. Программная модель Charm++.
Кроме простых chare-объектов Charm++ имеется возможность создавать массивы chare-объектов. При этом массивы бывают как одномерными, так и многомерными. Использование массивов позволяет создавать большое количество chare-объектов, управлять их распределением по вычислительным узлам, выполнять над ними коллективные операции.
Также в Charm++ поддерживается автоматическая динамическая балансировка нагрузки на вычислительные узлы, что реализуется на уровне runtime-системы за счет перемещения chare-объектов между вычислительными узлами (миграция chare-объектов). Для прикладного программиста данная возможность совершенна прозрачна, так как программная модель Charm++ не специфицирует расположение chare-объектов в вычислительной системе, и все объекты адресуются в едином адресном пространстве.
Charm++ естественно подходит для разработки графовых приложений, в особенности для алгоритмов в которых используется vertex-centric подход (VC-модель) к описанию вычислений, в котором каждой вершине графа соответствует chare-объект. В данном случае единственной проблемой могут стать накладные расходы runtime-системы, возникающие при необходимости работе с миллинами chare-объектов.
ParalleX/HPX-5
Вычислительная (и программная) модель ParalleX [15-17] разрабатывается с явной ориентацией на суперкомпьютеры экзафлопсного класса производительности под руководством Т. Стерлинга. Также как и ранее рассмотренные вычислительные модели (Active Pebbles и Charm++), модель ParalleX основана на асинхронном выполнении легковесных потоков (тредов).
В настоящее время разработана runtime-система HPX-5, реализующая основные концепции модели ParalleX (см. рисунок 5), в том числе активное глобальное адресное пространство (AGAS), локальные объекты синхронизации (LCO-объекты), например, реализующие семантику future-переменных [18], легковесные потоки вычислений.
В HPX-5 программа пользователя состоит из множества ParalleX-процессов (или P-процессов), имеющих доступ к глобальному адресному пространству. Физическое размещение объектов не зависит от глобально виртуального адреса, таким образом, любой объект может перемещаться в физическом пространстве, не меняя при этом своего глобального адреса.
12
ОБЗОР ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ ПАРАЛЛЕЛЬНЫХ ГРАФОВЫХ ПРИЛОЖЕНИЙ
ДЛЯ СУПЕРКОМПЬЮТЕРНЫХ КОМПЛЕКСОВ Фролов А. С., Семенов А. С., Марков А. С.
I I Локальность
. . Процесс
\ \ Локальная память
ж LCO-объект Тред (поток)
----- Приостановленный тред (поток)
-----*- Операция доступа к локальной памяти
• Операция доступа к объекту в GAS-пространстве
-----*- Локальная операция
-----р- Отправка Parcel-сообщения
Рис. 4. Программная модель ParalleX. (а) - создание локального треда, (b) -создание удаленного треда, (c) - удаленная атомарная операция, (d) - активация по изменению состояния LCO-объекта, (e) - активация треда при получении Parcel-сообщения, (f) - доступ к future-переменной.
В HPX-5 поддерживается механизм инициации вычислений, основанный на возникновении определенных пользователем событий (например, получении данных), что позволяет выполнять вычисления в том месте, где находятся данные (что по сути является основной идеей активных сообщений). Таким образом в HPX-5 поддерживается как модель распределенного адресного пространства (PGAS), так и модель активного адресного пространства (AGAS). При этом модель PGAS является частным случаем более общей с точки зрения функциональных возможностей модели AGAS.
Непосредственное выполнение вычислений в HPX-5 осуществляется с помощью action-тредов, которые создаются при получении специальных пакетов с данными (parcel-сообщения). При отправке parcel-сообщения в качестве адреса указывается адрес из глобального адресного пространства, определение физического местоположения адресуемого объекта осуществляется runtime-системой.
В HPX-5 реализовано несколько вариантов различных объектов для быстрого выполнения операций синхронизации (LCO-объекты), при этом создается динамический распределенный граф LCO-объектов. Такой подход
13
Computational nanotechnology
4-2015
ISSN 2313-223X
позволяет контролировать выполнения программы, избежать необходимость использования глобальных барьеров, динамически распределять вычислительную нагрузку, а также адаптироваться к данным в процессе выполнения программы.
Наиболее часто используемые LCO-объекты: future-объекты. Future-объекты могут блокировать выполнение треда до тех пор, пока объект не будет готов к соответвующей операции (чтения или записи). Так, если тред выполняет чтение данных из future-объекта, то объект должен быть в состоянии готовности для операции чтения, в противном случае тред будет заблокирован до момента изменения состояния future-объекта.
В HPX-5 реализованны два различных транспортных протокола. Первый использует асинхронные операции Isend/Irecv (ISIR-протокол). Второй - коммуникационную операцию Put с подтверждением завершения (Put with Completion, PWC-протокол). Для реализации ISIR-протокола используется библиотека MPI с
двусторонними асинхронными коммуникационными операциями (MPI_Isend, MPI_Irecv). Для PWC-протокола используется коммуникационная библиотека Photon [19], эффективно поддерживающая односторонние RDMA-операции с подтверждением.
Grappa
Проект Grappa [20,21] системы программирования для разработки нерегулярных задач, то есть задач с интенсивной нерегулярной работой с памятью, основан на массово-мультитредовой вычислительной модели и распределенной общей памяти и разрабатывается в Вашингтонсоком университете с 2011 года. Программный интерфейс Grappa ориентирован как на использование Grappa в качестве библиотеки для написания прикладных задач, так и в качестве целевой платформы для трансляторов с языков программирования более высокого уровня. Grappa разрабатывается на языке С++11 и в качестве коммуникационного уровня используется библиотеки MPI или GASNet.
14
ОБЗОР ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ ПАРАЛЛЕЛЬНЫХ ГРАФОВЫХ ПРИЛОЖЕНИЙ
ДЛЯ СУПЕРКОМПЬЮТЕРНЫХ КОМПЛЕКСОВ Фролов А. С., Семенов А. С., Марков А. С.
Runtime-система модели Grappa (см. рисунок 5) состоит из трех основных подсистем:
- подсистема управления заданиями поддерживает максимально облегченную мультитредовую модель выполнения программ для обеспечения толерантности к коммуникационным задержкам и реализует механизм глобального распределения вычислений (т. е. заданий) по вычислительным узлам (процессам runtime-системы) за счет возможности доступа к очередям заданий в других процессах. Немаловажную роль в данной подсистеме играют потоки-планировщики (или в термина Grappa - worker-треды), которые обеспечивают планирование выполнения пользовательских потоков (тредов). Целесообразным считается использование большого количестве потоков-планировщиков (например, несколько сотен) на ядро процессора для быстрого переключения контекста и минимизации простоя в использовании ресурсов конвейера ядра процессора.
- подсистема коммуникаций используется для агрегации коротких сообщений и непосредственной доставки сообщений адресатам. Так как передача сообщений должна выполняться с минимальными накладными расходами, то для упаковки и распаковки используется отдельный поток (или потоки), а также для доступа к буферам, содержащим сообщения, используются неблокирующие алгоритмы записи и чтения.
- подсистема поддержки распределенной общей памяти с глобальным адресным пространством обеспечивает выполнение запросов к выделенным сегментам глобальной общей памяти вне зависимости от физического размещения адресуемых данных. В основе реализации распределенной общей памяти лежит модель активных сообщений, посредством которой реализуются операции чтения, записи, а также атомарные операции типа int_fetch_add. Кроме того все ячейки (слова) памяти распределены по процессами runtime-системы, таким образом, любое изменение распределенной памяти возможно только через отправку запроса (делегацию) процессу, которому принадлежит адресуемая ячейка памяти, на соответствующую операцию.
Программная модель Grappa берет свое начало в архитектуре массово-мульти-тредового суперкомпьютера Tera MTA (вторая половина 90-х), поддерживавшего гло-
бальную общую память. Изначально Grappa проектировалась как программная реализация принципов работы Tera MTA для современных кластерных систем. Графовые приложения являются одной из целевых областей приложений, на данный момент для Grappa реализовано несколько типовых графовых алгоритмов, включая BFS, SSSP, CC, PageRank и другие алгоритмы.
Заключение
В статье приведен обзор перспективных программных моделей, предназначенных для решения задач с интенсивной нерегулярной работой с памятью с использованием суперкомпьютеров. Обобщение свойств рассмотренных моделей приведено в таблице 1.
Стоит отметить, что Parallel BGL является библиотекой шаблонов классов и алгоритмом для анализа графов. В настоящее время для параллельной реализации используется вычислительная модель Bulk Synchronous Parallel, однако могут быть использованы и другие вычислительные модели.
Три из рассмотренных моделей - Active Pebbles, ParalleX и Charm++ относятся к классу асинхронных моделей с управлением потоком данных, которые состоят из активных сообщений (pebbles в Active Pebbles и вызовы entry-методов в Charm++). Также в Active Pebbles и Charm++ используется программная маршрутизация агрегированных сообщений в виртуальной коммуникационной сети. Такой метод передачи сообщений позволяет более эффективно агрегировать короткие сообщения и при этом не требует большого количества памяти для буферов, в которых хранятся агрегированные сообщения. В целом, Active Pebbles и Charm++ основаны на одинаковых принципах и различаются только в деталях реализации. В Parallex/HPX-5 в отличие от Active Pebbles и Charm++ добавлена классическая распределенная общая память с глобальным адресным пространством.
15
Computational nanotechnology
4-2015
ISSN 2313-223X
Таблица. 1.
Сравнение программных моделей для создания параллельных графовых приложений
Parallel BGL Active Pebbles Charm++ Parallex/HPX Grappa
Тип программной модели Библиотека шаблонов Библиотека/ Rtunime-система Расширение языка/ библиотека/ Runtime-система Библиотека/ Runtime-система Библиотека/ Rtunime-система
Язык программирования С++ C++ C++ C++ С++11
Тип вычислительной модели BSP Асинхронная модель с управлением потоком данных Асинхронная модель с управлением потоком данных Асинхронная модель с управлением потоком данных и распределенной общей памятью Мультитредовая модель с распределенной общей памятью и активными сообщениями
Распределенная общая память - - - + +
Распределение данных Статическое (блочное) Статическое (блочное), динамическое (управляется пользователем) Статическое (блочное), динамическое (управляется runtime-системой] Статическое (блочное), динамическое Статическое (блочное), (управляется пользователем)
Программная маршрутизация сообщений - + + (библиотека TRAM) - -
Редукция сообщений + + - - -
Обнаружение завершения вычислений - + + - -
Графовые алгоритмы Итерацион- ные Итерационные, асинхронные Итерационные, асинхронные Итерационные, асинхронные Итерационные
Область применения Обработка графов Общего назначения (DIS-задачи) Общего назначения (DIS-задачи) Общего назначения (DIS-задачи) Общего назначения (DIS-задачи)
Представителем другого подхода является проект Grappa, в основе программной модели которого лежат массовая многопоточность (мультитредовость), распределенная общая память и активные сообщения. В отличие от моделей Active Pebbles и Charm++ в Grappa нет выделенных объектов, а данные хранятся в распределенных сегментах с простой линейной адресацией. В многом это обеспечивает привычную среду программирования для большинства разработчиков параллельных программ (близкую по стилю к OpenMP).
Все рассмотренные модели представляют интерес с точки зрения исследования создания средств параллельного программирования задач, ориентированных на обработку данных в масштабах экзафлопсных суперком-
пьютеров. Дальнейшие исследования будут направлены на сравнение производительности реализаций рассмотренных программных моделей и создание собственного варианта программной модели для решения DIS-задач на экзафлопсных суперкомпьютерах.
Работа выполнена при поддержке РФФИ (грант №15-07-09368).
Список литературы:
1. Lumsdaine, Andrew, et al. "Challenges in parallel graph processing." Parallel Processing Letters 17.01 (2007): 5-20.
2. Chakaravarthy, Venkatesan T., et al. "Scalable single source shortest path algorithms for massively par-
16
ОБЗОР ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ ПАРАЛЛЕЛЬНЫХ ГРАФОВЫХ ПРИЛОЖЕНИЙ
ДЛЯ СУПЕРКОМПЬЮТЕРНЫХ КОМПЛЕКСОВ Фролов А. С., Семенов А. С., Марков А. С.
allel systems." Parallel and Distributed Processing Symposium, 2014 IEEE 28th International. IEEE, 2014.
3. Pearce, Roger, Maya Gokhale, and Nancy M. Amato. "Faster parallel traversal of scale free graphs at extreme scale with vertex delegates." Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. IEEE Press, 2014.
4. Gropp, William, et al. "A high-performance, portable implementation of the MPI message passing interface standard." Parallel computing 22.6 (1996): 789-828.
5. Dagum, Leonardo, and Rameshm Enon. "OpenMP: an industry standard API for shared-memory programming." Computational Science & Engineering, IEEE 5.1 (1998): 46-55.
6. Douglas Gregor and Andrew Lumsdaine. The Parallel BGL: A Generic Library for Distributed Graph Computation. Workshop on Parallel Object-Oriented Scientific Computing. July, 2005
7. Douglas Gregor and Andrew Lumsdaine. Lifting Sequential Graph Algorithms for Distributed-Memory Parallel Computation. Object-Oriented Programming, Systems, Languages, and Applications. October, 2005
8. Jeremy G. Siek, Lie-Quan Lee, and Andrew Lumsdaine. "The boost graph library: user guide and reference manual" Addison-Wesley 2002..
9. Valiant, Leslie G. "A bridging model for parallel computation." Communications of the ACM 33.8 (1990): 103-111.
10. Willcock, Jeremiah James, et al. "Active pebbles: parallel programming for data-driven applications." Proceedings of the international conference on Supercomputing. ACM, 2011.
11. Willcock, Jeremiah James, et al. "AM++: A generalized active message framework." Proceedings of the 19th international conference on Parallel architectures and compilation techniques. ACM, 2010.
12. Firoz, Jesun Sahariar, et al. "Comparison Of Single Source Shortest Path Algorithms On Two Recent Asynchronous Many-task Runtime Systems."
13. Laxmikant V. Kale and Sanjeev Krishnan. Charm++: A portable concurrent object oriented system based on c++. SIGPLAN Not., 28(10):91-108, October 1993.
14. Kale, Laxmikant V., et al. "Charm++ for productivity and performance: A submission to the 2011 HPC class II challenge." (2011).
15. Kaiser, Hartmut, Maciej Brodowicz, and Thomas Sterling. "Parallex an advanced parallel execution model for scaling-impaired applications." Parallel Processing Workshops, 2009. ICPPW'09. International Conference on. IEEE, 2009.
16. Anderson, Matthew, et al. "A dynamic execution model applied to distributed collision detection." Supercomputing. Springer International Publishing, 2014.
17. Heller, T., H. Kaiser, and Klaus Iglberger. "Application of the ParalleX execution model to stencil-based problems." Computer Science-Research and Devel-opment28.2-3 (2013): 253-261.
18. Dekker, L., W. Smit, and J. C. Zuidervaart. "Programming Models and Tools for Massively Parallel Computers." Massively Parallel Processing Applications and Development: Proceedings of the 1994 EUROSIM Conference on Massively Parallel Processing Applications and Development, Delft, The Netherlands, 21-23 June 1994. Elsevier, 2013.
19. Kissel, Ezra, and Martin Swany. "Session layer burst switching for high performance data movement." Proceedings of PFLDNet. 2010.
20. B. Holt, J. Nelson, B. Myers, P. Briggs, L. Ceze, S. Kahan, and M. Oskin. Flat combining synchronized global data structures. In International Conference on PGAS Programming Models (PGAS), Oct 2013.
21. Jacob Nelson, Brandon Myers, A. H. Hunter, Preston Briggs, Luis Ceze, Carl Ebeling, Dan Grossman, Simon Kahan, and Mark Oskin. 2011. Crunching large graphs with commodity processors. In Proceedings of the 3rd USENIX conference on Hot topic in parallelism (HotPar'11). USENIX Association, Berkeley, CA, USA, 10-10.
22. Sinha, Amitabh B., Laxmikant V. Kale, and Balkrishna Ramkumar. "A dynamic and adaptive quiescence detection algorithm." University of Illinois at Urbana-Champaign, Urbana-Champaign (1993).
17
