Какие функции нужны пользователям от интерфейса MPI C ++?

Версия стандарта MPI 3.0 формально удалила интерфейс C ++ (ранее он был устаревшим). Хотя реализации все еще могут поддерживать его, новые функции в MPI-3 не имеют интерфейса C ++, определенного в стандарте MPI. См. Http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ для получения дополнительной информации.

Мотивация для удаления интерфейса C ++ из MPI заключалась в том, что он не имел существенного значения по сравнению с интерфейсом C. Было очень мало различий, кроме «s / _ / :: / g», и многие функции, к которым привыкли пользователи C ++, не использовались (например, автоматическое определение типа с помощью шаблонов).

Как человек, который участвует в форуме MPI и работает с рядом проектов C ++, в которых реализован собственный интерфейс C ++ для функций MPI C, я хотел бы знать, каковы желательные особенности интерфейса C ++ для MPI. Несмотря на то, что я ни к чему не привержен, мне было бы интересно увидеть реализацию автономного интерфейса MPI C ++, который отвечает потребностям многих пользователей.

И да, я знаком с Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ), но он поддерживает только функции MPI-1, и модель сериализации будет крайне сложно поддерживать RMA.

Один интерфейс C ++ к MPI, который мне нравится, это Elemental ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ), так что, возможно, люди могут предоставить некоторые за и против, что подходить. В частности, я думаю, что MpiMap решает существенную проблему.

Позвольте мне сначала ответить, почему я думаю, что интерфейсы C ++ к MPI, как правило, не были слишком успешными, долго думая об этой проблеме, пытаясь решить, следует ли нам просто использовать стандартные привязки C MPI или строить что-то на более высоком уровне. :

Когда вы смотрите на реальные коды MPI (скажем, PETSc, или в моем случае. II), можно обнаружить, что, возможно, удивительно, что количество вызовов MPI на самом деле не очень велико. Например, в 500 000 строк сделки. II, всего около 100 вызовов MPI. Следствием этого является то, что боль, связанная с использованием низкоуровневых интерфейсов, таких как привязки MPI C, не слишком велика. И наоборот, нельзя было бы получить все это с помощью интерфейсов более высокого уровня.

Мое второе замечание заключается в том, что во многих системах установлено несколько библиотек MPI (разные реализации MPI или разные версии). Это создает значительную трудность, если вы хотите использовать, скажем, boost :: mpi, который не просто состоит из заголовочных файлов: либо необходимо несколько установок этого пакета, либо нужно собрать его как часть проект, который использует boost :: mpi (но это опять проблема сама по себе, учитывая, что boost использует собственную систему сборки, которая не похожа ни на что другое).

Так что я думаю, что все это совпало с текущим набором интерфейсов C ++ к MPI: старые привязки MPI C ++ не давали никаких преимуществ, а внешние пакеты испытывали трудности с реальным миром.

Это все, что я думаю, вот что я хотел бы получить от убойного интерфейса, который я хотел бы получить от интерфейса более высокого уровня:

• Это должно быть универсальным. Необходимость указания типа данных для переменной явно не похожа на C ++. Конечно, это также приводит к ошибкам. Класс MpiMap от Elemental уже был бы хорошим первым шагом (хотя я не могу понять, почему, черт возьми, MpiMap::typeпеременная не является статической константой, так что к ней можно получить доступ без создания объекта).

• Он должен иметь возможности для потоковой передачи произвольных типов данных.

• Операции, которые требуют MPI_Opаргумента (например, сокращения), должны хорошо интегрироваться с std::functionинтерфейсом C ++ , так что легко просто передать указатель на функцию (или лямбду!) Вместо того, чтобы неуклюже регистрировать что-то.

boost :: mpi на самом деле удовлетворяет всем этим. Я думаю, что если бы это была библиотека только для заголовков, она была бы намного более популярной на практике. Также было бы полезно, если бы он поддерживал функции после MPI 1.0, но давайте будем честными: это покрывает большую часть того, что нам нужно большую часть времени.

Чтобы начать движение, вот две мои потребности:

• Интерфейс должен быть в состоянии устранить избыточные или ненужные аргументы, например, MPI_IN_PLACE.
• Интерфейс должен автоматически обнаруживать встроенные типы данных аля Elemental's MpiMap.
• Если / когда это возможно, определяемые пользователем типы данных должны создаваться для классов.

Мой список в произвольном порядке предпочтений. Интерфейс должен:

• быть только заголовком, без каких-либо зависимостей, но <mpi.h>и стандартной библиотеки,
• быть универсальным и расширяемым,
• быть неблокирующим только (если вы хотите заблокировать, то блокируйте явно, не по умолчанию),
• разрешить основанную на продолжении цепочку неблокирующих операций,
• поддерживать расширяемую и эффективную сериализацию (например, Boost.Fusion, которая работает с RMA),
• иметь нулевой штраф за абстракцию (т. е. быть по крайней мере так же быстро, как интерфейс C),
• быть в безопасности (деструктор неготового будущего называется? -> std :: terminate!),
• иметь сильный DEBUGрежим с тоннами утверждений,
• чрезвычайно безопасный для типов (больше никаких ints / void * для всего, черт возьми, я хочу, чтобы теги были типами!),
• он должен работать с лямбдами (например, все уменьшить + лямбда),
• последовательно использовать исключения в качестве механизма сообщения об ошибках и обработки ошибок (больше нет кодов ошибок! больше нет аргументов вывода функции!),
• MPI-IO должен предлагать неблокирующий интерфейс ввода-вывода в стиле Boost.AFIO,
• и просто следуйте хорошим современным практикам проектирования интерфейса C ++ (определяйте обычные типы, функции, не являющиеся членами, не являющимися друзьями, хорошо работайте с семантикой перемещения, операциями с диапазоном поддержки, ...)

Дополнительно:

• Позвольте мне выбрать исполнителя среды MPI, то есть, какой пул потоков он использует. Прямо сейчас у вас могут быть приложения с сочетанием OpenMP, MPI, CUDA и TBB ... все в одно и то же время, когда каждая среда выполнения думает, что она владеет средой, и, таким образом, запрашивает у операционной системы потоки каждый раз, когда им хочется Это. Шутки в сторону?

• используйте соглашение об именах STL (и Boost). Зачем? Каждый программист C ++ знает это.

Я хочу написать код так:

auto buffer = some_t{no_ranks};
auto future = gather(comm, root(comm), my_offsets, buffer)
              .then([&](){
                /* when the gather is finished, this lambda will 
                   execute at the root node, and perform an expensive operation
                   there asynchronously (compute data required for load 
                   redistribution) whose result is broadcasted to the rest 
                   of the communicator */
                return broadcast(comm, root(comm), buffer);
              }).then([&]() {
                /* when broadcast is finished, this lambda executes 
                   on all processes in the communicator, performing an expensive
                   operation asynchronously (redistribute the load, 
                   maybe using non-blocking point-to-point communication) */
                 return do_something_with(buffer);
              }).then([&](auto result) {
                 /* finally perform a reduction on the result to check
                    everything went fine */
                 return all_reduce(comm, root(comm), result, 
                                  [](auto acc, auto v) { return acc && v; }); 
              }).then([&](auto result) {
                  /* check the result at every process */
                  if (result) { return; /* we are done */ }
                  else {
                    root_only([](){ write_some_error_log(); });
                    throw some_exception;
                  }
              });

/* Here nothing has happened yet! */

/* ... lots and lots of unrelated code that can execute concurrently 
   and overlaps with communication ... */

/* When we now call future.get() we will block 
   on the whole chain (which might have finished by then!).
*/

future.get();

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

Лично я не против вызывать длинные функции в стиле C по той причине, о которой говорил Вольфганг; на самом деле есть несколько мест, где вам нужно их вызвать, и даже тогда они почти всегда оборачиваются каким-то кодом более высокого уровня.

Единственное, что действительно беспокоит меня в MPI в стиле C, это пользовательские типы данных и, в меньшей степени, пользовательские операции (потому что я использую их реже). Что касается пользовательских типов данных, я бы сказал, что хороший интерфейс C ++ должен поддерживать общий и эффективный способ обработки этого, скорее всего, через сериализацию. Это, конечно, пройденный маршрут boost.mpi, который, если вы будете осторожны , поможет вам сэкономить много времени.

Что касается boost.mpiналичия дополнительных зависимостей (в частности, boost.serializationкоторые сами по себе не только для заголовков), я недавно натолкнулся на библиотеку сериализации C ++ только для заголовков, называемую cereal, которая кажется многообещающей; Разумеется, требуется компилятор, совместимый с C ++ 11. Возможно, стоит изучить и использовать его как основу для чего-то похожего boost.mpi.

Проект github easyLambda предоставляет высокоуровневый интерфейс для MPI с C ++ 14.

Я думаю, что у проекта аналогичные цели, и он даст некоторое представление о том, что можно и нужно сделать в этой области с использованием современного C ++. Руководствуясь другими усилиями, а также самой easyLambda.

Начальные тесты производительности и строки кода показали многообещающие результаты.

Ниже приведено краткое описание функций и интерфейса, который он предоставляет.

Интерфейс основан на программировании потока данных и операциях со списком функций, которые обеспечивают присущий параллелизм. Параллелизм выражается как свойство задачи. Распределение процесса и распределение данных для задачи можно запросить с помощью свойства .prll (). На веб-странице и в хранилище кодов имеется множество примеров , включающих в себя пост-обработку молекулярной динамики LAMMPS, явное конечно-разностное решение уравнения теплопроводности, логистическую регрессию и т. Д. В качестве примера обсуждается проблема диффузии тепла, рассмотренная в статье HPC ... может быть выражено в ~ 20 строк кода.

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

Отказ от ответственности: я автор библиотеки. Я полагаю, что я не причинил никакого вреда в надежде получить конструктивную обратную связь о текущем интерфейсе easyLambda, который может быть выгоден easyLambda и любому другому проекту, преследующему аналогичные цели.