¿Por qué no debería usar F # flujos de trabajo asíncronos para el paralelismo?

Question

He estado aprendiendo F # recientemente, estando particularmente interesado en su facilidad para explotar el paralelismo de datos. La expresión data |> Array.map |> Async.Parallel |> Async.RunSynchronously parece muy fácil de entender y de usar y obtener un valor real.

¿Por qué es que async no está pensado para esto? Donald Syme himself dice que PLINQ y Futuros son probablemente una mejor opción. Y otras respuestas que he leído aquí concuerdan con eso y también recomiendan TPL. (PLINQ no parece ser demasiado diferente a las funciones integradas anteriores, siempre y cuando utilice el F # Powerpack para obtener las funciones PSeq).

F # y los lenguajes funcionales tienen mucho sentido para esto, y some applications han logrado un gran éxito con el paralelismo async.

¿Por qué no debería Yo uso async para ejecutar procesos de datos paralelos? ¿Qué voy a perder escribiendo el código paralelo async en lugar de usar PLINQ o TPL?

Answer 1

Escribí un artículo que implementa una muestra de C# TPL utilizando Task y Async, que también tiene algunos comentarios sobre la diferencia entre los dos. Puede find it here y también hay un más advanced async-based version.

Aquí es una cita del primer artículo que compara las dos opciones:

La elección entre las dos implementaciones posibles depende de muchos factores. Los flujos de trabajo asincrónicos se diseñaron específicamente para F #, por lo que se ajustan mejor al lenguaje. Ofrecen un mejor rendimiento para las tareas vinculadas de E/S y proporcionan un manejo de excepciones más conveniente. Además, la sintaxis secuencial es bastante conveniente. Por otro lado, las tareas se optimizan para los cálculos de CPU vinculados y hacen que sea más fácil acceder al resultado del cálculo desde otros lugares de la aplicación sin caché explícito.

Answer 2

Siempre pensé que es lo que TPL, PLinq, etc ... le da más de lo que hace Async. (Los mecanismos de cancelación es lo que viene a la mente.) This question tiene algunas respuestas mejores.

Este artículo hace alusión a slight performance advantage a TPL, pero probablemente no lo suficiente como para ser significativo.

Answer 3

¿Por qué no debería usar async para ejecutar procesos de datos paralelos?

Si usted tiene un pequeño número de totalmente independientes no async tareas y una gran cantidad de núcleos entonces no hay nada malo con el uso asíncrono para conseguir el paralelismo. Sin embargo, si sus tareas dependen de alguna manera o si tiene más tareas que núcleos o si empuja demasiado el uso de async en el código, dejará mucho rendimiento sobre la mesa y podría hacerlo mucho mejor al elegir un una base más apropiada para la programación paralela.

en cuenta que su ejemplo se puede escribir aún más elegante con el TPL de F # embargo:

Array.Parallel.map f xs 

¿Qué voy a perder por la escritura de código asíncrono en paralelo en lugar de utilizar PLINQ o TPL?

se pierde la capacidad de escribir código de caché ajeno y, en consecuencia, sufrirá de una gran cantidad de errores de caché y, por lo tanto, todos los núcleos se cale la espera de memoria compartida que significa pobre escalabilidad en un multi-núcleo.

El TPL se basa en la idea de que las tareas secundarias deben ejecutarse en el mismo núcleo que sus padres con una alta probabilidad y, por lo tanto, se beneficiará al reutilizar los mismos datos porque estarán calientes en la memoria caché local de la CPU. No hay tal seguridad con asincronización.