2010-05-21 18 views
10

Soy nuevo en la plataforma .Net. Hice una búsqueda y encontró que hay varias maneras de hacer el cómputo paralelo en .Net:Tecnologías paralelas disponibles en .Net

  1. tarea paralela en la Tarea Parallel Library, que es Net 3.5.

  2. PLINQ, .Net 4.0

  3. Programación Asynchounous, .Net 2.0, (asíncrono se utiliza principalmente para hacer de E/S tareas pesadas, F # tiene una sintaxis concisa apoyo a esta). Enumero esto porque en Mono, parece que no hay TPL o PLINQ. Por lo tanto, si necesito escribir programas paralelos de plataforma cruzada, puedo usar async.

  4. .hilos .Net. Sin limitación de versión.

¿Podría dar algunos breves comentarios sobre estos o agregar más métodos en esta lista? Gracias.

+1

Algunos enlaces útiles para los datos en bruto: http://msdn.microsoft.com/en-us/concurrency/ee851578.aspx http://channel9.msdn.com/shows/The + Knowledge + Chamber/Multi-Core-and-Parallel-Programming-Practices/ http://blogs.msdn.com/pfxteam/rss.xml – Brian

+0

Bueno, PLINQ/'Parallel' es definitivamente el más fácil de usar, pero no aplicable en todas las situaciones –

Respuesta

16

Necesita hacer una buena cantidad de investigación para determinar cómo hacer multihebras efectivamente. Hay algunos buenos technical articles, parte del Microsoft Parallel Computing team's site.

De la parte superior de mi cabeza, hay varias maneras de ir sobre multihilo:

  1. Thread clase.
  2. ThreadPool, que también tiene soporte para operaciones vinculadas a E/S y un puerto de finalización de E/S.
  3. Begin*/End* operaciones asincrónicas.
  4. Componentes de programación asincrónica basada en eventos (o "EBAP"), que usan SynchronizationContext.
  5. BackgroundWorker, que es un EBAP que define una operación asincrónica.
  6. Task clase (Biblioteca de tareas paralelas) en .NET 4.
  7. Paralelo LINQ. Hay un good article en Parallel.ForEach (Task Parallel Library) contra PLINQ.
  8. Rx o "LINQ to Events", que aún no tiene una versión que no sea Beta, pero está a punto de completarse y parece prometedor.
  9. (solo F) Flujos de trabajo asincrónicos.

Actualización: Hay un artículo Understanding and Applying Parallel Patterns with the .NET Framework 4 disponible para su descarga que le da una cierta dirección en la que las soluciones a utilizar para qué tipos de escenarios paralelos (aunque se supone .NET 4 y no cubre Rx).

+1

+1 para una lista extensa –

3

También existe la Reactive Extensions for .NET (Rx)

Rx es básicamente consultas LINQ para eventos. Le permite procesar y combinar flujos de datos asincrónicos de la misma manera que linq le permite trabajar con colecciones. Por lo tanto, probablemente lo utilice junto con otras tecnologías paralelas como una forma de reunir los resultados de sus operaciones paralelas sin tener que preocuparse por los bloqueos y otras primitivas de subprocesamiento de bajo nivel.

Expert to Expert: Brian Beckman and Erik Meijer - Inside the .NET Reactive Framework (Rx) ofrece una buena visión general de lo que se trata Rx.

EDIT: Otra biblioteca vale la pena mencionar es el de concurrencia y coordinación en tiempo de ejecución (CCR), que ha estado presente durante mucho tiempo (antes de lo '06) y es enviado como parte de la Microsoft Robotics Studio.

Rx tiene muchas de las mismas ideas geniales que el CCR tiene dentro, pero con una API mucho mejor en mi opinión. Todavía hay algunas cosas interesantes en el CCR, así que podría valer la pena echarle un vistazo. También hay un marco de servicios distribuidos que funciona con el CCR que podría ser útil dependiendo de lo que esté haciendo.

Expert to Expert: Meijer and Chrysanthakopoulos - Concurrency, Coordination and the CCR

+0

No tengo ni idea de cómo logré obtener un voto a favor de esto, Rx hace que la programación paralela sea mucho más fácil en algunas situaciones, la uso mucho. –

+0

+1 por ser el primero en mencionar Rx. ;) –

+0

@Mauricio están muy relacionados, ejecutar todo en paralelo es inútil si no puede coordinar sus resultados. Está claro por la pregunta que el OP también está interesado en este aspecto. Afirma que "F # tiene una sintaxis concisa que respalda esto", en referencia a la mónada de continuación, Rx es esencialmente la mónada de continuación para todos los lenguajes .NET compatibles con LINQ. –

2

Uno más es la nueva biblioteca de tareas en paralelo .NET 4.0, que es similar y en la línea de lo que ya has descubierto, pero esto puede ser una lectura interesante:

Task Parallel Library

11

Estrictamente hablando, la distinción entre paralelo, asincrónico y concurrente debe hacerse aquí.

Paralelo significa que una "tarea" se divide entre varias subtareas menores que se pueden ejecutar al mismo tiempo. Esto requiere una CPU multinúcleo o una computadora con varias CPU, donde cada tarea tiene su núcleo o CPU dedicado. O múltiples computadoras. PLINQ (paralelismo de datos) y TPL (paralelismo de tareas) entran en esta categoría.

Asincrónico significa que las tareas se ejecutan sin bloquearse entre sí. La expresión asíncrona de F #, Rx, patrón de inicio/fin son todas las API para programación asíncrona.

La concurrencia es un concepto más amplio que la paralelización y la asincronía. Concurrencia significa que varias "tareas" se ejecutan al mismo tiempo, interactuando entre sí. Pero estas "tareas" no tienen que ejecutarse en unidades de computación físicas separadas, como se entiende en la paralelización. Por ejemplo, los sistemas operativos multitarea pueden ejecutar múltiples procesos al mismo tiempo, incluso en equipos de una sola CPU de un solo núcleo, utilizando intervalos de tiempo. La concurrencia se puede lograr, por ejemplo, con el modelo Actor y el envío de mensajes (por ejemplo, buzón de F #, procesos de Erlang (Retlang en .Net))

Los hilos son un concepto relativamente bajo en comparación con los conceptos anteriores. Los subprocesos son tareas que se ejecutan dentro de un proceso, se ejecutan simultáneamente y son administrados directamente por el programador del sistema operativo. Puede implementar la paralelización cuando el sistema operativo asigna cada subproceso a un núcleo separado, o un modelo Actor implementando cola de mensajes, enrutamiento, etc. en cada subproceso.

+1

Publico esto como wiki comunitario para que otros puedan corregir y refinar mi definiciones ... –

4

También hay algunas bibliotecas .NET para los datos de programación paralela que se dirigen a la unidad de procesamiento gráfico (GPU) incluyendo:

Microsoft Accelerator es para la programación paralela de datos y puede apuntar bien la GPU o procesadores de múltiples núcleos.

Brama es para transformaciones de datos de estilo LINQ que se ejecutan en la GPU.

CUDA.NET proporciona un contenedor para permitir que CUDA se use desde programas .NET.

-1

dos formas principales de hacer paralelo son los hilos y la nueva biblioteca basada en tareas TPL.

La programación asincrónica que menciona no es más que un nuevo hilo en el grupo de hilos.

PLINQ, Rx y otros mencionados son en realidad extensiones que se encuentran en la parte superior del nuevo planificador de tareas.

el mejor artículo explicando exactamente la nueva arquitectura para el nuevo planificador de tareas y todas las bibliotecas en la parte superior, Visual Studio 2010 y el nuevo TPL .NET 4.0 Paralelismo basado en tareas está aquí (por Steve Teixeira, Product Unit Manager for Parallel Herramientas de Desarrollo de Microsoft):

http://www.drdobbs.com/visualstudio/224400670

lo contrario Dr. Dobbs ha dedicado sección de programación paralela aquí: http://www.drdobbs.com/go-parallel/index.jhtml

La principal diferencia entre los hilos decir y nueva tarea basada en la programación paralela es que no es necesario pensar una Además, en cuanto a los hilos, ¿cómo gestiona los conjuntos y el sistema operativo subyacente y el hardware? TPL se ocupa de que solo use tareas. Ese es un gran cambio en la forma en que haces paralelo en cualquier nivel, incluida la abstracción.

Así que en realidad .NET no tiene muchas opciones:

  1. Tema
  2. Nueva tarea basada, programador de tareas.

Obviamente, la tarea se basa en el camino a seguir.

aplausos Valko

Cuestiones relacionadas