¿Cuál es una manera eficiente de notificar a los procesos MPI de recibir mensajes?

8

En MPI, ¿hay algún mecanismo incorporado para notificar a un grupo de procesos que necesitan recibir mensajes de otros procesos?

En mi aplicación, todos los procesos deben enviar datos a un grupo de procesos con identificadores de rango conocidos (que potencialmente cambian en cada iteración), pero no conocen el rango de los procesos de los que recibirán mensajes. ¿Existe una forma portátil, preferiblemente incorporada, de lograr esto sin consultar todos y cada uno de los procesos?

mpi

— mmirzadeh
fuente

7

Puede intentar que todos los procesadores utilicen MPI_IProbe o MPI_Probe con MPI_ANY_SOURCE para verificar si hay mensajes que se pueden recibir con una etiqueta determinada. Si hay mensajes coincidentes, puede extraer el rango de los remitentes del estado devuelto y llamar a MPI_Recv inmediatamente.

— Matthew Emmett
fuente

¿Llamar es MPI_Probeesencialmente más barato que MPI_Recv?

— mmirzadeh

@GradGuy Con MPI_IProbe y MPI_Probe en realidad no recibe ningún mensaje (solo está consultando MPI para ver si hay algún mensaje por cobrar), por lo que en ese sentido supongo que es más barato que MPI_Recv.

— Matthew Emmett

@MatthewEmmett ¿Cómo sabe el receptor cuántas MPI_IProbellamadas publicar o cuánto tiempo siguen sondeando?

— Shibli

12

Otros ya han propuesto las diversas variantes de MPI_Probe, pero me gustaría señalar una cosa: MPI no es una llamada a procedimiento remoto, es decir, no hay formas de notificar a un proceso que ha entrado algún mensaje (por ejemplo, al emitir una señal ) Se envían mensajes, pero si el proceso de recepción no los busca, entonces no sucederá nada. Como tal, la respuesta a su pregunta es "no", pero un proceso puede determinar activamente si se le ha enviado un mensaje.

— Wolfgang Bangerth
fuente

En teoría, MPI_Probe puede ser reprogramado por el kernel de modo que sea pasivo hasta que se use, lo que no es muy diferente de cómo IBM implementa RPC reales en Blue Gene (donde el SO y HW colaboran para implementar interrupciones iniciadas en red muy eficientes que pueden llamar devoluciones de llamada arbitrarias definidas por el usuario). Por supuesto, ninguna implementación que conozca realmente hace esto bloqueando las llamadas MPI ...

— Jeff

1

El punto que quería destacar no es tanto sobre cómo se implementa realmente, sino sobre el modelo mental que uno debería tener cuando se piensa en MPI. MPI es un concepto puramente pasivo: no puede acceder a los datos de otro proceso, no puede esperar que se genere una señal si llega un mensaje entrante; todo solo sucede si envías un mensaje activamente o miras si llegó uno.

— Wolfgang Bangerth

Tiene razón acerca de una señal, pero RMA le da acceso a datos remotos y se supone que las implementaciones proporcionan un progreso pasivo.

— Jeff

1

Sí, está hablando de lo que MPI 3 llama "comunicación unilateral". Esa es una adición bastante reciente, y probablemente una rara vez utilizada. Pero creo que no le quita el modelo mental que expuse anteriormente.

— Wolfgang Bangerth

MPI 2.0 tenía RMA hace diez años y uno puede implementar, por ejemplo, put_with_notify usando esas características. Estoy de acuerdo en que MPI no tiene llamadas a procedimientos remotos, también conocidos como mensajes activos (todavía), pero ninguna máquina que no sea de IBM implementa aquellos sin sondeo, por lo que ya no estamos hablando de MPI si criticamos la necesidad de sondeo.

— Jeff

7

http://mpitutorial.com/tutorials/dynamic-receiving-with-mpi-probe-and-mpi-status/ tiene un tutorial que describe el uso de MPI_Probe que podría serle útil.

— Jeff
fuente

1

Si los remitentes saben a quién envían pero los receptores no saben de quién están recibiendo, simplemente publique sus recibos de MPI_ANY_SOURCE. Eso coincidirá con la recepción con cualquier proceso que le envíe un mensaje.

Si los receptores podrían no recibir nada, pueden publicar un iRecv. Cada vez que se realiza un proceso enviando sus mensajes, puede publicar am Ibarrier. Cuando Ibarrier se completa porque todos los procesos lo ingresaron (y llamaron a MPI_WAIT en el objeto de solicitud), todos saben que la comunicación se realizó y pueden cancelar su Irecv anterior.

— Wesley Bland
fuente

¿En qué orden recibe eso el mensaje? Necesito devolver el resultado del remitente de algunos cálculos ...

— mmirzadeh

La recepción estará en orden por proceso de envío. Si el rango 1 envía mensajes A - B - C en ese orden, llegarán en ese orden. No hay garantía del orden entre los procesos.

— Wesley Bland

Ya veo ... pero ¿se garantiza que los mensajes de los procesos no se mezclan?

— mmirzadeh

No. Los mensajes entre procesos pueden llegar en cualquier orden.

— Wesley Bland el

3

MPI_Cancel es una función horrible y debe usarse con la menor frecuencia posible. En su lugar, apruebo las variantes de Probe.

— Jeff