Personalmente elegimos OpenMPI como nuestra implementación de MPI. Para nosotros, se comparó mejor y la portabilidad no fue un gran problema. Vea el enlace de preguntas que Taylor L publicó.
Xorlev
1
También puede considerar que en las tendencias de Google, OpenMPI es 2-3 veces más buscado que MPICH / MPICH2.
Foad
Creo que MPICH ya no es compatible con las versiones recientes de Linux (por ejemplo, Ubuntu 18 no puede ejecutarlo), IIRC solo funciona en ciertas versiones del kernel
jrh
Respuestas:
148
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.
Es posible que OpenMPI tenga un soporte superior para la memoria compartida en colectivos, pero necesito investigar a fondo antes de actualizar mi respuesta.
Jeff
2
¿Puede explicar por qué no tiene sentido ejecutar MPI en Windows?
Dmitri Nesteruk
3
No, pero siéntase a hacer una nueva pregunta en StackOverflow sobre HPC en Windows.
Jeff
@Jeff, resaltaste el MPI_THREAD_MULTIPLEen la respuesta, pero no tengo experiencia real para usarlo antes. ¿Podría dar algunos casos / ejemplos de usuarios en los que MPI_THREAD_MULTIPLEsea útil y eficiente en comparación con otros modos como MPI THREAD FUNNELED? Mi primera impresión es que esta función hace que el programa sea más complejo y difícil de depurar entre el hilo y el proceso. Gracias.
Patric
1
Solo una nota de que Open-MPI ahora se compila y funciona bien en el Subsistema de Windows para Linux, supongo que mpich también.
jawknee
12
Si realiza el desarrollo en lugar del sistema de producción, vaya con MPICH. MPICH tiene depurador incorporado, mientras que Open-MPI no dura la última vez que lo verifiqué.
En producción, Open-MPI probablemente será más rápido. Pero es posible que desee investigar otras alternativas, como Intel MPI.
No estoy seguro de lo que quiere decir con depurador incorporado, pero encuentro que Open-MPI tiene una buena integración con, por ejemplo, gdb: open-mpi.org/faq/?category=debugging .
Jeff
Para la producción, ¿hay alguna idea sobre el uso de MPICH con TAO?
namu
10
Estoy de acuerdo con el póster anterior. Pruebe ambos para ver cuál funciona su aplicación más rápido y luego úselo para producción. Ambos cumplen con los estándares. Si es tu escritorio tampoco está bien. OpenMPI sale de la caja en Macbooks, y MPICH parece ser más compatible con 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 su topología de red. Configurarlo en un clúster de producción será la principal diferencia en términos de su tiempo, ya que tendrá que usar RTFM.
@ Jeff Um, ¿qué pasa con los errores? ¿Documentos desactualizados? Eso está detrás de una pluralidad de mis (cientos de ...) preguntas aquí;)
javadba
6
Ambos cumplen con los estándares, por lo que no debería importar cuál use desde el punto de vista de la corrección. A menos que exista alguna característica, como extensiones de depuración específicas, que necesite, luego compare ambas y elija la que sea más rápida para sus aplicaciones en su hardware. También considere que hay otras implementaciones de MPI que podrían brindar un mejor rendimiento o compatibilidad, como MVAPICH (puede tener el mejor rendimiento de 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 va después de ser vendido a la Plataforma ...
Desde mi experiencia, una buena característica que admite OpenMPI pero MPICH no es la afinidad de proceso . Por ejemplo, en OpenMPI, usando -npersocketpuede establecer el número de rangos lanzados en cada socket. Además, OpenMPI rankfilees bastante útil cuando desea identificar rangos para núcleos o suscribirse en exceso.
Por último, si necesita controlar la asignación de rangos a núcleos, definitivamente sugeriría escribir y compilar su código usando OpenMPI.
Respuestas:
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 integralMPI_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 peroLD_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
mpirunompiexec, 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:
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.
fuente
MPI_THREAD_MULTIPLEen la respuesta, pero no tengo experiencia real para usarlo antes. ¿Podría dar algunos casos / ejemplos de usuarios en los queMPI_THREAD_MULTIPLEsea útil y eficiente en comparación con otros modos comoMPI THREAD FUNNELED? Mi primera impresión es que esta función hace que el programa sea más complejo y difícil de depurar entre el hilo y el proceso. Gracias.Si realiza el desarrollo en lugar del sistema de producción, vaya con MPICH. MPICH tiene depurador incorporado, mientras que Open-MPI no dura la última vez que lo verifiqué.
En producción, Open-MPI probablemente será más rápido. Pero es posible que desee investigar otras alternativas, como Intel MPI.
fuente
Estoy de acuerdo con el póster anterior. Pruebe ambos para ver cuál funciona su aplicación más rápido y luego úselo para producción. Ambos cumplen con los estándares. Si es tu escritorio tampoco está bien. OpenMPI sale de la caja en Macbooks, y MPICH parece ser más compatible con 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 su topología de red. Configurarlo en un clúster de producción será la principal diferencia en términos de su tiempo, ya que tendrá que usar RTFM.
fuente
Ambos cumplen con los estándares, por lo que no debería importar cuál use desde el punto de vista de la corrección. A menos que exista alguna característica, como extensiones de depuración específicas, que necesite, luego compare ambas y elija la que sea más rápida para sus aplicaciones en su hardware. También considere que hay otras implementaciones de MPI que podrían brindar un mejor rendimiento o compatibilidad, como MVAPICH (puede tener el mejor rendimiento de 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 va después de ser vendido a la Plataforma ...
fuente
Desde mi experiencia, una buena característica que admite OpenMPI pero MPICH no es la afinidad de proceso . Por ejemplo, en OpenMPI, usando
-npersocketpuede establecer el número de rangos lanzados en cada socket. Además, OpenMPIrankfilees bastante útil cuando desea identificar rangos para núcleos o suscribirse en exceso.Por último, si necesita controlar la asignación de rangos a núcleos, definitivamente sugeriría escribir y compilar su código usando OpenMPI.
fuente