2008-09-27 9 views
22

Мне нужно реализовать MPI-систему в кластере. Если у кого-нибудь есть опыт работы с MPI (MPICH/OpenMPI), я хотел бы знать, что лучше и как повысить производительность в кластере из x86_64.Какая лучшая реализация MPI

ответ

18

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

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

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

+1

Поддержка отказоустойчивости MPICH2 в последнее время значительно улучшилась. Если вы заинтересованы в использовании этой поддержки, вы можете узнать больше об этом, отправив список MPICH2 ([email protected]). – 2011-03-01 15:26:11

+0

Каким образом можно узнать, какая версия MPI используется данным сервером? Я запускаю python binding mpi4py, но вам нужно знать, что такое базовая версия MPI? – 218 2016-03-22 16:18:25

-1

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

9

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

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

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

Ознакомьтесь с форумами MPI - у них есть много хороших info about MPI routines, а на сайте Beowulf есть много интересных вопросов.

2

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

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

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

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

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