Propósito
Primero, es importante reconocer cómo MPICH y Open-MPI son diferentes, es decir, que están diseñados para satisfacer diferentes necesidades. Se supone que MPICH es una implementación de referencia de alta calidad del último estándar MPI y la base para implementaciones derivadas para satisfacer necesidades de propósitos especiales. Open-MPI apunta al caso común, tanto en términos de uso como de conductos de red.
Soporte para tecnología de red
Open-MPI documenta su soporte de red aquí . MPICH enumera esta información en el archivo README distribuido con cada versión (por ejemplo, esto es para 3.2.1). Tenga en cuenta que debido a que Open-MPI y MPICH son compatibles con OFI(también conocido como libfabric), soportan muchas de las mismas redes. Sin embargo, libfabric es una API multifacética, por lo que no todas las redes pueden recibir el mismo soporte en ambos (por ejemplo, MPICH tiene una implementación IBM Blue Gene / Q basada en OFI, pero no conozco un 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 es compatible con 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 es compatible con InfiniBand, mientras que Open-MPI sí. 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", entonces 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 admite la interconexión Cray Gemini, pero Cray no admite su uso. Más recientemente, MPICH apoyó InfiniBand a través de un netmod (ahora en desuso), pero MVAPICH2 tiene amplias optimizaciones 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 es generalmente muy superior. MPICH ha sido la primera implementación de cada versión del estándar MPI, desde MPI-1 a MPI-3. Open-MPI solo ha admitido recientemente MPI-3 y creo que algunas características de MPI-3 tienen errores 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 un soporte holístico MPI_THREAD_MULTIPLE, lo cual es crítico para algunas aplicaciones. Puede ser compatible con algunas plataformas, pero generalmente no se puede suponer que funciona. Por otro lado, MPICH ha tenido un soporte integral MPI_THREAD_MULTIPLEdurante muchos años, aunque la implementación no siempre es de alto rendimiento (consulte "Aspectos de bloqueo en implementaciones de MPI multiproceso" 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, como usuario muy importante de estas características, encuentro que en general funcionan bien en Open-MPI 3.x (consulte, por ejemplo, la matriz de prueba ARMCI-MPI en Travis CI para ver los resultados que muestran que RMA funciona 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 quedado en desuso durante muchos años (consulte la entrada de preguntas frecuentes de MPICH para más detalles). Por lo tanto, las críticas a MPICH debido a MPD son espurias.
El administrador de procesos Hydra es bastante bueno y tiene la usabilidad y el conjunto de características similares a ORTE (en Open-MPI), por ejemplo, ambos admiten HWLOC para el control sobre la topología del proceso. Hay informes de que el lanzamiento del proceso Open-MPI es más rápido que los derivados de 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 con ninguna conclusión. Tales problemas de rendimiento suelen ser específicos de la red y, a veces, incluso específicos de la máquina.
He encontrado que Open-MPI es más robusto cuando se usa MacOS con una VPN, es decir, MPICH puede bloquearse en 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 puede compilar en una amplia gama de plataformas, la portabilidad de las bibliotecas MPI en forma binaria, o programas vinculados en su contra, a menudo es importante.
MPICH y muchos de sus derivados son compatibles con la compatibilidad ABI ( sitio web ), lo que significa que la interfaz binaria a la biblioteca es constante y, por lo tanto, uno puede compilar mpi.hdesde 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_PRELOADuna 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 de software independientes) 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 iniciador MPI (generalmente mpiruno mpiexec, junto con sus demonios de nodo de cómputo) y la biblioteca MPI en todas partes. Este no es necesariamente el caso de los contenedores.
Si bien Open-MPI no promete compatibilidad ABI, han invertido mucho en contenedores de soporte ( documentos , diapositivas ). Esto requiere un gran cuidado para mantener la compatibilidad entre diferentes versiones del iniciador MPI, los demonios del iniciador y la biblioteca MPI, porque un usuario puede iniciar trabajos utilizando una versión más nueva del iniciador MPI que los demonios del iniciador en el soporte del contenedor. Sin una cuidadosa atención a la estabilidad de la interfaz del iniciador, los trabajos de 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 Docker, por ejemplo, es contener la infraestructura junto con la aplicación. En otras palabras, incluye el demonio MPI en el contenedor con la aplicación misma, y luego requiere que todos los contenedores (incluido mpiexec) sean de la misma versión. Esto evita el problema ya que ya no tiene operaciones de infraestructura de versiones cruzadas.
Agradezco a Ralph Castain, del equipo Open-MPI, por explicarme los problemas del contenedor. La cita inmediatamente anterior es suya.
Comparación de plataforma específica
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 razón 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 desea una versión de lanzamiento que sea compatible con todo MPI-3 o MPI_THREAD_MULTIPLE, probablemente necesite MPICH, a menos que cree Open-MPI usted mismo, porque, por ejemplo, Ubuntu 16.04 solo proporciona la versión antigua 1.10 a través de APT. No conozco 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 todo MPI-3 o MPI_THREAD_MULTIPLE, es probable que necesite MVAPICH2. Creo 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 es más importante para mí (RMA, también conocido como unilateral) se han roto en Open-MPI en el pasado.
Linux con Intel Omni Path (o su predecesor, True Scale): He usado MVAPICH2, Intel MPI, MPICH y Open-MPI en dichos sistemas, y todos están funcionando. Intel MPI tiende a los más optimizados, mientras que Open-MPI ofrece el mejor rendimiento de las implementaciones de código abierto porque tienen un PSM2 bien optimizado back-end basado en . Tengo algunas notas sobre GitHub sobre cómo construir diferentes implementaciones de código abierto, pero esa información se vuelve obsoleta bastante rápido.
Supercomputadoras Cray o IBM: MPI viene instalado en estas máquinas automáticamente y se basa en MPICH en ambos casos. Ha habido demostraciones de MPICH en Cray XC40 ( aquí ) usando OFI , Intel MPI en Cray XC40 ( aquí ) usando OFI, MPICH en Blue Gene / Q usando OFI ( aquí ) y Open-MPI en Cray XC40 usando OFI y uGNI ( aquí ), pero ninguno de estos son compatibles con el proveedor.
Windows: no veo ningún punto en ejecutar MPI en Windows excepto a través de una VM Linux, pero tanto Microsoft MPI como Intel MPI son compatibles con Windows y están basados en MPICH. He escuchado informes de compilaciones exitosas de MPICH o Open-MPI utilizando Windows Subsystem para Linux, pero no tengo experiencia personal.
Notas
En total divulgación, actualmente trabajo para Intel en una capacidad de investigación / búsqueda de ruta (es decir, no trabajo en ningún producto de software Intel) y anteriormente trabajé para Argonne National Lab durante cinco años, donde colaboré ampliamente con el equipo MPICH.