que open for faq descargar mpi hpc openmpi

for - MPICH vs OpenMPI



openmpi faq (4)

¿Alguien puede explicar las diferencias entre las implementaciones de MPI de OpenMPI y MPICH? ¿Cuál de los dos es una mejor implementación?


Propósito

En primer lugar, es importante reconocer cómo MPICH y Open-MPI son diferentes, es decir, que están diseñados para satisfacer diferentes necesidades. MPICH se supone que es una implementación de referencia de alta calidad del último estándar MPI y la base para implementaciones derivadas para satisfacer necesidades especiales. Open-MPI se enfoca en el caso común, tanto en términos de uso como de conductos de red.

Soporte para la tecnología de red

Open-MPI documenta su soporte de red here . MPICH enumera esta información en el README distribuido con cada versión (por ejemplo, this es para 3.2.1). Tenga en cuenta que, dado que tanto Open-MPI como MPICH admiten la capa de red OFI (también conocida como libfabric), admiten muchas de las mismas redes. Sin embargo, libfabric es una API multifacética, por lo que no todas las redes pueden ser compatibles en ambas (por ejemplo, MPICH tiene una implementación de IBM Blue Gene / Q basada en OFI, pero no conozco el soporte equivalente en Open-MPI) . Sin embargo, las implementaciones basadas en OFI de MPICH y Open-MPI están trabajando en memoria compartida, Ethernet (a través de TCP / IP), Mellanox InfiniBand, Intel Omni Path y probablemente otras redes. Open-MPI también admite ambas redes y otras de forma nativa (es decir, sin OFI en el medio).

En el pasado, una queja común sobre MPICH es que no admite InfiniBand, mientras que Open-MPI sí lo hace. Sin embargo, MVAPICH e Intel MPI (entre otros), ambos derivados de MPICH, son compatibles con InfiniBand, por lo que si uno está dispuesto a definir MPICH como "MPICH y sus derivados", MPICH tiene un soporte de red extremadamente amplio, que incluye InfiniBand y propietario. interconecta como Cray Seastar, Gemini y Aries, así como IBM Blue Gene (/ L, / P y / Q). Open-MPI también es compatible con la interconexión Cray Gemini, pero su uso no es compatible con Cray. Más recientemente, MPICH apoyó InfiniBand a través de netmod (ahora obsoleto), pero MVAPICH2 tiene optimizaciones extensas que lo convierten en la implementación preferida en casi todos los casos.

Soporte de funciones del último estándar MPI

Un eje ortogonal al soporte de hardware / plataforma es la cobertura del estándar MPI. Aquí, MPICH suele ser muy superior. MPICH ha sido la primera implementación de cada lanzamiento del estándar MPI, desde MPI-1 a MPI-3. Open-MPI solo ha soportado recientemente MPI-3 y encuentro que algunas características de MPI-3 son defectuosas en algunas plataformas (MPICH no está libre de errores, por supuesto, pero los errores en las características de MPI-3 han sido mucho menos comunes).

Históricamente, Open-MPI no ha tenido soporte holístico para MPI_THREAD_MULTIPLE , que es crítico para algunas aplicaciones. Puede ser compatible con algunas plataformas, pero generalmente no se puede suponer que funcione. Por otro lado, MPICH ha tenido soporte holístico para MPI_THREAD_MULTIPLE durante muchos años, aunque la implementación no siempre es de alto rendimiento (ver "Aspectos de bloqueo en implementaciones de multiproceso MPI" para un análisis).

Otra característica que se rompió en Open-MPI 1.x fue la comunicación unilateral, también conocida como RMA. Esto se ha solucionado más recientemente y encuentro, como un usuario muy pesado de estas características, que generalmente están funcionando bien en Open-MPI 3.x (consulte la matriz de prueba ARMCI-MPI en Travis CI para obtener resultados que muestren que RMA trabaja con ambas implementaciones, al menos en memoria compartida. He visto resultados positivos similares en Intel Omni Path, pero no he probado Mellanox InfiniBand.

Gestión de proceso

Un área donde Open-MPI solía ser significativamente superior era el administrador de procesos. El antiguo lanzamiento de MPICH (MPD) era frágil y difícil de usar. Afortunadamente, ha estado en desuso por muchos años (consulte la entrada de Preguntas frecuentes sobre MPICH para obtener más información). Por lo tanto, la crítica de MPICH debido a MPD es espuria.

El gestor de procesos de Hydra es bastante bueno y tiene la facilidad de uso y las funciones similares configuradas como ORTE (en Open-MPI), por ejemplo, ambas admiten HWLOC para el control de la topología de procesos. Hay informes de que el lanzamiento del proceso Open-MPI es más rápido que los derivados MPICH para trabajos más grandes (más de 1000 procesos), pero como no tengo experiencia de primera mano aquí, no me siento cómodo al establecer conclusiones. Tales problemas de rendimiento suelen ser específicos de la red y, a veces, incluso específicos de la máquina.

He descubierto que Open-MPI es más robusto cuando se usa MacOS con una VPN, es decir, MPICH puede bloquearse durante el inicio debido a problemas de resolución de nombre de host. Como se trata de un error, este problema puede desaparecer en el futuro.

Portabilidad binaria

Si bien tanto MPICH como Open-MPI son software de código abierto que se pueden compilar en una amplia gama de plataformas, la portabilidad de las bibliotecas de MPI en formato binario, o los programas vinculados con ellas, a menudo es importante.

MPICH y muchos de sus derivados son compatibles con la compatibilidad ABI ( website ), lo que significa que la interfaz binaria de la biblioteca es constante y, por lo tanto, se puede compilar con mpi.h desde una implementación y luego ejecutarla con otra. Esto es cierto incluso en múltiples versiones de las bibliotecas. Por ejemplo, frecuentemente compilo Intel MPI pero LD_PRELOAD una versión de desarrollo de MPICH en tiempo de ejecución. Una de las grandes ventajas de la compatibilidad ABI es que los ISV (proveedores independientes de software) pueden lanzar binarios compilados contra un solo miembro de la familia MPICH.

ABI no es el único tipo de compatibilidad binaria. Los escenarios descritos anteriormente suponen que los usuarios emplean la misma versión del mpirun MPI (generalmente mpirun o mpiexec , junto con sus daemons de nodo de cómputo) y la biblioteca de MPI en todas partes. Este no es necesariamente el caso de los contenedores.

Si bien Open-MPI no promete compatibilidad con ABI, han invertido mucho en contenedores de apoyo ( docs , slides ). Esto requiere gran cuidado para mantener la compatibilidad entre las diferentes versiones del iniciador de MPI, daemons de iniciador y biblioteca de MPI, porque un usuario puede iniciar trabajos utilizando una versión más nueva del iniciador de MPI que los daemons de inicio en el contenedor. Sin prestar atención a la estabilidad de la interfaz del iniciador, los trabajos en contenedor no se iniciarán a menos que las versiones de cada componente del iniciador sean compatibles. Este no es un problema insuperable:

La solución alternativa utilizada por el mundo de Docker, por ejemplo, es contenerizar la infraestructura junto con la aplicación. En otras palabras, incluye el daemon MPI en el contenedor con la aplicación en sí, y luego requiere que todos los contenedores (incluidos mpiexec) tengan la misma versión. Esto evita el problema ya que ya no tiene operaciones de infraestructura de versión cruzada.

Reconozco a Ralph Castain del equipo Open-MPI por explicarme los problemas del contenedor. La cita inmediatamente anterior es suya.

Comparación específica de la plataforma

Aquí está mi evaluación plataforma por plataforma:

  • Mac OS: tanto Open-MPI como MPICH deberían funcionar bien. Para obtener las últimas características del estándar MPI-3, debe usar una versión reciente de Open-MPI, que está disponible en Homebrew. No hay motivo para pensar en el rendimiento de MPI si está ejecutando en una computadora portátil Mac.

  • Linux con memoria compartida: tanto Open-MPI como MPICH deberían funcionar bien. Si quiere una versión que sea compatible con MPI-3 o MPI_THREAD_MULTIPLE, probablemente necesite MPICH, a menos que construya Open-MPI usted mismo, porque por ejemplo, Ubuntu 16.04 solo proporciona la antigua versión 1.10 a través de APT. No estoy al tanto de ninguna diferencia de rendimiento significativa entre las dos implementaciones. Ambos admiten optimizaciones de copia única si el sistema operativo lo permite.

  • Linux con Mellanox InfiniBand: use Open-MPI o MVAPICH2. Si desea una versión de lanzamiento que admita MPI-3 o MPI_THREAD_MULTIPLE , es probable que necesite MVAPICH2. Me parece que MVAPICH2 funciona muy bien pero no he hecho una comparación directa con OpenMPI en InfiniBand, en parte porque las características para las que el rendimiento me importa más (RMA también conocido como de un solo lado) se han roto en Open-MPI en el pasado.

  • Linux con Intel Omni Path (o su predecesora, True Scale): he utilizado MVAPICH2, Intel MPI, MPICH y Open-MPI en dichos sistemas, y todos están funcionando. Intel MPI tiende a ser el más optimizado, mientras que Open-MPI ofrece el mejor rendimiento de las implementaciones de código abierto porque tienen un back-end basado en PSM2 bien optimizado. Tengo algunas notas sobre GitHub sobre cómo construir diferentes implementaciones de código abierto, pero dicha información se vuelve obsoleta bastante rápidamente.

  • Supercomputadores Cray o IBM: MPI viene instalado en estas máquinas automáticamente y está basado en MPICH en ambos casos. Ha habido demostraciones de MPICH en Cray XC40 ( here ) usando OFI , Intel MPI en Cray XC40 ( here ) usando OFI, MPICH en Blue Gene / Q usando OFI ( here ), y Open-MPI en Cray XC40 utilizando tanto OFI como uGNI ( here ), pero ninguno de estos es compatible con proveedores.

  • Windows: no veo sentido en ejecutar MPI en Windows, excepto a través de una máquina virtual Linux, pero tanto Microsoft MPI como Intel MPI son compatibles con Windows y están basados ​​en MPICH. No he visto ningún informe de compilaciones exitosas de MPICH o Open-MPI usando Subsistema de Windows para Linux .

Notas

En total divulgación, actualmente trabajo para Intel en una capacidad de búsqueda / exploración (es decir, no trabajo en ningún producto de software de Intel) y anteriormente trabajé para Argonne National Lab durante cinco años, donde colaboré extensamente con el equipo de MPICH.


Ambos cumplen con los estándares, por lo que no debería importar cuál usar desde el punto de vista de la corrección. A menos que haya alguna función, como extensiones de depuración específicas, que necesite, realice una evaluación comparativa de ambas y elija la que sea más rápida para sus aplicaciones en su hardware. Además, tenga en cuenta que existen otras implementaciones de MPI que pueden proporcionar un mejor rendimiento o compatibilidad, como MVAPICH (puede tener el mejor rendimiento InfiniBand) o Intel MPI (ISV ampliamente compatibles). HP trabajó duro para que su MPI calificara con muchos códigos ISV también, pero no estoy seguro de cómo le está yendo después de que se lo vendió a Platform ...


Estoy de acuerdo con el poster anterior. Pruebe ambos para ver cuál ejecuta más rápido su aplicación y luego úsela para producción. Ambos son compatibles con los estándares. Si es tu escritorio, está bien. OpenMPI viene de la caja en Macbooks, y MPICH parece ser más amigable para Linux / Valgrind. Está entre usted y su cadena de herramientas.

Si se trata de un clúster de producción, debe realizar una evaluación comparativa más exhaustiva para asegurarse de que esté optimizado para la topología de su red. Configurarlo en un clúster de producción será la principal diferencia en términos de su tiempo, ya que tendrá que RTFM.


Si haces desarrollo en lugar de sistema de producción, ve con MPICH. MPICH tiene un depurador incorporado, mientras que Open-MPI no es la última vez que lo verifiqué.

En producción, Open-MPI probablemente sea más rápido. Pero luego puede investigar otras alternativas, como Intel MPI.