¿Se pueden priorizar los mensajes MPI?

Según tengo entendido, el orden en que se reciben los mensajes MPI punto a punto sin bloqueo (Isend e Irecv) es coherente con el orden en que se envían. ¿Hay alguna técnica para dar prioridad a ciertos mensajes sobre otros?

Por ejemplo, tenemos un algoritmo multinivel en el que las soluciones de alta resolución se envían con llamadas sin bloqueo y se realizan cálculos en los niveles gruesos mientras se envían los mensajes finos. Sin embargo, cuando llega el momento de enviar las soluciones de baja resolución, nos gustaría que tengan prioridad (esencialmente están bloqueando).

También puedo imaginar que esto podría ser útil para otros algoritmos a medida que avanzamos hacia el exascale: algunos mensajes están en la "ruta crítica" mientras que otros no.

Creo que la respuesta a esto es no. Una vez que los ha introducido en la pila de MPI, están fuera de su control y la semántica de MPI rige la forma en que se envían los mensajes.

Ciertamente, puede priorizar los mensajes haciendo cola en su código antes de enviarlos, y luego verificando con frecuencia cuáles son los más importantes para enviar. Pero no estoy del todo convencido de que obtendrá ningún beneficio. ¿Existe evidencia de que sus mensajes no están completos cuando se prepara para enviar los mensajes groseros? Si no lo hay, es posible que desee investigar si es necesario en primer lugar.

Actualmente MPI no tiene disposiciones para la priorización de mensajes y tampoco tiene el próximo estándar MPI 3.0. Depende de la implementación de MPI decidir cómo transmitir los mensajes. Por ejemplo, los mensajes más pequeños pueden enviarse más rápido debido a ciertas omisiones en la maquinaria de comunicación (altamente dependiente de la implementación y del sistema). Es posible que pueda aprovechar el hecho de que la mayoría de las implementaciones de MPI dividen los mensajes grandes en fragmentos y los mensajes más pequeños pueden deslizarse entre los fragmentos grandes. Pero, una vez más, esto depende mucho de la implementación y no confiaría en eso.

Hice un experimento simple usando Open MPI 1.5.3 a través de la conexión InfiniBand. El programa envía un mensaje muy grande (1 GiB) con MPI_Isendy luego dos mensajes cortos (16 bytes) con MPI_Send, y luego espera a que se complete el envío grande MPI_Wait. Por otro lado, MPI_Irecvprimero se publica un para la gran recepción y luego dos MPI_Recvoperaciones posteriores , seguidas por MPI_Waitla gran recepción. Siempre pude recibir los dos mensajes cortos antes de que se completara la recepción del mensaje grande. Aquí está el resultado de mi prueba:

[0] Rank 0 running on host1
[0] Starting big send at 0.000019s
[0] Starting small send at 0.215448s
[0] Starting small send 2 at 0.224105s
[0] Starting wait at 0.224114s
[0] Finished wait at 0.935843s
[1] Rank 1 running on host2
[1] Starting big receive at 0.000020s
[1] Starting small recv at 0.000037s
[1] Starting small recv 2 at 0.548396s
[1] Starting wait at 0.548418s
[1] Finished wait at 0.935780s

Ambos envíos pequeños tienen éxito antes de que el envío asíncrono se haya completado como lo demuestra el tiempo de espera de ~ 700 ms. Diría que la primera recepción pequeña tiene éxito algún tiempo (~ 300 ms) después de que la recepción grande haya comenzado en segundo plano. Intenté esto usando solo MPI_COMM_WORLDo usando un comunicador separado para los mensajes pequeños: los resultados son los mismos. Los nodos tienen un QDR IB HCA cada uno y su ejecución --mca btl_base_verbose 50confirma que no hay canales de comunicación alternativos en uso.

Esto no es compatible con MPI ni con ningún otro middleware de comunicación que conozca. Esto probablemente se deba a que no es compatible con ningún hardware que conozca, con la excepción de Blue Gene, donde hay paquetes de alta prioridad para mensajes de control que superarán a otros mensajes en algunas condiciones. Sin embargo, estos no son de uso general ya que solo permiten que uno comunique 64 bytes (al menos en Blue Gene / P).

La buena noticia es que no necesitas esto. La sobrecarga para implementarlo no valdrá la pena y encontrará, suponiendo que alguna vez investigue los detalles de bajo nivel, que no implementar las prioridades en la red le permite a MPI ofrecer el mejor rendimiento en la mayoría de los usos.

Es un poco extraño que mencione esto en el contexto del orden de los mensajes. Citandote:

Según tengo entendido, el orden en que se reciben los mensajes MPI punto a punto sin bloqueo (Isend e Irecv) es coherente con el orden en que se envían.

Vale la pena señalar aquí que MPI solo garantiza que los mensajes coincidentes entre procesos se recibirán en el orden en que fueron enviados. Realmente no desea que cambie este tipo de orden, porque hace que su código sea más comprensible y le quita una gran carga como programador de aplicaciones.

Sin embargo, si envió mensajes con diferentes etiquetas, eso cambia los criterios de coincidencia, y podría recibir fácilmente el segundo antes que el primero. Vea el segundo ejemplo en la parte relevante de la norma para más detalles. Yo espero que si usted tiene dos piezas de código que envían al mismo tiempo que ya está separando los mensajes grueso y fino usando las etiquetas, y no tratar de poner en práctica algún protocolo de su propio mensaje en la parte superior del ordenamiento. Esta es una segunda naturaleza para la mayoría de los programadores de MPI que conozco.

De todos modos, suponiendo que lo esté haciendo, probablemente le preocupe que los mensajes de gran volumen y granularidad obstruyan su red cuando desee enviar los gruesos. Mi consejo general al respecto es que si no se trata de un problema de rendimiento que realmente se puede medir en este momento, entonces realmente no debería molestarse en abordarlo. Parece confirmar que todavía no es un problema en uno de los comentarios anteriores.

Una posible solución que podría considerar sería utilizar un colectivo sin bloqueo (NBC) como Bcast o Barrier para notificar a todos que la fase gruesa está lista y lista para enviar su solución. Con toda probabilidad, el tráfico de NBC no se priorizará, pero los procesos notificados pueden al menos dejar de enviar gotas de soluciones finas hasta que se realicen los envíos generales. Los NBC estarán en MPI-3 o podría intentar usar libNBC si no puede esperar tanto.

Una vez más, sin embargo, esto parece mucho trabajo para algo que todavía no parece ser un problema de rendimiento.