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

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

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

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

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

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

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

Посетите форумы MPI - на них есть много хорошей информации о подпрограммах MPI, а также На сайте Beowulf есть ответы на множество интересных вопросов.

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

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

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

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

Разделение трафика ввода-вывода и MPI может иметь большое значение для некоторых кластеров, особенно для кластеров Gigabit Ethernet.

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