2009-12-09 2 views
-1

Я ищу фреймворк/подход для передачи сообщений, распределенных вычислений на C++.Простые распределенные вычисления (аналогично суммированию) (в C++)

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

Поскольку все обновления являются аддитивными (то есть коммутативными и ассоциативными), вполне нормально объединять обновления с других узлов в произвольном порядке или даже для пакетного слияния обновлений. Когда дело доходит до , применяя обновления, парадигма map/reduce будет работать нормально.

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

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

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

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

Кто-нибудь знает какие-либо существующие рамки или подходы к ускорению разработки? Или даже просто общие указатели? Я никогда не делал ничего подобного ...

ответ

3

Возможно, вам нужен MPI (интерфейс передачи сообщений). Это, по сути, отраслевой стандарт для распределенных вычислений. Есть много реализаций, но я бы порекомендовал OpenMPI, потому что он бесплатный и очень ценится. Он предоставляет вам API-интерфейс C для передачи сообщений между узлами, а также обеспечивает более высокоуровневые функции, такие как широковещательная передача, все-на-одном, сокращение, сборка рассеяния и т. Д. Она работает по протоколу TCP, а также быстрее, с меньшей задержкой таких как Infiniband или Myrinet, и поддерживает различные топологии.

Существует также обложка Boost вокруг MPI (Boost.MPI), которая предоставит вам более удобный интерфейс на C++.

+0

Это похоже на разумный технический старт. Я предполагаю, что пакетный/слияние аспектов не является решенной проблемой? –

 Смежные вопросы

  • Нет связанных вопросов^_^