mpi - para - que es el grid
Óxido en la computación grid (2)
Estoy buscando crear implementaciones de Rust de algunos pequeños programas bioinformáticos para mi investigación. Una de mis principales consideraciones es el rendimiento, y aunque sé que puedo programar el programa Rust para que se ejecute en una grilla con qsub, el clúster al que tengo acceso usa GridEngine de Oracle, me preocupa que no llame. MPI directamente causará problemas de rendimiento con el programa Rust.
¿Programar el programa sin utilizar una biblioteca MPI dificulta enormemente el rendimiento? ¿Debo usar una biblioteca MPI en Rust, y si es así, hay alguna biblioteca MPI conocida para Rust? He buscado uno pero no he encontrado nada.
¿Programar el programa sin utilizar una biblioteca MPI dificulta enormemente el rendimiento?
Hay muchas maneras de llevar a cabo la computación paralela. MPI es uno, y como los comentarios a su pregunta indican que puede llamar a MPI de Rust con un poco de gimnasia.
Pero hay otros enfoques, como la familia PGAS (Chapel, OpenSHMEM, Co-array Fortran) o mensajes alternativos como lo que usa Charm ++.
MPI está "simplemente" proporcionando una abstracción de mensajes (muy útil, altamente portátil, optimizada agresivamente), pero mientras tenga alguna forma de administrar el paralelismo, puede ejecutar cualquier cosa en un clúster.
He utilizado varias instalaciones de supercomputación (soy astrofísico) y muchas veces he tenido el mismo problema: conozco muy bien C / C ++ pero prefiero trabajar con otros idiomas.
En general, cualquier enfoque que no sea MPI servirá, pero considere que a menudo dichos superordenadores tienen bibliotecas MPI muy optimizadas, a menudo diseñadas para el hardware específico integrado en el clúster. Es difícil decir cuánto se verá afectado el rendimiento de sus programas de Rust si no usa MPI, pero la apuesta más segura es permanecer con la implementación de MPI proporcionada en el clúster.
No existe una penalización de rendimiento al usar un contenedor Rust alrededor de una biblioteca C como una biblioteca MPI, ya que el cuello de botella es el tiempo necesario para transferir datos (por ejemplo, a través de un MPI_Send) entre nodos, no el costo insignificante de una llamada de función adicional. (Además, este no es el caso de Rust: no hay una llamada de función adicional, como ya se ha comentado anteriormente).
Sin embargo, a pesar del muy buen FFI proporcionado por Rust, no será fácil crear enlaces MPI. El problema radica en el hecho de que MPI no es una biblioteca, sino una especificación. Las bibliotecas populares de MPI son OpenMPI ( http://www.open-mpi.org ) y MPICH ( http://www.mpich.org ). Cada uno de ellos difiere ligeramente en la forma en que implementan el estándar, y generalmente cubren tales diferencias utilizando macros de preprocesador de C. Muy pocas IFF pueden tratar macros complejas; No sé cómo puntajes Rust aquí.
Como ejemplo, estoy implementando un programa MPI en Free Pascal pero no he podido usar los enlaces MPICH existentes ( http://wiki.lazarus.freepascal.org/MPICH ), ya que el clúster que estoy utilizando proporciona su propio MPI biblioteca y prefiero usar esta por la razón indicada anteriormente. No pude reutilizar los enlaces MPICH, ya que suponían que las constantes como MPI_BYTE eran constantes enteras codificadas. Pero en mi caso son punteros a estructuras opacas que parecen crearse cuando se llama a MPI_Init.
Los enlaces de Julia a MPI ( https://github.com/lcw/MPI.jl ) resuelven este problema ejecutando los programas C y Fortran durante la instalación que generan el código Julia con los valores correctos para dichas constantes. Véase, por ejemplo, https://github.com/lcw/MPI.jl/blob/master/deps/make_f_const.f
En mi caso, preferí implementar un middleware, es decir, una pequeña biblioteca C que envuelve las llamadas MPI con una interfaz más "predecible". (Esto es más o menos lo que hacen también las vinculaciones de Python y Ocaml, consulte https://forge.ocamlcore.org/projects/ocamlmpi/ y http://mpi4py.scipy.org .) Las cosas funcionan sin problemas, hasta ahora no tengo ningún problema