CC BY
110
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
УДК 004.454 Дата подачи статьи: 27.07.15
DOI: 10.15827/0236-235X.112.093-098
ПОДДЕРЖКА ПРОТОКОЛА MPIВ ЯДРЕ ОС LINUX ДЛЯ МНОГОПРОЦЕССОРНЫХ ВЫЧИСЛИТЕЛЬНЫХ КОМПЛЕКСОВ НА БАЗЕ ВЫСОКОСКОРОСТНЫХ КАНАЛОВ RapidIO
А.С. Кулешов, аспирант, rndfax@ps.niisi.ras.ru (ФНЦ НИИСИ РАН, Нахимовский просп, 36, корп. 1, г. Москва, 11 7218, Россия)
Решение вычислительных задач на многопроцессорных вычислительных комплексах в конечном итоге опирается на определенный программный интерфейс передачи данных. Таким наиболее распространенным интерфейсом является интерфейс передачи сообщений MPI, который определяет стандарт передачи данных для конечных пользовательских программ. В статье показана реализация протокола MPI для разработанной в НИИСИ РАН микросхемы 1890ВМ6Я, являющейся основой для многопроцессорных вычислительных комплексов различного назначения, узлы которого могут быть связаны через высокоскоростные каналы RapidIO. Для реализации были взяты наиболее распространенная библиотека MPI - MPICH и хорошо зарекомендовавшее себя в суперкомпьютерных вычислениях ядро ОС Linux. MPICH в базовой поставке предоставляет различные сетевые модули, реализующие связку интерфейса библиотеки с определенными транспортными драйверами: tcp (Ethernet TCP/IP), ib (Infiniband), mx (Myrinet eXpress) и другими. Задействование наиболее подходящего под архитектуру RapidIO сетевого модуля mx позволило сосредоточиться только на разработке Linux-драйвера для контроллера RapidIO. Особенности контроллера RapidIO микросхемы 1890ВМ6Я, интерфейса MPI и идея использования канала RapidIO для других, отличных от MPI целей позволили создать достаточно универсальный стек передачи сообщений через канал RapidIO без избыточных копирований данных. В конце статьи приведены результаты работы тестовых MPI-программ, таких как NAS Parallel Benchmarks и OSU Micro-Benchmarks, на 4 узлах через канал RapidIO, дано заключение о проделанной работе и подведен итог использования контроллера RapidIO микросхемы 1890ВМ6Я в качестве транспортной среды для протокола MPI.
Ключевые слова: RapidIO, MPI, MPICH, Linux.
Проблема построения эффективных вычислительных систем, решающих разнообразные задачи - от научных до военных, упирается в доставку данных до вычислительных компонент: будь то центральный процессор, специализированная интегральная схема или графический ускоритель. В то время как на аппаратном уровне идет бурное развитие различных сетевых идеологий, с программной точки зрения самым распространенным средством передачи данных для многопроцессорных комплексов является интерфейс передачи сообщений (MPI) [1].
Разработанная в НИИСИ РАН микросхема 1890ВМ6Я, являющаяся микросхемой общего назначения, имеет в своем составе, помимо всего прочего, центральный процессор, мощный математический сопроцессор и контроллер RapidIO [2]. Коммутатор RapidIO 1890КП3, также разработанный в НИИСИ РАН, позволяет объединить эти микросхемы в сеть RapidIO и сформировать высокопроизводительный многопроцессорный вычислительный комплекс. Далее в данной статье представлена реализация MPI для вычислительного комплекса на базе микросхем семейства 1890ВМ6Я с возможностью исполнения операций приема/передачи данных по RapidIO без копирования (zero-copy/data offload).
При решении задачи запуска MPI-приложений на вычислительном комплексе возникает один из главных вопросов - рабочее окружение, состоящее из таких компонентов, как ядро ОС и набор библиотек. В качестве ядра ОС было выбрано ядро Linux, так как оно в связке с библиотеками MPI по-
казало свою эффективность в распределенных вычислениях [3-5], а в качестве библиотеки MPI -MPICH как одна из широко используемых реализаций MPI [6].
Архитектура библиотеки MPICH
В процессе своего развития библиотека MPICH пришла к стройной многоуровневой архитектуре
[7, 8] (см. рис. 1).
MPI Application
MPI Interface
MPICH2
ROMIO
ADI3 Interface
CH3 Device
CH3 Interface
Nemesis
Netmod Interface
Pc
О
H
m
о
Рис. 1. Структура библиотеки MPICH: темным фоном обозначен интерфейс, светлым - код логического устройства
Fig. 1. MPICH library structure: interface is in the dark background, a logical device code is in the light background
93
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
В верхней части библиотеки находится совместимый со стандартом MPI версии 2.2 интерфейс, предоставляемый прикладным программам. Ниже по уровню располагается логическое устройство, реализующее абстрактный интерфейс устройства (Abstract Device Interface version 3 - ADI3 Interface). Портирование MPICH для определенной коммуникационной среды может заключаться в реализации такого ADI3-устройства (например, на рисунке 1 это CH3 Device). Данный подход позволяет наилучшим образом наложить интерфейс библиотеки на конкретное оборудование, однако процесс разработки и сопровождения полного ADI3 -устройства может быть весьма трудоемким из-за своей сложности и постоянного развития верхнего уровня (поддержка более новых версий MPI может повлечь за собой введение новых или изменение старых функций).
Другой подход заключается в разработке устройства более низкого уровня, взаимодействующего с имеющимся в библиотеке MPICH ADI3 устройством (CH3 Device) по интерфейсу CH3I. Устройства такого уровня называются каналами. Естественно, добавление нового уровня абстракции немного снижает производительность, но разработка и сопровождение такого канала требуют значительно меньше трудовых затрат. Однако практика показала, что разработчики вместо реализации каналов для конкретного оборудования перерабатывали само CH3-устройство. Стало ясно, что интерфейс CH3I не удовлетворял потребностям современных на то время технологий. Отсюда возникла необходимость в создании еще одного слоя абстракции, позволяющего стабилизировать CH3I-интерфейс.
Таким образом, был представлен канал Nemesis для CH3-устройства [9]. Ключевыми особенностями Nemesis являются масштабируемость, высокая производительность для внутриузловых и межузловых обменов, а также поддержка разнородных сетевых каналов передачи. Главные компоненты Nemesis - высокооптимизированная система сообщений для внутриузловых обменов и средства для реализации сетевых модулей (Network Modules -netmod), которые позволили реализовать модули, взаимодействующие с контроллерами Myrinet, Infiniband и Ethernet. Базовой функцией сетевого модуля является передача служебных сообщений и массивов данных через коммуникационную среду.
Рассмотрим процесс разработки стека RapidIO от драйвера контроллера RapidIO до реализации сетевого модуля для Nemesis и обоснуем принятые решения.
Драйвер контроллера RapidIO
Контроллер RapidIO в 1890ВМ6Я реализует следующие механизмы передачи данных стандарта RapidIO: IO-транзакции [10], сообщения и так
называемые дверные звонки (doorbell) [11]. Дверные звонки могут передать максимум 2 байта данных за одну транзакцию. Они предназначены, например, для оповещения о случившемся прерывании, а не для передачи массивов данных.
Использование Ю-транзакций (в частности, NREAD и NWRITE - чтение и запись памяти удаленного узла) возможно путем выполнения процессорных инструкций чтения/записи специальной транслируемой области памяти, которая указывает на память удаленного узла. Каждая такая инструкция может либо загрузить, либо записать данные размером до 8 байт. Если учесть размер служебного заголовка для транзакции (6 байт + 6 бит), то он получается почти равным размеру передаваемых данных, что дает весьма низкую эффективность использования такого рода транзакций в данной реализации контроллера RapidIO.
Сообщения позволяют передавать до 4 Кб данных. Каждое сообщение состоит из сегментов, количество которых может достигать 16, а размер каждого из них не превышает 256 байт. По спецификации RapidIO гарантируются доставка сообщений до места назначения и сохранение порядка передачи с помощью полей «номер письма» (номер сообщения) и «номер сегмента» в заголовке. Оно также имеет дополнительное поле (подкраску) -номер почтового ящика, который служит для разделения входящих потоков сообщений. Таким образом, сообщения являются наиболее приемлемым способом передачи данных ввиду своей высокой эффективности и необходимости наименьшего числа транзакций для данных размером более 8 байт. Далее по тексту под буфером будет пониматься область памяти, разбитая на сообщения либо на отправку, либо на прием.
Контроллер сообщений RapidIO микросхемы 1890ВМ6Я имеет ряд особенностей.
• 8 выделенных очередей, программируемых на прием сообщений от заданного узла с заданным номером почтового ящика. С помощью механизма выделенных очередей становится возможным прием данных напрямую в буфер назначения без промежуточных копирований данных (zero-copy). Такой прием назовем приемом ожидаемого пакета.
• Наличие общей очереди, куда попадают сообщения, не попавшие ни в одну из выделенных очередей. Такие входящие сообщения будем называть неожиданными.
• Проблема сегментов разной длины. По спецификации RapidIO сообщение состоит максимум из 16 сегментов, размер которых одинаков (размер сегмента не больше 256 байт), кроме последнего сегмента. Отправитель посылает сегменты один за другим, одновременно ожидая статуса доставки каждого сегмента от узла получателя. При возникновении заторов в коммуникационной среде любой сегмент может быть отклонен получателем, что приводит к повторной отправке недоставленного
94
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
сегмента. Отсюда возможна следующая ситуация, когда все сегменты, кроме последнего, были отклонены получателем. Тогда этот успешно полученный последний сегмент расположится в памяти по адресу адрес буфера + 256 байт * (количество сегментов - 1). Если же размер всех предыдущих сегментов меньше 256 байт, можно с уверенностью сказать, что произошла порча памяти у получателя в момент записи последнего сегмента, если, конечно, буфер был рассчитан только на прием действительного размера сообщения. В качестве простого решения этой проблемы введем ограничение выравненности размера буферов отправки и приема на 256 байт.
• Физический адрес буфера должен быть выравнен на 8 байт. Из предыдущего требования вытекает требование выравненности адреса буфера, лежащего в транслируемой виртуальной памяти, на 256 байт. Но логика работы контроллера RapidIO микросхемы 1890ВМ6Я при приеме в выделенную очередь заключается в том, что количество отправленных сообщений и размер каждого из них должны точно совпадать с числом и размерами запрограммированных сообщений на стороне получателя. Поэтому для упрощения увеличим требование выравненности для адреса такого буфера до 4Кб.
Для передачи сообщения на уровне прикладной программы, использующей MPI, на первом узле необходимо вызвать функцию передачи MPI_Send, а на другом - функцию приема MPI_Recv. Для MPI_Send задаются параметры: ID получателя, TAG сообщения («подкраска» сообщения), адрес буфера и его размер. Для MPI_Recv должны быть заданы соответствующие параметры, которые либо точно совпадают с параметрами отправки ID и TAG, либо представляют собой особые значения MPI_ANY_SOURCE для ID или MPI_ANY_TAG для TAG, которые пропускают любые соответствующие значения. Такой парный подход вызовов MPI_Send/MPI_Recv для приема/передачи данных позволяет воспользоваться выделенными очередями контроллера RapidIO микросхемы 1890ВМ6Я для приема и последующей отправки в них данных «без копирования». После успешного открытия выделенной очереди информация о номере почтового ящика должна быть передана узлу-отправителю. Для передачи такого рода контрольной информации зарезервируем нулевой почтовый ящик, а остальные номера предоставим выделенным очередям.
Таким образом, можно обозначить три интерфейсные функции нижнего уровня драйвера: отправка пакета (номер почтового ящика передается в параметрах запроса), прием неожиданных сообщений (контрольной информации) и запрос на прием ожидаемых пакетов (запрос на открытие выделенной очереди). Все эти функции должны рабо-
тать с допустимыми (то есть обладающими необходимыми требованиями выравненности, введенными выше) для работы контроллера RapidIO буферами. Для обработки неожиданных сообщений драйвер при инициализации открывает общую очередь.
Управляющий уровень драйвера контроллера RapidIO
Так как число выделенных очередей и почтовых ящиков ограничено, а порядок вызовов MPI функций-запросов на прием, которые могут побудить открытие выделенной очереди, строго говоря, не детерминирован, необходимо осуществлять динамическое присвоение номера почтовому ящику и открытие выделенной очереди для одного определенного узла. Эта работа отнесена на отдельный управляющий уровень. При недостатке свободных очередей или почтовых ящиков запросы на выделенную очередь откладываются до тех пор, пока не станет доступным недостающая часть.
Для приема или передачи буфера без копирования необходимо, чтобы его физический адрес и размер удовлетворяли введенным требованиям вы-равненности. При этом, если буфер находится в транслируемой виртуальной области памяти, осуществляется преобразование виртуального адреса в физические адреса, при необходимости с подкачкой страниц памяти с внешнего носителя. В случае неудовлетворения введенным требованиям выделяется «правильный» связующий буфер (bounce buffer) для обмена данными (либо на прием, либо на передачу) с применением копирования.
Прием в выделенную очередь (прием ожидаемого пакета) происходит только после открытия выделенной очереди и получения контрольной информации о выделенном номере почтового ящика отправителем. Но выделение почтового ящика (которого для данного узла в данный момент может и не быть), открытие выделенной очереди на прием (на данный момент свободной может и не быть) и отправка контрольной информации узлу-отправителю могут занять слишком много времени по отношению к размеру передаваемых данных. Поэтому для данных маленького размера дешевле обойтись общей очередью (нулевой почтовый ящик), используя связующий буфер. Чтобы отличить маленькие данные от контрольной информации, необходимо передавать заголовок с типом данных и их размером вместе с предполагаемыми данными.
Граница между маленькими и большими данными сильно зависит от самой аппаратуры, поэтому устанавливается эмпирическим путем. Если по результатам измерения эта граница расположилась за пределами 4 Кб, то данные маленького размера, превышающие 4 Кб, будут разбиты на не-
95
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
сколько сообщений RapidIO драйвером контроллера. Для последующей обработки таких данных на узле-получателе необходимо их все собрать в единый пакет, что возможно благодаря введенному заголовку.
Таким образом, в управляющем уровне можно выделить следующие интерфейсные функции: отправка данных в общую очередь узла-назначения (маленький размер данных или контрольная информация вместе с заголовком о типе данных и их размере - протокол управляющего уровня); прием неожиданных пакетов, собранных из нескольких сообщений; регистрация буфера (выделение при необходимости связующего буфера или получение физических адресов из транслируемых виртуальных); запрос на открытие выделенной очереди для приема в зарегистрированный буфер; отправка зарегистрированного буфера в заданный почтовый ящик.
В общем случае пользователей управляющего интерфейса может быть несколько. Основная проблема заключается в распознавании пользовате-ля-получателя неожиданных пакетов, так как для ожидаемых пакетов получатель известен по определению. Для ее решения в заголовке неожиданного пакета необходимо передавать идентификатор пользователя-получателя. Для этого введем еще одну интерфейсную функцию-регистрацию пользователя-получателя, которая формирует рабочий контекст, и постулируем работу функций управляющего уровня в рамках этого контекста.
Высшие уровни и тестирование
В числе пользователей канала RapidIO - виртуальное устройство Ethernet (см. рис. 2). Стек Ethernet является базовой необходимостью, так как с его помощью работают многие полезные протоколы, например telnet и ssh. Другим пользователем является уровень MX (см. рис. 2), который реализует интерфейс передачи сообщений по значениям «ключ-маска», в достаточно хорошей степени точности соответствующий интерфейсу передачи сообщений MPI, описанному выше.
Интерфейс Myrinet eXpress [12], использующийся в сетевом модуле mx библиотеки MPICH, также соответствует интерфейсу передачи сообщений MPI. Этот сетевой модуль был взят как справочник при реализации библиотеки пользовательского уровня MXlib, которая реализует интерфейс Myrinet eXpress для работы с ядерным уровнем MX. С этой библиотекой стала возможной работа библиотеки MPICH поверх канала RapidIO через использование сетевого модуля mx.
В качестве аппаратуры для измерения производительности MPI были взяты 4 ПЛИС с ядром микросхемы семейства 1890ВМ6Я, соединенные каналами RapidIO, пиковая пропускная способность которого составляет 192 МБ/с. На одном, двух и четырех узлах были запущены тесты NAS Parallel Benchmarks (NPB) [13] класса А, которые достигли 80 %-ной эффективности масштабирования при увеличении количества узлов. Также была измерена производительность между двумя узлами тестами OSU Micro-Benchmarks [14], результаты которых представлены в таблице.
Результаты измерения производительности стека RapidIO при работе связки MX + MPICH
Measurement results for RapidIO stack performance with operating MX + MPICH
Размер передаваемых данных (байт) Тест
osu bibw (МБ/с) osu bw (МБ/с) osu_latency (мкс)
1 0,00 0,00 699,62
64 0,23 0,19 639,04
512 1,78 1,51 680,80
2048 6,52 5,49 804,26
4096 10,55 8,44 953,26
16384 24,32 18,34 2194,66
65536 59,35 49,56 3906,18
131072 72,78 67,65 7441,22
524288 112,04 81,08 31151,76
4194304 219,03 162,00 219750,74
На основании изложенного можно сделать следующие выводы. Реализованный в данной статье стек RapidIO для MPI показал свою работоспособность на различных программах - тесты NAS Parallel Benchmarks, OSU Micro-Benchmarks, тесты MPICH. На тесте передачи сообщений OSU удалось достичь скорости передачи в 84 % от пиковой. Благодаря расширению области тестирования путем запуска разнообразных MPI-программ были выявлены и устранены ранее неизвестные ошибки в логике работы контроллера RapidIO.
При использовании готовых библиотек добиться максимальной производительности можно только на аппаратуре, функциональные возможности которой соответствуют идеологии обмена данными, заложенной в самой библиотеке. В целом контроллер RapidIO микросхемы 1890ВМ6Я лишь частично соответствует стандарту MPI, а соответственно, и его библиотечным реализациям. Так,
96
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
например, для передачи большого массива данных необходимо произвести «ручное» программирование каждого сообщения в соответствии с таблицей физических адресов, в то время как такая тривиальная работа может быть реализована в железе. Необходимость разрешения конфликтов выравненности буферов на обоих узлах также влечет дополнительные накладные расходы на процессор, в худшем случае прибегая к копированию данных.
Другим примером является введенный в стандарт MPI версии 2 интерфейс RMA (Remote Memory Access), который позволяет совершать операции чтения и записи памяти любого размера удаленного узла. Микросхема 1890ВМ6Я предоставляет весьма скудный механизм такого удаленного доступа к памяти - IO-транзакции типа NREAD и NWRITE с полезной нагрузкой до 8 байт, хотя по стандарту RapidIO полезная нагрузка может составлять 256 байт.
Недостатком является и получившаяся сильная перегруженность стека драйверов, что делает отправку и прием данных слишком дорогой операцией. По грубым оценкам, получилось больше 20 тысяч процессорных инструкций для передачи всего лишь одного байта данных. Это означает, что при частоте процессора в 1 ГГц передать один байт получится не меньше, чем через несколько десятков микросекунд. Конечно, с ростом передаваемого объема данных сама подготовка к передаче будет становиться исчезающе малой, но факт задержки, тем не менее, останется. Поэтому необходима дальнейшая работа по ее уменьшению.
Автор выражает благодарность Лазутину Юрию Михайловичу (ФНЦ НИИСИ РАН) за помощь в подготовке данной статьи.
Литература
1. Message Passing Interface Forum. MPI: A message-passing interface standard, version 3.0, 2012. URL: http://www.mpi-
forum.org/docs/mpi-3.0/mpi30-report.pdf (дата обращения:
25.07.2015) .
2. Бобков С.Г., Еремин А.А., Кондратьева Н.В., Сер-дин О.В. Разработка высоконадежных многопроцессорных модулей на базе высокоскоростных каналов RapidIO // Программные продукты и системы. 2013. № 4. С. 49-55.
3. Yang C., Xiao L., Lu Yu., Liao X. MilkyWay-2 supercomputer: system and application. Front. Comput. Sci., 2014, no. 8 (3), pp. 345-356.
4. Graham R.L., Gutierrez S.K., Hjelm N.T., Venkata M.G. Performance Evaluation of Open MPI on Cray XE/XK Systems. High-Performance Interconnects (HOTI), 2012 IEEE 20 th Annual Symposium, 22-24 Aug. 2012, pp. 40-47.
5. Sato M., Tsuji M. / Performance Evaluation of OpenMP and MPI Hybrid Programs on a Large Scale Multi-core Multi-socket Cluster, T2K Open Supercomputer. Parallel Processing Workshops, 2009. ICPPW '09. Intern. Conf, 22-25 Sept. 2009, pp. 206-213.
6. MPICH is a high performance and widely portable implementation of the Message Passing Interface (MPI) standard. URL: https://www.mpich.org/ (дата обращения: 25.07.2015).
7. Архитектура библиотеки MPICH первой версии. URL: http://www.mcs.anl.gov/research/projects/mpi/mpich1-old/papers/ mpicharticle/node21.html#Node21 (дата обращения: 25.07.2015).
8. Pritchard H., Gorodetsky I., Buntinas D. A uGNI-Based MPICH2 Nemesis Network Module for Cray XE Computer Systems. EuroMPI'11 Proceedings of the 18th European MPI Users' Group conference on Recent advances in the message passing interface, pp. 110-119.
9. Buntinas D., Mercier G., and Gropp W. Design and Evaluation of Nemesis, a Scalable, Low-Latency, Message-Passing Communication Subsystem. In CCGRID’06, 2006, pp. 521-530.
10. RapidIO Interconnect Specification. Part 1: Input/Output Logical Specification. Revision 2.2. RapidIO Trade Association, 2011. URL: http://www.rapidio.org/specs/current/Ra-pidIO_ Rev_ 2.2_Specification.zip (дата обращения: 25.07.2015).
11. RapidIO Interconnect Specification. Part 2: Messsage Passing Logical Specification. Revision 2.2. RapidIO Trade Association, 2011. URL: http://www.rapidio.org/specs/current/RapidIO_Rev_ 2.2_Specification.zip (дата обращения: 25.07.2015).
12. Myricom, Inc. Myrinet Express (MX): A High Performance, Low-Level, Message-Passing Interface for Myrinet. URL: http://www.myri.com/scs/MX/doc/mx.pdf (дата обращения:
25.07.2015) .
13. NAS Parallel Benchmarks: небольшой набор программ, созданных для помощи в оценке производительности параллельных суперкомпьютеров. URL: http://www.nas.nasa.gov/pub-lications/npb.html (дата обращения: 25.07.2015).
14. OSU Micro-Benchmarks: тесты производительности вычислительных узлов с использованием MPI. URL: http://mvapi-ch.cse.ohio-state.edu/benchmarks/ (дата обращения: 25.07.2015).
DOI: 10.15827/0236-235X.112.093-098 Received 27.07.15
MPI SUPPORT IN LINUX OS FOR RapidlO-BASED MULTIPROCESSOR COMPUTER SYSTEMS Kuleshov A.S., Postgraduate Student, rndfax@cs.niisi.ras.ru (SRISA RAS, Nakhimovsky Av. 36/1, Moscow, 117218, Russia Federation)
Abstract. Solving calculus problems using multiprocessor computing systems refers to a certain data transfer programming interface. The most well-known interface is the message passing interface (MPI), which defines the standard of API functions to transfer data between nodes for end-user programs. This paper presents MPI implementation for SoC 1890VM6IA developed in SRISA RAS. It is a base for multipurpose multiprocessor computing systems, nodes of which can be connected through high speed RapidIO channels. To implement it we took MPICH, which is the most widespread library of MPI, and Linux kernel that proved itself as the best solution for supercomputing. MPICH basic configuration includes different network modules, which implement API for specific transport drivers: tcp (Ethernet TCP/IP), ib (Infiniband), mx (Myrinet eXpress) and others. Using network module mx, which is well-fitting for RapidIO architecture, gave the opportunity to focus only on the development of the Linux driver for RapidIO controller. The features of RapidIO controller of 1890VM6IA, MPI interface and the idea of using RapidIO channel for purposes other than MPI in Linux, allowed implementing a message passing stack with the some degree of universality using RapidIO channel without unnecessary data copying. In the end of the paper there are the results of different MPI test programs
97
Программные продукты и системы /Software & Systems
№ 4 (112), 2015
such as NAS Parallel Benchmarks and OSU Micro-Benchmarks for 4 nodes using the RapidIO channels. The author made a conclusion and summarized the results using RapidIO controller of 1890VM6IA SoC as a transport facility for MPI.
Keywords: RapidIO, MPI, MPICH, Linux.
References
1. Message Passing Interface Forum. MPI: A message-passing interface standard, version 3.0. 2012. Available at: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf (accessed July 25, 2015).
2. Bobkov S.G., Eremin A.A., Kondrateva N.V., Serdin O.V. Design of high reliability multiprocessor modules based on high-performance RapidIO interconnect architecture. Programmnyeprodukty i sistemy [Software & Systems].
2013, no. 4, pp. 49-55 (in Russ.).
3. Yang C., Xiao L., Lu Yu., Liao X. MilkyWay-2 supercomputer: system and application. Front. Comput. Sci.
2014, no. 8 (3), pp. 345-356.
4. Graham R.L., Gutierrez S.K., Hjelm N.T., Venkata M.G. Performance Evaluation of Open MPI on Cray XE/XK Systems. IEEE 20th Annual Symp. on High-Performance Interconnects (HOTI). 2012, pp. 40-47.
5. Sato M., Tsuji M. Performance Evaluation of OpenMP and MPI Hybrid Programs on a Large Scale Multi-core Multi-socket Cluster, T2K Open Supercomputer. ICPPW '09. Int. Conf. on Parallel Processing Workshops. 2009, pp. 206-213.
6. MPICH is a high performance and widely portable implementation of the Message Passing Interface (MPI) standard. Available at: https://www.mpich.org (accessed July 25, 2015).
7. Arkhitektura biblioteki MPICH pervoy versii [MPICH library architecture, the 1st vrsion]. Available at: http://www.mcs.anl.gov/research/projects/mpi/mpich1-old/papers/mpicharticle/node21.html#Node21 (accessed July 25, 2015).
8. Pritchard H., Gorodetsky I. A uGNI-Based MPICH2 Nemesis Network Module for Cray XE Computer Systems. Proc. of the 18th European MPI Users' Group Conf. on Recent Advances in the Message Passing Interface. 2011, pp. 110-119.
9. Buntinas D., Mercier G., Gropp W. Design and Evaluation of Nemesis, a Scalable, Low-Latency, MessagePassing Communication Subsystem. CCGRPD’06. 2006, pp. 521-530.
10. RapidIO Interconnect Specification. Part 1: Input/Output Logical Specification. Revision 2.2. RapidIO Trade Association. 2011. Available at: http://www.rapidio.org/specs/current/Ra-pidIO_ Rev_ 2.2_Specification.zip (accessed July 25, 2015).
11. RapidIO Interconnect Specification. Part 2: Messsage Passing Logical Specification. Revision 2.2. RapidIO Trade Association. 2011. Available at: http://www.rapidio.org/specs/current/Ra-pidIO_ Rev_ 2.2_Specification.zip (accessed July 25, 2015).
12. Myricom, Inc. Myrinet Express (MX): A High Performance, Low-Level, Message-Passing Interface for Myrinet. Available at: http://www.myri.com/scs/MX/doc/mx.pdf (accessed July 25, 2015).
13. NAS Parallel Benchmarks. Available at: http://www.nas.nasa.gov/publications/npb.html (accessed July 25, 2015).
14. MVAPICH: MPI over InfiniBand, 10GigE/iWARP and RoCE. Available at: http://mvapich.cse.ohio-state.edu/benchmarks/ (accessed July 25, 2015).
Примеры оформления статьи в списке литературы
1. Кулешов А.С. Поддержка протокола MPI в ядре ОС Linux для многопроцессорных вычислительных комплексов на базе высокоскоростных каналов RapidIO // Программные продукты и системы. 2015. № 4 (112). С. 93-98.
2. Кулешов А.С. Поддержка протокола MPI в ядре ОС Linux для многопроцессорных вычислительных комплексов на базе высокоскоростных каналов RapidIO // Программные продукты и системы. 2015; DOI: 10.15827/0236-235X.112.093-098.
3. Kuleshov A.S. MPI support in Linux OS for RapidIO-based multiprocessor computer systems. Programmnye produkty i sistemy [Software & Systems]. 2015, no. 4 (112), pp. 93-98 (in Russ.); DOI: 10.15827/0236-235X.112.093-098.
98
