¿MPI o zócalos?

Question

Estoy trabajando en un clúster débilmente acoplado para algunos procesos de datos. El código de red y el código de procesamiento están en su lugar, pero estamos evaluando diferentes metodologías en nuestro enfoque. En este momento, como deberíamos ser, estamos vinculados con la E/S en cuestiones de rendimiento, y estamos tratando de disminuir ese cuello de botella. Obviamente, los conmutadores más rápidos como Infiniband serían increíbles, pero no podemos darnos el lujo de tirar lo que tenemos y obtener nuevos equipos.

Mi pregunta es esta. Todas las aplicaciones de HPC tradicionales y serias que se realizan en clústeres se implementan típicamente con el envío de mensajes en lugar de enviar por sockets directamente. ¿Cuáles son los beneficios de rendimiento para esto? ¿Deberíamos ver una aceleración si cambiamos de los sockets?

Answer 1

MPI MIGHT use sockets. Pero también hay implementación de MPI para ser utilizada con SAN (red de área del sistema) que usa memoria compartida distribuida directa. Eso por supuesto si tienes el hardware para eso. Entonces, MPI le permite usar dichos recursos en el futuro. En ese caso, puede obtener mejoras masivas en el rendimiento (en mi experiencia con clusters en la universidad, puede alcanzar ganancias de unos pocos órdenes de magnitud). Por lo tanto, si está escribiendo código que puede trasladarse a clústeres de gama superior, usar MPI es una muy buena idea.

Incluso al descartar problemas de rendimiento, el uso de MPI puede ahorrarle mucho tiempo, que puede usar para mejorar el rendimiento de otras partes de su sistema o simplemente para salvar su cordura.

Answer 2

MPI utiliza conectores por debajo, por lo que realmente la única diferencia debe ser la API con la que se establece el código. Podría ajustar el protocolo si está utilizando tomas directamente, pero eso es todo. ¿Qué estás haciendo exactamente con los datos?

Answer 3

MPI Utiliza conectores, y si sabe lo que está haciendo probablemente pueda obtener más ancho de banda de sockets porque no necesita enviar tantos metadatos.

Pero tiene que saber lo que está haciendo y es probable que sea más propenso a errores. esencialmente estarías reemplazando mpi con tu propio protocolo de mensajería.

Answer 4

Recomendaría usar MPI en lugar de enrollar el suyo, a menos que sea muy bueno en ese tipo de cosas. Después de haber escrito algunas aplicaciones informáticas distribuidas utilizando mis propios protocolos, siempre me encuentro reproduciendo (y reproduzco pobremente) las características que se encuentran dentro de MPI.

Rendimiento no esperaría que MPI le diera ninguna aceleración de red tangible: utiliza enchufes como usted. Sin embargo, MPI le proporcionará mucha de la funcionalidad que necesitaría para administrar muchos nodos, es decir, la sincronización entre nodos.

Answer 5

para alto volumen, baja sobrecarga negocio de mensajería es posible que desee echa un vistazo a OAMQ con varios productos. La variante de código abierto OpenAMQ supuestamente ejecuta la negociación en JP Morgan, por lo que debería ser confiable, ¿no?

Answer 6

No he usado MPI, pero he usado enchufes bastante. Hay algunas cosas a considerar en los enchufes de alto rendimiento. ¿Estás haciendo muchos paquetes pequeños o grandes? Si está haciendo muchos paquetes pequeños, considere desactivar el algoritmo Nagle para obtener una respuesta más rápida:

setsockopt (m_socket, IPPROTO_TCP, TCP_NODELAY, ...);

Además, el uso de señales puede ser mucho más lento cuando se trata de obtener un gran volumen de datos. Hace mucho tiempo, hice un programa de prueba en el que el lector esperaría una señal y leería un paquete; obtendría una combinación de 100 paquetes/seg. Luego hice lecturas de bloqueo y obtuve 10000 lecturas/seg.

El punto es mirar a todas estas opciones, y en realidad ponerlos a prueba. Las diferentes condiciones harán que las diferentes técnicas sean más rápidas/lentas. Es importante no solo obtener opiniones, sino ponerlas a prueba. Steve Maguire habla sobre esto en "Escribir código sólido". Utiliza muchos ejemplos que son contraintuitivos, y los prueba para descubrir qué hace un código mejor/más rápido.

Answer 7

voy a tener que estar de acuerdo con OldMan y espacio libre. A menos que sepa de una mejora específica y específica de algún indicador útil (rendimiento, mantenimiento, etc.) sobre MPI, ¿por qué reinventar la rueda? MPI representa una gran cantidad de conocimiento compartido sobre el problema que está tratando de resolver.

Hay una gran cantidad de problemas que debe abordar, que van más allá del simple envío de datos. La configuración y el mantenimiento de la conexión se convertirán en su responsabilidad. Si MPI es la abstracción exacta (parece que es) que necesita, úselo.

Por lo menos, el uso de MPI y posterior refactorización con su propio sistema es un buen enfoque que cuesta la instalación y la dependencia de MPI.

Me gusta especialmente el punto de OldMan de que MPI le ofrece mucho más que una simple comunicación de socket. Obtiene una gran cantidad de implementación de cómputo distribuido y paralelo con una abstracción transparente.

Answer 8

paso de mensajes no es un paradigma de una tecnología. En la instalación más general, MPI usará enchufes para comunicarse. Puede ver una velocidad al cambiar a MPI, pero solo en la medida en que no haya optimizado su comunicación de socket.

Cómo es O vinculado la aplicación de E /? ¿Está obligado a transferir los bloques de datos a los nodos de trabajo o está vinculado debido a la comunicación durante el cálculo?

Si la respuesta es "debido a la comunicación", entonces el problema es que está escribiendo una aplicación estrechamente acoplada y tratando de ejecutarla en un clúster diseñado para tareas débilmente acopladas. La única forma de obtener rendimiento será obtener un mejor hardware (conmutadores más rápidos, infiniband, etc.) ... ¿tal vez podría pedirle prestado tiempo al HPC de otra persona?

Si la respuesta es transferencia de "bloques de datos", considere la posibilidad de asignar a los trabajadores múltiples bloques de datos (para que permanezcan ocupados por más tiempo) & comprimir los bloques de datos antes de la transferencia. Esta es una estrategia que puede ayudar en una aplicación débilmente acoplada.

Answer 9

El rendimiento no es la única consideración en este caso, incluso en los clústeres de alto rendimiento. MPI ofrece una API estándar y es "portátil". Es relativamente trivial cambiar una aplicación entre las diferentes versiones de MPI.

implementaciones más MPI utilizan sockets para la comunicación basada en TCP. Las probabilidades son buenas de que cualquier implementación de MPI determinada se optimice mejor y proporcione una transmisión de mensajes más rápida, que una aplicación local que use sockets directamente.

Además, si alguna vez tiene la oportunidad de ejecutar su código en un clúster que tiene InfiniBand, la capa MPI resumirá cualquiera de esos cambios de código. Esta no es una ventaja trivial: la codificación de una aplicación para usar directamente la implementación de OFED (u otros verbos del IB) es muy difícil.

La mayoría de las aplicaciones MPI incluyen pequeñas aplicaciones de prueba que se pueden usar para verificar la corrección de la configuración de red independientemente de su aplicación. Esta es una gran ventaja cuando llega el momento de depurar su aplicación. El estándar MPI incluye las interfaces "pMPI" para perfilar llamadas MPI. Esta interfaz también le permite agregar fácilmente sumas de verificación u otra verificación de datos a todas las rutinas de envío de mensajes.

Answer 10

MPI tiene la ventaja de que puede hacer comunicaciones colectivas. Hacer transmisiones/reducciones en O (log p)/* p es su número de procesadores */en lugar de O (p) es una gran ventaja.