Какая лучшая реализация MPI

Ответ 1

MPICH работает намного дольше. Он чрезвычайно портативен, и вы найдете в Интернете много советов и подсказок. Это безопасная ставка, и она, вероятно, совместима с другими программами MPI.

OpenMPI новее. Хотя он не совсем портативен, он очень хорошо поддерживает наиболее распространенные платформы. Большинство людей, похоже, считают это намного лучше в нескольких отношениях, особенно для отказоустойчивости, но, чтобы воспользоваться этим, вам, возможно, придется использовать некоторые из его специальных функций, которые не являются частью стандарта MPI.

Что касается производительности, это сильно зависит от приложения; трудно дать общий совет. Вы должны указать конкретный вопрос о типе вычисления, которое вы хотите запустить, о числе узлов и типе оборудования, включая тип используемого вами сетевого оборудования.

Ответ 2

Я написал довольно много параллельных приложений для кластеров Windows и Linux, и я могу посоветовать вам, что сейчас MPICH2, вероятно, является более безопасным выбором. Это, как упоминает другой ответчик, очень зрелая библиотека. Кроме того, есть широкая поддержка вещания (через MPI_Bcast), и на самом деле у MPICH2 есть довольно много действительно хороших функций, таких как разброс и сбор.

OpenMPI набирает силу. Penguin computing (они большой поставщик кластера, и они любят Linux) на самом деле имеют некоторые действительно сильные тесты, в которых OpenMPI превосходит MPICH2 в определенных обстоятельствах.

Что касается вашего комментария о "повышении производительности", лучший совет, который я могу дать, - никогда не отправлять больше данных, чем это абсолютно необходимо, если вы связаны с I/O и никогда не делаете больше работы, чем необходимо, если вы являетесь центральным процессором связаны. Я попал в ловушку для оптимизации неправильной части кода более одного раза:) Надеюсь, вы не пойдете по моим стопам!

Ознакомьтесь с форумами MPI - у них много хорошего информация о процедурах MPI и Beowulf есть много интересных вопросов.

Ответ 3

"Лучше" сложно определить... "Быстрее" можно ответить, сравнив его с вашим кодом и вашим оборудованием. Такие вещи, как коллективная и разгрузочная оптимизация, будут зависеть от вашего точного оборудования и также весьма различны в отношении версий стека драйверов, Google должен уметь находить ваши рабочие комбинации.

Что касается работы по оптимизации, это в некоторой степени зависит от кода и отчасти от аппаратного обеспечения.

Является ли ваш код ввода-вывода привязанным к хранилищу? В этом случае расследование может быть намного лучше, чем NFS, или использование ввода/вывода MPI, а не наивного параллельного ввода/вывода

Если вы привязаны к сети, посмотрите на локальность общения и скомпоновать взаимосвязи/вычисление. Большинство различных реализаций MPI имеют параметры настройки для использования локальной общей памяти, а не сети для сообщений внутри сети, что для некоторых кодов может значительно снизить нагрузку на сеть.

Сегментация трафика ввода-вывода и MPI может иметь большое значение для некоторых кластеров, особенно для кластеров ethernet-сетей.

Ответ 4

Мы использовали mpich просто потому, что он казался наиболее доступным и наиболее документированным, мы не прилагали больших усилий для тестирования альтернатив. MPICH имеет разумные инструменты для развертывания в Windows.
Основная проблема с производительностью была в том, что нам нужно было отправлять одни и те же базовые данные всем узлам, а MPICH не поддерживал (или не поддерживал) широковещательную рассылку - поэтому развертывание исходных данных было O (n)