2008-10-09 14 views
31

En estos días, hay un gran interés en Erlang como lenguaje para escribir programas paralelos en multinúcleo. He escuchado a la gente decir 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 qué se considera que MPI es más difícil que la memoria compartida y Erlang lo considera más fácil, cuando ambos pasan mensajes?

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 paso de mensajes generalmente se considera muy difícil de programar, y las personas argumentan que los modelos de memoria compartida como OpenMP o UPC son más fáciles de programar.

¿Alguien sabe por qué hay tal diferencia en la percepción de la transmisión de mensajes vs. memoria compartida en los mundos de TI y HPC? ¿Se debe a alguna diferencia fundamental en la forma en que Erlang y MPI implementan el paso de mensajes que hace que el envío de mensajes al estilo Erlang sea mucho más fácil que MPI? ¿O hay alguna otra razón?

+0

lo encuentro el MPI opuesto y Earlang son más fáciles que la memoria compartida! – pyCthon

Respuesta

36

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

Erlang se basa en un concepto de memoria local, paso de mensajes asíncronos y estado compartido resuelto mediante el uso de alguna forma de base de datos global que puede acceder a todos los subprocesos. Está diseñado para aplicaciones que no mueven una gran cantidad de datos, y se supone que no debe explotar en un nodo separado de 100k que necesita coordinación.

MPI se basa en la memoria local y la transmisión de mensajes, y está destinado a problemas donde el movimiento de datos es una parte clave del dominio. La informática de alto rendimiento se trata de tomar el conjunto de datos para un problema y dividirlo entre una gran cantidad de recursos informáticos. Y ese es un trabajo bastante difícil en un sistema de transmisión de mensajes ya que los datos deben distribuirse explícitamente teniendo en cuenta el equilibrio. Básicamente, MPI puede verse como una admisión de mala gana de que la memoria compartida no se 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 rendimiento más alto posible, en lugar de descomponer un problema naturalmente paralelo en sus hilos naturales. Fue diseñado con un tipo de tareas de programación totalmente diferente en mente en comparación con MPI.

Por lo tanto, Erlang se compara mejor con pthreads y otras soluciones de subprocesos heterogéneos bastante locales, en lugar de MPI, que realmente apunta a un conjunto de problemas muy diferentes (y hasta cierto punto inherentemente más difíciles).

0

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

+0

Entiendo este argumento, pero ¿por qué eso no se aplica a Erlang vs. OpenMP? ¿Todavía no tienes que dividir tu problema con Erlang? –

12

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 cuando se compara con alguna biblioteca de MPI en C o C++.

En primer lugar, como 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 se basan en la transmisión de mensajes de Erlang. Esta estructura de soporte te ayuda a impulsarte en la tierra de procesamiento paralelo. Eche un vistazo al components of 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 solidez 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í.

8

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 integrado para el envío de mensajes. Otra posible razón es la desconexión entre simplemente enviar/recibir mensajes y soluciones de división en unidades de ejecución concurrentes.

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

Con MPI, por otro lado, se ve obligado a pensar simplemente en el mensaje 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 visión común es que si el constructo para el envío de mensajes está integrado en el lenguaje de programación y el paradigma que está utilizando, generalmente es una mejor forma de expresar la solución en comparación con otra cosa está "pegado" o existe como complemento de un idioma (en forma de biblioteca o extensión).

4

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

El motivo es simplemente el paralelismo frente a la concurrencia. Erlang es criado para programación concurrente. HPC tiene que ver con la programación paralela. Estos son objetivos relacionados pero diferentes.

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

La programación en paralelo tiene un flujo de control mucho más simple y el objetivo es el máximo rendimiento total y no 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 tanto tratable como sustancialmente mejor en este contexto. En efecto, la coherencia de la memoria caché le proporciona un pase de mensajes acelerado por hardware.

Finalmente, además de estas diferencias técnicas, también existe un problema político. Los chicos de Erlang están tratando de entusiasmarse con el multicore simulando que Erlang es relevante para multinúcleo cuando no lo es. En particular, están promocionando una gran escalabilidad por lo que es esencial considerar el rendimiento absoluto también. Erlang puede escalar fácilmente desde un desempeño absoluto pobre en un núcleo hasta un desempeño absoluto pobre en cualquier número de núcleos.Como se puede imaginar, eso no impresiona a la comunidad HPC (pero es adecuada para una gran cantidad de código concurrente).

9

Normalmente, la concurrencia en HPC significa trabajar en grandes cantidades de datos. Este tipo de paralelismo se llama data parallelism y de hecho es más fácil de implementar usando un enfoque de memoria compartida como OpenMP, porque el sistema operativo se encarga de tareas como la programación y la ubicación de tareas, que uno debería implementar si se usa un paradigma de paso de mensajes.

Por el contrario, Erlang fue diseñado para hacer frente a task parallelism encontrado en sistemas telefónicos, donde diferentes piezas de código deben ejecutarse simultáneamente con solo una cantidad limitada de comunicación y requisitos estrictos para tolerancia a fallas y recuperación.

Este modelo es similar a lo que la mayoría de las personas usa PThreads. Se adapta a aplicaciones como servidores web, donde cada solicitud puede manejarse con 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.

0

Este artículo realmente lo explica bien, Erlang es mejor cuando estamos enviando pequeños fragmentos de datos y MPI lo hace mucho mejor en cosas más complejas. También El modelo de Erlang es fácil de entender :-)

Erlang Versus MPI - Final Results and Source Code

Cuestiones relacionadas