¿Se pueden priorizar los mensajes MPI?

8

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.

mpi

— Matthew Emmett
fuente

12

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.

— Bill Barth
fuente

Actualmente, los mensajes finos se envían antes de que necesitemos enviar los mensajes gruesos, por lo que por ahora estamos bien. Tener la superposición de comunicaciones es un poco preocupante, tal vez tendremos un problema si los flops realmente se vuelven gratuitos. De todos modos, podría ser más fácil ajustar un poco nuestro algoritmo en lugar de implementar un sistema de colas de prioridad sobre MPI. ¡Ya veremos!

— Matthew Emmett

Estoy tratando de descubrir cómo su algoritmo no puede importar cuando aparecen los mensajes finos, pero tiene una condición difícil cuando lo hacen los gruesos. ¿Por qué no retrasar los mensajes finos para siempre (y no enviarlos)? Presumiblemente al final de cada aplicación / iteración, ¿se deben requerir todos los mensajes? ¿Qué te preocupa que suceda si los mensajes se superponen?

— Bill Barth

Estamos trabajando en un algoritmo multinivel de tiempo paralelo en el que los niveles aproximados tienen dependencias seriales: el cálculo aproximado en la iteración k en el procesador p depende del cálculo aproximado en la iteración k en el procesador p-1. Los niveles finos son diferentes: la iteración k en el procesador p depende de la iteración k-1 en el procesador p-1. Si los mensajes gruesos se ralentizan, la eficiencia del algoritmo disminuirá, pero la superposición no es catastrófica.

— Matthew Emmett

7

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.

— Hristo Iliev
fuente

5

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.

— Jeff
fuente

No estoy seguro de entender el último párrafo. ¿Quiere decir que, al tener imparcialidad en la red, MPI puede entregar todos los mensajes antes que si algunos tuvieran mayor prioridad que otros? Esto parece contrario a la intuición, pero es cierto que no conozco los detalles de bajo nivel de MPI y las interconexiones modernas: solo puedo relacionar esto con mi conocimiento de redes IP y cosas como filtros de paquetes y colas de prioridad. ¡De todos modos, gracias por la respuesta!

— Matthew Emmett

@MatthewEmmett Ver inversión de prioridad . MPI no conoce las dependencias de mensajes de la aplicación, por lo que establecer una prioridad más alta en un mensaje puede hacer que impida sus dependencias, lo que hace que demore más. Mitigar la inversión de prioridad es difícil.

— Jed Brown

2

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.

— Todd Gamblin
fuente

Sí, envío los mensajes gruesos con etiquetas diferentes a los mensajes finos. Estaba preocupado (como habrás adivinado) de que los mensajes de gran volumen podrían obstruir la red, pero aún no lo hemos visto, es algo de lo que me preguntaba. Gracias por su sugerencia sobre NBC.

— Matthew Emmett