MPI или сокеты?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каким образом ограничивается ввод-вывод вашего приложения? Привязан ли он к передаче блоков данных рабочим узлам или связан из-за связи во время вычислений?

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

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

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

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

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

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

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