MPI или сокеты?

Question

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

Мой вопрос задан так. Все традиционные и серьезные приложения HPC, выполняемые в кластерах, обычно реализуются с передачей сообщений вместо прямой отправки через сокеты. Каковы преимущества производительности для этого? Должны ли мы увидеть ускорение, если мы переключились с сокетов?

Answer 1

MPI МОЖЕТ использовать розетки. Но есть также реализация MPI, которая будет использоваться с SAN (Системная сеть), которая использует прямую распределенную совместно используемую память. Это, конечно, если у вас есть оборудование для этого. Таким образом, MPI позволяет использовать такие ресурсы в будущем. В этом случае вы можете добиться значительного улучшения производительности (на моем опыте работы с кластерами еще во время обучения в университете вы можете получить выгоды на несколько порядков). Так что, если вы пишете код, который можно перенести в кластеры более высокого уровня, использовать MPI - очень хорошая идея.

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

Answer 2

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

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

Answer 3

Производительность - не единственное соображение в этом случае, даже на высокопроизводительных кластерах. MPI предлагает стандартный API и является «переносимым». Относительно тривиально переключать приложение между различными версиями MPI.

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

Кроме того, если у вас когда-нибудь появится возможность запустить код в кластере с InfiniBand, уровень MPI будет абстрагировать любое из этих изменений кода. Это не тривиальное преимущество - кодирование приложения для непосредственного использования реализации OFED (или другого глагола IB) очень сложно.

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

Answer 4

MPI имеет то преимущество, что вы можете делать коллективные коммуникации. Выполнение широковещательной рассылки / сокращения O (log p) / * p - это количество процессоров * / вместо O (p) - большое преимущество.

Answer 5

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

Как связан ваш ввод / вывод? Это связано с передачей блоков данных на рабочие узлы, или это связано из-за связи во время вычислений?

Если ответ «из-за связи», то проблема в том, что вы пишете тесно связанное приложение и пытаетесь запустить его в кластере, предназначенном для слабо связанных задач. Единственный способ повысить производительность - это получить более качественное оборудование (более быстрые коммутаторы, инфинити и т. Д.) ... может быть, вы могли бы занять время на чужом HPC?

Если ответом является «передача блоков данных», рассмотрите возможность назначения работникам нескольких блоков данных (чтобы они дольше оставались занятыми) и сожмите блоки данных перед передачей. Это стратегия, которая может помочь в слабо связанных приложениях.

Answer 6

Я должен согласиться со OldMan и freespace. Если вы не знаете о конкретном и улучшении какого-либо полезного показателя (производительности, ремонтопригодности и т. Д.) По сравнению с MPI, зачем изобретать велосипед. MPI представляет собой большой объем общих знаний о проблеме, которую вы пытаетесь решить.

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

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

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

Answer 7

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

setsockopt (m_socket, IPPROTO_TCP, TCP_NODELAY, ...);

Кроме того, использование сигналов на самом деле может быть намного медленнее при попытке пропустить большой объем данных. Давным-давно я создал тестовую программу, в которой читатель ожидал сигнала и считывал пакет - он получал около 100 пакетов в секунду. Затем я просто заблокировал чтение и получил 10000 операций чтения / сек.

Смысл в том, чтобы взглянуть на все эти опции и проверить их. Различные условия сделают разные техники быстрее / медленнее. Важно не просто получать мнения, но и проверять их. Стив Магуайр говорит об этом в «Написание твердого кода». Он использует множество нелогичных примеров и тестирует их, чтобы выяснить, что делает код лучше / быстрее.

Answer 8

Для больших объемов сообщений с низкими накладными расходами бизнес сообщений, которые вы можете попробовать OAMQ с несколькими продуктами. Вариант с открытым исходным кодом OpenAMQ предположительно ведет торговлю в JP Morgan, поэтому он должен быть надежным, не так ли?

Answer 9

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

Но вы должны знать, что вы делаете, и это, вероятно, будет более подвержено ошибкам. по сути, вы бы заменили mpi собственным протоколом обмена сообщениями.

Answer 10

MPI использует сокеты, поэтому единственное отличие должно заключаться в API, с которым взаимодействует ваш код. Вы можете точно настроить протокол, если вы используете сокеты напрямую, но это все. Что именно вы делаете с данными?