Полный вариант стандарта  (и всех предыдущих) в формате pdf можно скачать тут:
http://www.mpi-forum.org/docs/docs.html

Но более интересным представляется MPI-3,  предложения, обсуждаемые комитетом, можно увидеть здесь: http://meetings.mpi-forum.org/MPI_3.0_main_page.php

Для меня наиболее интересным расширением оказались так называемые Persistent Operations, позволяющие закэшировать соединения для коллективной операции и исключить оверхед при повторном использовании.

Хочу поделится с обществом найденной интересной программой.
Скачать ее можно с Sourceforge: http://sourceforge.net/projects/mpigraph. Программа прогоняет пинг-понг тест между всеми ранками по принципу каждый-с-каждым, распараллеливая значительную часть работы. В результате работы получается сводная таблица с намерянными скоростями между ранками.
Кроме того в пакете идет перловый скрипт, который позволяет сделать из текстовой таблички, совершенно не читаемой при количестве обмерянных нод >10, картинку в градациях серого. Каждый пиксель на которой представляет ту же таблицу, чем ярче цвет тем больше скорость, черный цвет – обрыв линка. Получаем примерно такую картинку на больном кластере:

Визуально получается интересно, а чтобы выяснить где именно проседает Bandwidth скрипт генерирует еще и html файл со скриптами. При наведении мышкой на картинку выскакивает всплывающая подсказка с объяснением на какой именно пиксель вы “наехали” – с какого ранка была передача и на какой. Вообщем это уже можно использовать для диагонстики неполадок сети.
Попутно у меня возникла идея о снятии серии таких картинок, и дальнейшего микширования в короткий ролик. Тогда на ролике случайные провисания линков будут видны как шум, а имеющие место проблемы – постоянными пятнами. Пока что я попробую снять 250 кадров-замеров для 10-секундного ролика. На 64-х нодах это потребует примерно 10*250  примерно 2500 секунд

В общем работает быстрее 2.1.5 где-то на 20-30%, точные цифры опубликовать к сожалению не могу.

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

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

а) Все процессоры имеют равноправный доступ к памяти. Память равноудалена от всех процессоров. Это так называемые SMP (Symmetric Multi-Processing), симметричные процессорные системы.

Как видно из иллюстрации все процессоры связаны с общей памяти через FSB (Front Side Bus). Эта же шина и является узким местом такой архитектуры, поскольку ее пропускная способность должна удовлетворять запросы каждого процессора, даже если они поступают одновременно.

б) Каждый процессор имеет свою локальную память и более затратный доступ к памяти других процессоров. Это NUMA системы, или системы с неодинаковым доступом к памяти.
В NUMA cистемах каждый процессор имеет локальную память и при правильной привязке процессов к процессорам всегда используется “ближняя” память. Доступ же в дальную память, с соответствующим пенальти происходит только при коммуникации процессов. Если привязки процессов нет, то в результате так называемой “миграции”, процесс может быть запущен на другом процессоре и работать со своими данными из дальней памяти.
Общая проблема NUMA систем – большое количество линков, возрастающее при увеличении числа процессоров. Для двухпроцессорной NUMA cистемы достаточно одного линка между процессорами:

При добавлении процессоров получается более сложная организация:

Можете представить, что будет для системы с восемью процессорами. Это будет похоже на паутину С давних времен сложилось так что Intel продвигает SMP системы на рынке, а AMD – NUMA. В случае Intel-a связь между процессорами сделана на основе QPI, соответственно для AMD это HyperTransport. Фактически при использовании SMP систем каких-то дополнительных сложностей нет. Все процессоры равны и даже миграция (теряется кэш) не сильно влияет на производительность. В случае NUMA уже порой приходится задумываться о привязке процессов/потоков к определенному процессору (или к любому но намертво).

Следущий шаг усложнения кластеры. Кластер – это набор узлов, обединенных сетью. Узлы могут быть одинаковые (гомогенные кластеры) или разные (гетерогенные кластеры). Обычно кластер имеет как минимум одну головную ноду (head node) и отдельные узлы для файловой системы. Собственно каждый узел (computation node, нода) внутри может быть небольшой SMP или NUMA системой. В этом нет ничего страшного, практически так стоятся все современные суперкомпьютеры, и есть тенденция к увеличению количества процессоров в одной ноде. Между собой ноды связаны сетью, применяется как Gigabit Ethernet (GigE) или более быстрые сети Infiniband (Mellanox, QLogic), Myrinet или другие пропиетарные интерконнекты и сети. Основные два условия к ПО кластера – обеспечить общий диск между узлами (shared space) и службу удаленного запуска приложений (это может быть telnet, ssh, rshell и т.п). От размера кластера главным образом зависит то, каким будет топология его сети. Небольшие по размеру кластера могут строиться на одном-двух свичах, а для связывания больших кластеров свичи объединяются в несколько уровней. Например, простой вариант, когда количество узловменьше или равно количеству портов у свича:

Так строится одна стойка кластера. На рисунке показана только вычислительная сеть. В случае объединения двух стоек, можно воспользоваться одним из портов свича для создания связи свич-свич.

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

Обычно для крупных систем хватает два уровня. Свичи делятся на Leaf и Spine. Узлы подключаются только к Leaf. Все Leaf связаны между собой через Spine. Вот пример топологии 256-нодового кластера с Infiniband свичем CISCO:

Квадратами обозначаются ноды (по 12 шт в одном квадрате). Эти 12 шт подключены к одному листу (Leaf-у), который в свою очередь соединяется с 12-ю Spine. Такой кластер обеспечивает запуск задачи одновременно на 2048 ядрах или 256 нодах при довольно интенсивном межузловом обмене.

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

Свич установлен в дальней стойке сверху. Сверху вниз стойка заполнена нодами. Внизу каждой стойки установлен источник бесперебойного питания. В центральной части установлена login-node и скорее всего синего цвета ноды файловой системы.
Так выглядит серверная комната в яндексе:

Это скорее всего кластер кластеров установленный в одном помещении.

1. Threads / Processes
2. OpenMP
3. MPI

Исторически сложилось так, что наиболее часто применяемый способ – это Threads в их различных реинкарнациях. Способ хорош тем что не требует дополнительных библиотек. Чтобы использовать этот вариант, достаточно имеющихся возможностей OC. Обычно используется для скрытия от пользователя различных продолжительных операций, чтобы не терять возможность отрисовки GUI в момент ожидания операции. Основное достоинство – потоки разделяют адресное пространства и принадлежат одному процессу. Поэтому все передачи данных между потоками выполняются максимально быстро. Чаще всего достаточно передать указатель. Синхронизация потоков не затратна и не требует системных вызовов (Syscall) – долгих операций с переключением контекста. Сюда же можно отнести и многопроцессные программы в самом простейшем виде – использующие fork() или что-то подобное из системных функций для порождения нового процесса, но применяющее для синхронизации и обмена данными системное API.
Для более простого распараллеливания уже существующего кода был придуман OpenMP. Больщинство работы по распараллеливанию и синхронизации здесь переложена на компилятор и его библиотеки. Для распараллеливания достаточно разместить определенные прагмы (#pragma …) в коде программы. Набор этих прагм описан в стандарте. Плюс такого подхода – легкость обретения параллелизма программой. Недостатки – требуется специальный компилятор, низкий уровень параллельности, необходимость следования навязываемой парадигме.

MPI (Message Passing Interface). Эта библиотека, как следует из названия не предназначена для какого либо распараллеливания, однако ее чаще всего применяют для написания параллельных программ на больших кластерах. Именно для написания, так как для применения MPI плохо подходит вариант “напишем последовательный код, а потом распараллелим”. В варианте с MPI программа сразу представляет собой N процессов. Это N фиксировано и задается параметром при запуске приложения. Т.е. это полный параллелизм, а библиотека предоставляет примитивы для синхронизации и обмена данными. К плюсам применения MPI относят высокую масштабируемость решения, высокий уровень параллельности и отличная портабельность кода. Основные минусы – сложности при программировании, относительно высокие затраты на синхронизацию и обмен данными.

Кроме основных трех способов существуют еще и другие малоизвестные, малоприменимые и/или устаревшие. Такие как GlobalArrays – распределенные структуры данных со скрытым доступом к элементам, PVM – прародитель MPI… Может еще чего есть – напишите мне, если знаете

Как это выглядит

Здесь я минимально приведу код, чтобы его можно было охватить глазами. Объяснять как это работает здесь смысла нет, для этого будут отдельные темы.

1. Создание двух процессов вызовом fork():

int main(){
...
pid = fork();
if (pid == 0) {
// код потомка
else{
// код родителя}
...}

2. Использование прагм openmp()

 int main(){
...
#pragma parallel for
for (int i=0; i<MaxI; i++)// Параллельный цикл
...

}

3. Использование MPI

int main(int* argc, char ** argv){//код идет параллельно начиная с ф-ции main()
//Обязательный пролог - инициализация MPI
MPI_Init(int* argc, char ** argv);
MPI_Comm_size(&np);
MPI_Comm_rank(&myrank);
printf("I'm process %i, from %i total", myrank, np);
//обязательный эпилог
MPI_Finalize();
}