为什么不应该使用F＃异步工作流的并行？ [英] Why shouldn't I use F# asynchronous workflows for parallelism?

问题描述

我一直在学习F＃最近，正在其易于利用数据并行的特别感兴趣。在数据|＆GT; Array.map |＆GT; Async.Parallel |＆GT; Async.RunSynchronously 成语似乎很容易理解和容易使用，并从中获取真正的价值。

I have been learning F# recently, being particularly interested in its ease of exploiting data parallelism. The data |> Array.map |> Async.Parallel |> Async.RunSynchronously idiom seems very easy to understand and straightforward to use and get real value from.

那么，为什么是异步是不是真的打算为这个？ <一href=\"http://blogs.msdn.com/b/dsyme/archive/2007/10/11/introducing-f-asynchronous-workflows.aspx\">Donald赛姆自己说，PLINQ及期货可能是一个更好的选择。而我在这里读其他的答案同意这一点，以及推荐第三方物流。 （PLINQ似乎并没有上述内置功能太多不同，只要你使用的F＃动力组，以获得 PSeq 功能。）

So why is it that async is not really intended for this? Donald Syme himself says that PLINQ and Futures are probably a better choice. And other answers I've read here agree with that as well as recommending TPL. (PLINQ doesn't seem too much different to the above built-in functions, as long as you're using the F# Powerpack to get the PSeq functions.)

F＃和函数式语言做出很大的意义这一点，一些应用曾与异步并行取得了巨大的成功。

F# and functional languages make a lot of sense for this, and some applications have achieved great success with async parallelism.

那么，为什么的不应该的我用异步执行并行数据处理？我该怎么写平行失去异步 code，而不是使用PLINQ或TPL？

So why shouldn't I use async to execute parallel data processes? What am I going to lose by writing parallel async code instead of using PLINQ or TPL?

推荐答案

我写了一篇文章，重新工具同时使用工作一架C＃TPL样品和异步，其中也有对两者之间的差别一些意见。您可以这里找到它，还有一个更的先进的基于异步版本。

I wrote an article that re-implements one C# TPL sample using both Task and Async, which also has some comments on the difference between the two. You can find it here and there is also a more advanced async-based version.

下面是这两个选项的比较的第一篇文章报价：

Here is a quote from the first article that compares the two options:

两种可能的实现之间的选择取决于许多因素。异步工作流是为F＃专门设计的，所以他们更自然契合的语言。他们提供更好的性能为I / O密集​​型任务，并提供更方便的异常处理。此外，连续的语法是比较方便的。在另一方面，任务是为CPU密集型计算进行了优化，使之更容易访问从应用程序的其他地方计算的结果没有明确的缓存。

The choice between the two possible implementations depends on many factors. Asynchronous workflows were designed specifically for F#, so they more naturally fit with the language. They offer better performance for I/O bound tasks and provide more convenient exception handling. Moreover, the sequential syntax is quite convenient. On the other hand, tasks are optimized for CPU bound calculations and make it easier to access the result of calculation from other places of the application without explicit caching.

这篇关于为什么不应该使用F＃异步工作流的并行？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！