¿Por qué se considera que MPI es más difícil que la memoria compartida y que Erlang se considera más fácil cuando ambos transmiten mensajes?

StackOverflow https://stackoverflow.com/questions/185444

Pregunta

Hay mucho interés en estos días en Erlang como lenguaje para escribir programas paralelos en multinúcleo. He escuchado a personas argumentar que el modelo de paso de mensajes de Erlang es más fácil de programar que los modelos dominantes de memoria compartida, como los hilos.

Por el contrario, en la comunidad informática de alto rendimiento, el modelo de programación paralela dominante ha sido MPI, que también implementa un modelo de paso de mensajes. Pero en el mundo de HPC, este modelo de transmisión de mensajes generalmente se considera muy difícil de programar, y la gente argumenta que los modelos de memoria compartida como OpenMP o UPC son más fáciles de programar.

¿Alguien sabe por qué hay tanta diferencia en la percepción de pasar mensajes frente a la memoria compartida en los mundos de TI y HPC? ¿Se debe a alguna diferencia fundamental en cómo Erlang y MPI implementan el paso de mensajes que hace que el paso de mensajes al estilo Erlang sea mucho más fácil que MPI? ¿O hay alguna otra razón?

¿Fue útil?

Solución

Estoy de acuerdo con todas las respuestas anteriores, pero creo que un punto clave que no se deja totalmente claro es que una de las razones por las que MPI podría considerarse difícil y Erlang fácil es la coincidencia del modelo con el dominio.

Erlang se basa en un concepto de memoria local, transmisión de mensajes asíncronos y estado compartido resuelto mediante el uso de alguna forma de base de datos global a la que pueden acceder todos los subprocesos. Está diseñado para aplicaciones que no mueven una gran cantidad de datos, y no se supone que explote a 100k nodos separados que necesitan coordinación.

MPI se basa en la memoria local y el paso de mensajes, y está destinado a problemas en los que mover datos es una parte clave del dominio. La informática de alto rendimiento se trata principalmente de tomar el conjunto de datos para un problema y dividirlo entre una gran cantidad de recursos informáticos. Y eso es un trabajo bastante duro en un sistema de transmisión de mensajes, ya que los datos deben distribuirse explícitamente teniendo en cuenta el equilibrio. Esencialmente, MPI se puede ver como una admisión de mala gana que la memoria compartida no escala. Y apunta a la computación de alto rendimiento distribuida en procesadores de 100k o más.

Erlang no está tratando de lograr el mayor rendimiento posible, sino de descomponer un problema paralelo natural en sus hilos naturales. Fue diseñado con un tipo totalmente diferente de tareas de programación en mente en comparación con MPI.

Entonces Erlang se compara mejor con pthreads y otras soluciones de hilos heterogéneas más bien locales, en lugar de MPI, que realmente está dirigido a un conjunto de problemas muy diferente (y hasta cierto punto inherentemente más difícil).

Otros consejos

El paralelismo en Erlang sigue siendo bastante difícil de implementar. Con eso quiero decir que todavía tiene que descubrir cómo dividir su problema, pero hay algunas cosas menores que alivian esta dificultad en comparación con alguna biblioteca MPI en C o C ++.

Primero, dado que el paso de mensajes de Erlang es una característica de lenguaje de primera clase, el azúcar sintáctico lo hace sentir más fácil.

Además, las bibliotecas de Erlang están construidas alrededor del paso de mensajes de Erlang. Esta estructura de soporte le ayuda a impulsar el procesamiento en paralelo de la tierra. Eche un vistazo a los componentes de OTP como gen_server, gen_fsm, gen_event. Estas son estructuras muy fáciles de usar que pueden ayudar a que su programa se vuelva paralelo.

Creo que es más la robustez de la biblioteca estándar disponible que diferencia el mensaje de erlang que pasa de otras implementaciones de MPI, no realmente ninguna característica específica del lenguaje en sí.

Por lo general, la concurrencia en HPC significa trabajar en grandes cantidades de datos. Este tipo de paralelismo se llama paralelismo de datos y de hecho es más fácil de implementar usando un enfoque de memoria compartida como OpenMP , porque el sistema operativo se ocupa de cosas como la programación y la colocación de tareas, que uno tendría que implementar uno mismo si usa un paradigma de paso de mensajes.

En contraste, Erlang fue diseñado para hacer frente al paralelismo de tareas que se encuentra en los sistemas telefónicos, donde es diferente las piezas de código deben ejecutarse simultáneamente con solo una cantidad limitada de comunicación y requisitos estrictos para la tolerancia y recuperación de fallas.

Este modelo es similar al que usa la mayoría de las personas PThreads. Se adapta a aplicaciones como servidores web, donde cada solicitud puede ser manejada por un hilo diferente, mientras que las aplicaciones HPC hacen más o menos lo mismo en grandes cantidades de datos que también deben intercambiarse entre los trabajadores.

Creo que tiene algo que ver con la mentalidad cuando estás programando con MPI y cuando estás programando con Erlang. Por ejemplo, MPI no está integrado en el lenguaje, mientras que Erlang tiene soporte incorporado para pasar mensajes. Otra posible razón es la desconexión entre simplemente enviar / recibir mensajes y particionar soluciones en unidades concurrentes de ejecución.

Con Erlang, se ve obligado a pensar en un marco de programación funcional en el que los datos realmente pasan de una llamada a otra a la función, y recibir es un acto activo que parece una construcción normal en el lenguaje. Esto le brinda una conexión más estrecha entre el cálculo que realmente está realizando y el acto de enviar / recibir mensajes.

Con MPI, por otro lado, se ve obligado a pensar simplemente en el mensaje real que pasa, pero no en la descomposición del trabajo. Este marco de pensamiento requiere un cambio de contexto entre escribir la solución y la infraestructura de mensajería en su código.

La discusión puede continuar, pero la opinión común es que si la construcción para el paso de mensajes está realmente integrada en el lenguaje de programación y el paradigma que está utilizando, por lo general, ese es un mejor medio para expresar la solución en comparación con otra cosa que sea " agregado a " o existe como complemento de un idioma (en forma de biblioteca o extensión).

  

¿Alguien sabe por qué hay tanta diferencia en la percepción de pasar mensajes frente a la memoria compartida en los mundos de TI y HPC? ¿Se debe a alguna diferencia fundamental en cómo Erlang y MPI implementan el paso de mensajes que hace que el paso de mensajes al estilo Erlang sea mucho más fácil que MPI? ¿O hay alguna otra razón?

La razón es simplemente paralelismo versus concurrencia. Erlang es criado para la programación concurrente. HPC tiene que ver con la programación paralela. Estos son objetivos relacionados pero diferentes.

La programación concurrente es muy complicada por un flujo de control muy no determinista y la latencia es a menudo un objetivo importante. El uso de Erlang de estructuras de datos inmutables simplifica enormemente la programación concurrente.

La programación paralela tiene un flujo de control mucho más simple y el objetivo es el rendimiento total máximo y no la latencia. El uso eficiente de la memoria caché es mucho más importante aquí, lo que hace que tanto Erlang como las estructuras de datos inmutables sean en gran medida inadecuadas. La mutación de la memoria compartida es manejable y sustancialmente mejor en este contexto. En efecto, la coherencia de la memoria caché le proporciona mensajes acelerados por hardware.

Finalmente, además de estas diferencias técnicas, también hay un problema político. Los chicos de Erlang están tratando de montar el bombo multinúcleo al pretender que Erlang es relevante para multinúcleo cuando no lo es. En particular, están promocionando una gran escalabilidad, por lo que también es esencial tener en cuenta el rendimiento absoluto. Erlang escala sin esfuerzo de pobre rendimiento absoluto en un núcleo a pobre rendimiento absoluto en cualquier número de núcleos. Como puede imaginar, eso no impresiona a la comunidad HPC (pero es adecuado para una gran cantidad de código muy concurrente).

Con respecto a MPI vs OpenMP / UPC: MPI lo obliga a cortar el problema en pedazos pequeños y asumir la responsabilidad de mover los datos. Con OpenMP / UPC, "todos los datos están ahí", solo tiene que desreferenciar un puntero. La ventaja de MPI es que los grupos de CPU 32-512 son mucho más baratos que las máquinas individuales de CPU 32-512. Además, con MPI el gasto es por adelantado, cuando diseñas el algoritmo. OpenMP / UPC puede ocultar las latencias que obtendrá en tiempo de ejecución, si su sistema usa NUMA (y todos los sistemas grandes lo hacen): su programa no escalará y tomará un tiempo descubrir por qué.

Este artículo en realidad lo explica bien, Erlang es mejor cuando enviamos pequeños datos y MPI funciona mucho mejor en cosas más complejas. Además, el modelo Erlang es fácil de entender :-)

Erlang Versus MPI - Resultados finales y código fuente

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top