Узел OpenMPI и топология сети

В настоящее время я создаю небольшую служебную библиотеку как часть более крупного проекта. OpenMPI имеет хорошо документированную библиотеку API, но я немного озадачен, когда дело доходит до связи между узлами на более низком уровне. Я знаю, что при написании вашего алгоритма вы распределяете его по всем узлам, которые, как ожидается, будут выполнять вычисления, каждый из которых взаимодействует с остальными, выполняя часть алгоритма на основе их «глобального» ранга MPI (как определено в алгоритме) и все узлы синхронизируются вперед и назад. Однако причина, по которой я поместил global в кавычки, заключается в том, что openMPI взаимодействует на уровне ip, поэтому я говорю, что у меня уже есть длинный алгоритм выполнения, но есть узел, который простаивает, не запуская никаких процессов MPI, если я выполняю свой MPI алгоритм на нем, присоединится ли он к MPI_COMM_WORLD и станет частью общей топологии сети, или есть какое-то «шаманство», которое мне нужно сделать, чтобы сделать этот узел частью MPI_COMM_WORLD. Кроме того, если узлы могут стать частью MPI_COMM_WORLD для этого конкретного алгоритма, как я могу зарегистрировать/идентифицировать этот новый узел?

любые ссылки на чтение также полезны.

огромное спасибо!

tl;dr можно ли заменить узлы MPI в горячем режиме из MPI_COMM_WORLD?


person mayotic    schedule 24.05.2012    source источник


Ответы (1)


Вы не можете присоединять узлы к коммуникатору после его создания. Это также верно для MPI_COMM_WORLD, который является всего лишь предварительно созданным коммуникатором. Только процессы, запущенные в рамках первоначального запуска SPMD, становятся частью MPI_COMM_WORLD. Но вы можете создавать дополнительные процессы, используя средства управления процессами MPI-2, описанные в . Глава 10 текущей версии стандарта MPI 2.2.

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

MPI 3.0 (когда он выйдет, рано или поздно) принесет отказоустойчивость, которая позволит исключить/удалить неисправные процессы из MPI_COMM_WORLD (или из любого другого коммуникатора), а MPI 3.1 со временем принесет что-то, что позволит заменить неисправные процессы .

person Hristo Iliev    schedule 24.05.2012
comment
спасибо за быстрый ответ; кстати я тоже из Болгарии, меня зовут Георгий :) - person mayotic; 24.05.2012
comment
у меня есть еще один быстрый вопрос относительно схемы связи; если я создам групповой коммуникатор выбранных узлов из MPI_COMM_WORLD в конкретном процессе, будет ли этот процесс единственным, который обладает этим дескриптором MPI_Group, или он будет создан для всех узлов, которые являются частью этой группы? - person mayotic; 26.05.2012
comment
Имейте в виду, что прогнозные заявления о MPI-3 не являются точными. Части отказоустойчивости, например, сейчас вызывают весьма споры, и нет гарантии, что они станут частью MPI-3. - person Jeff Squyres; 26.05.2012
comment
Согласно вашему комментарию, MPI ничего не знает об узлах - он понимает только процессы. Также не существует такого понятия, как групповой коммуникатор — у коммуникаторов есть группа, но это не совсем одно и то же. Группа — это набор процессов. Коммуникатор — это группа с уникальным коммуникативным контекстом. Пример: можно отправлять и получать на коммуникаторе; вы не можете отправлять и получать в группе. Итак, если я понимаю ваш вопрос, дескрипторы MPI_Group являются локальными, но некоторые из конструкторов являются коллективными по своей природе (это означает, что все процессы должны их вызывать). - person Jeff Squyres; 26.05.2012