В настоящее время я реализую основанную на передаче сообщений реализацию, чтобы перенести интенсивную работу на другой узел с установленным графическим процессором.
Итак, я получил модель «ведущий / ведомый», где хост генерирует данные и хочет, чтобы они вычислялись на подчиненном (+ подключенный графический процессор).
Я реализовал это до сих пор, используя OpenMPI, где я запускаю свою программу на этих 2 узлах и отправляю данные через передачу сообщений.
Теперь я хочу изменить реализацию подчиненного устройства, чтобы он постоянно работал и ждал данных, пока к нему не подключится НЕКОТОРЫЙ хост. И этот хост может быть хостом Windows или Linux.
Поэтому я не хочу начинать мастер&slave с mpirun, но просто хост нормально и хочет, чтобы он подключался во время выполнения к моему slave.
Другое требование заключается в том, что я использую шаблонные классы, размер которых я не знаю во время компиляции. Я начал создавать простой TCP-протокол, который представлял собой просто структуру с тегом сообщения (без знака) и с полезной нагрузкой / данными (как объединение). Здесь была проблема, что я не мог использовать шаблонные классы в объединении (что имеет смысл).
Итак, для решения моей проблемы я ищу библиотеку высокого уровня для передачи сообщений с MPI-подобным синтаксисом в оптимальном варианте. Есть какой-либо способ сделать это?
Любит использовать MPI, но не mpirun и вместо этого подключаться к другим процессам во время выполнения.
MPI предоставляет средство для соединения процессов сервер / клиент. Это обсуждается в разделе 10.4 стандарт, один вариант использования:
Сервер хочет принимать соединения от нескольких клиентов. И клиенты, и сервер могут быть параллельными программами.
В основном это включает в себя, MPI_Open_port
/ MPI_Comm_accept
на сервере, и MPI_Comm_connect
на стороне клиента. Есть некоторые (Name Publishing) для установления связей.
Тем не менее, это, кажется, редко используемая функция, и я не уверен, насколько хорошо различные реализации справляются с этим. Даже стандарт предупреждает, что это не должно быть особенно надежным решением.
Хотя Boost.MPI, по-видимому, не поддерживает это напрямую, должна быть возможность использовать Boost.MPI для фактической связи, когда вы устанавливаете соединение с интерфейсом C.
Других решений пока нет …