2010-06-03 15 views
6

¿.net 4.0 Task Parallel Library reemplaza MPI.NET para cálculos de alto rendimiento?.net 4.0 Task Parallel Library vs. MPI.NET

MPI.NET que se encuentra aquí http://www.osl.iu.edu/research/mpi.net/svn/ es una implementación de alto rendimiento y fácil de usar de la interfaz de paso de mensajes (MPI) para el entorno .NET de Microsoft. MPI es el estándar de facto para escribir programas paralelos que se ejecutan en un sistema de memoria distribuida, como un clúster de cálculo.

.NET 4 TPL dice: "La Biblioteca paralela de tareas (TPL) es un conjunto de tipos públicos y API en los espacios de nombres System.Threading y System.Threading.Tasks en .NET Framework versión 4. El propósito del TPL es para hacer que los desarrolladores sean más productivos al simplificar el proceso de agregar paralelismo y concurrencia a las aplicaciones. El TPL escala el grado de concurrencia de manera más eficiente para usar todos los procesadores disponibles. Además, el TPL maneja la partición del trabajo. la programación de subprocesos en ThreadPool, soporte de cancelación, administración de estado y otros detalles de bajo nivel. Al usar TPL, puede maximizar el rendimiento de su código mientras se enfoca en el trabajo que su programa está diseñado para lograr ".

Mi objetivo es crear una aplicación que se pueda ejecutar en Windows HPC 2008 ... ¿qué camino tomar?

Respuesta

2

La transmisión de mensajes es una forma diferente de abordar la idea de la programación paralela. Axum y Erlang usan el mensaje de pase. Realmente no son comparables directamente, ya que ambos abordan dos implementaciones específicas.

El beneficio que he visto con la transmisión de mensajes es que los límites de red/proceso pueden hacerse transparentes y el mensaje que pasa no se basa en subprocesos subyacentes (todos los mensajes y actores pueden estar en un hilo).

El TPL, desde mi comprensión limitada, está ahí para construir sobre/reemplazar/mejorar mucho el modelo actual de subprocesamiento en .NET, es decir, tiene subprocesos reales que usted controla y se comunica transfiriendo argumentos o usando estado compartido.

Si es desde el principio, y los trajes de diseño se dividen en segmentos muy pequeños de código, entonces sugeriría MPI.NET. Si el tipo de trabajo es intensivo en la CPU (como el trabajo matemático) sugeriría la ruta TPL.

Editar: largo tiempo de edición, esta respuesta es viejo! MPI.NET se adapta directamente a HPC ya que hace que los límites de comunicación de los nodos de HPC sean transparentes y configurables. MPI.NET envía mensajes a puntos finales; estos son puntos que se definen como direcciones IP/Puerto en archivos de configuración. El código no sabe que un punto final cruza un límite de red.

Si opta por TPL en HPC (no estoy seguro si es compatible), creo que su código tendrá que conocer los nodos y cómo transportar el procesamiento de uno a otro, para que no obtenga ningún beneficio.

+0

¿Entonces sugiere MPI.NET para aplicaciones HPC? –

+0

Eche un vistazo por favor http://resourcekit.windowshpc.net/MORE_INFO/SeqToParallelHPC.html –

+0

Hola jalchr, lamentablemente no es tan simple. Si está realizando un levantamiento matemático pesado (es decir, estrangulará un hilo en particular) opte por el TPL, es un buen marco para enhebrar en el modelo estándar. La única área beneficiosa para MPI.NET (bueno, Axum para mí) es actualmente una red, donde los actores pueden escuchar en los puertos de red sin consumir CPU. El MPI.NET no sería muy adecuado. –

6

Según tengo entendido, TPL no admite la informática distribuida mientras que MPI.NET sí.

Cuestiones relacionadas