【发布时间】：2010-10-15 12:37:09
【问题描述】：
我的意思是：当您免费设计应用程序副作用等时，F# 代码会自动分布在所有内核上吗？
【问题讨论】：
【发布时间】：2010-10-15 12:37:09
【问题描述】：
不，它不会。您仍然必须通过 F# 支持的众多机制之一显式编组对其他线程的调用。
【讨论】：
不，我很确定它不会自动为您并行化。它必须知道您的代码没有副作用，这可能很难证明，一方面。
当然，F# 可以让您的代码更容易并行化，尤其是在您没有任何副作用的情况下...但那是另一回事。
【讨论】：
-
F#的类型系统不区分纯函数和非纯函数吗？因此，知道手术没有副作用应该不难。
-
谢谢乔恩。通过证明你的意思，你必须使用合同之类的东西？
-
我不知道这种区别，但距离说它不存在还有很长的路要走。大概这会切断与框架的任何交互 - 那么异常呢？
-
@Joan：我是说因为它能够自动并行化将非常困难，并且在许多情况下可能不会有帮助，因为使用有用的库和语言功能进行仔细的手动并行化让它更容易。
-
伙计们，在这种情况下，纯洁是一个红鲱鱼。在类型系统中跟踪副作用在并行性的上下文中基本上是无用的。即使在概念上可以并行计算两个表达式，这样做通常会大量降低性能，因为它们会竞争主内存等共享资源。解决这个问题需要对算法进行理论研究，这就是为什么自动并行化在一般情况下永远不会很有用......
我的理解是Parallel Extensions is being modified 不会让它被 F# 使用。不会让它自动多线程吧，应该很容易实现。
【讨论】：
-
很好，Richard...在低睡中奔跑，不敢相信我写的
与其他提到的一样，F# 不会自动跨内核扩展，并且仍然需要一个框架，例如 Josh 提到的 ParallelFX 端口。
F# 通常与并行处理的潜力相关联，因为它默认对象是不可变的，因此在许多情况下无需锁定。
【讨论】：
不，恐怕不会。鉴于 F# 不是纯 函数式语言（在最严格的意义上），我相信这样做会相当困难。在 F# 中充分利用并行性的主要方法是使用 Async Workflows（我相信主要是通过 Async 模块）。 .NET 4.0 引入的 TPL（任务并行库）将在 F# 中发挥类似的作用（尽管值得注意的是，它同样可以用于所有 .NET 语言），但我不能说我'我确切地知道它将如何与现有的异步框架集成。也许微软会简单地建议对所有事情都使用 TPL，或者他们可能会将两者都作为一种选择，最终将成为事实上的标准......
无论如何，这里有几篇关于 F# 中的异步编程/工作流的文章可以帮助您入门。
【讨论】：
-
“鉴于 F# 不是纯函数式语言”。实际上，纯度无关紧要。
-
@Jon：那是你弄错了。这是非常相关的。编译器无法以这种方式做出必要的假设。
-
几十年来，我们一直在为 Fortran 等命令式语言提供矢量化编译器。我的观点是，在多核并行环境中，它们被证明与纯度几乎一样无用。
-
Fortan 是一种命令式语言。它永远不会平淡无奇。
-
微不足道还是自动？在实践中，从 Fortran 获得良好的并行性能比从 Haskell 更容易......
嗯，你有你的答案，但我只是想补充一点，我认为这是 F# 最重要的限制，因为它是一种混合命令式/函数式语言。 p>
我希望看到 F# 的一些扩展，它声明一个函数是 pure。也就是说，它没有函数类型未表示的副作用。这个想法是，一个函数只有在它引用其他“已知纯”函数时才是纯函数。当然，这只有在可以要求作为函数参数传递的委托引用纯函数时才有用。
【讨论】：
-
谢谢丹尼尔。我认为 F# 有一个“纯”关键字。没有？
F# 不会让它自动化，它只是让它变得简单。
又一次链接到Luca's PDC talk 的机会。从 52:20 开始的八分钟是 F# 异步工作流的精彩演示。它摇摆不定！
【讨论】：
关于纯度注释：Code Contracts 有一个 Pure 属性。我记得听说 BCL 的某些部分已经使用了这个。潜在地，这个属性也可以被并行化框架使用，但我目前还不知道有这样的工作。另外，我什至不确定代码联系人在 F# 中的使用效果如何，所以这里有很多未知数。
不过，看看所有这些东西是如何结合在一起的会很有趣。
【讨论】：
-
我想我在反射器的 BCL 中看到了一些东西。