14

微软是否有可能让 F# 程序在 VM 执行时或更可能在编译时检测到程序是用函数式语言构建的并自动更好地并行化它？

现在我相信没有这样的努力来尝试自动执行一个作为单线程程序构建为多线程程序的程序。

也就是说，开发人员将编写一个单线程程序。并且编译器会输出一个编译的程序，该程序是多线程的，在需要时带有互斥锁和同步。

这些优化会在任务管理器中的进程线程数中可见，还是会比这更低？

4

7 回答 7

12

我认为这在不久的将来不太可能。如果确实发生了，我认为它更有可能发生在 IL 级别（程序集重写）而不是语言级别（例如 F#/编译器特定的东西）。这是一个有趣的问题，我希望一些优秀的人一直在关注这个问题，并将继续关注这个问题，但在短期内，我认为重点将放在让人类更容易指挥程序的线程化/并行化，而不是像魔术一样让这一切发生。

（像F# 异步工作流这样的语言特性，以及像任务并行库和其他库这样的库，都是这里近期取得进展的好例子；它们可以为您完成大部分繁重的工作，尤其是当您的程序更具声明性而不是命令性时，但它们仍然需要程序员选择加入，对正确性/意义进行分析，并可能对代码结构进行轻微改动以使其全部工作。）

无论如何，这都是猜测；谁能说未来会带来什么？我期待着发现（并希望能实现其中的一些）。:)

于 2008-09-27T15:05:00.997 回答
7

由于 F# 是从 Ocaml 派生的，而 Ocaml 编译器可以比其他编译器更好地优化您的程序，因此可能可以做到。

于 2008-09-27T14:46:27.703 回答
6

我不相信以一种普遍有用的方式自动矢量化代码是可能的，并且 F# 的函数式编程方面在这种情况下基本上是无关紧要的。

最困难的问题不是检测何时可以并行执行子计算，而是确定何时不会降低性能，即何时子任务将花费足够长的时间来计算，值得承担并行生成的性能损失。

我们在科学计算的背景下对此进行了详细研究，并在我们的 F# for Numerics 库中采用了混合方法。我们的并行算法基于 Microsoft 的任务并行库构建，需要一个附加参数，该参数是一个函数，可提供子任务的估计计算复杂度。这允许我们的实现避免过度细分并确保最佳性能。此外，该解决方案非常适合 F# 编程语言，因为描述复杂性的函数参数通常是匿名的一等函数。

干杯，乔恩·哈罗普。

于 2008-10-19T03:46:31.297 回答
4

我认为这个问题忽略了 .NET 架构的重点——F#、C# 和 VB（等）都被编译为 IL，然后通过 JIT 编译器编译为机器代码。程序是用函数式语言编写的这一事实并不相关——如果 IL 中的 JIT 编译器有可用的优化（如尾递归等），编译器应该利用它。

当然，这并不意味着编写函数式代码是无关紧要的——显然，有一些方法可以编写可以更好地并行化的 IL——但是其中许多技术可以在任何 .NET 语言中使用。

因此，没有必要将 IL 标记为来自 F# 以检查它的潜在并行性，这样的事情也不可取。

于 2008-09-27T15:36:22.187 回答
3

对各种语言的自动并行化和自动矢量化进行了积极的研究。人们可能希望（因为我真的很喜欢 F#）他们会想出一种方法来确定是否使用了“纯”无副作用子集，然后将其并行化。此外，自从 Haskell 之父 Simon Peyton-Jones 在 Microsoft 工作以来，我很难不相信会有一些很棒的东西出现。

于 2008-09-27T14:47:58.947 回答
2

这是可能的，但不太可能。Microsoft 将大部分时间用于支持和实施最大客户要求的功能。这通常意味着 C#、VB.Net 和 C++（不一定按此顺序）。F# 在优先级列表中似乎并不高。

于 2008-09-27T15:52:45.720 回答
2

微软目前正在开发两种代码并行化途径：PLINQ（Pararllel Linq，很大程度上归功于函数式语言）和最初属于 Robotics Studio 的任务并行库 (TPL)。PLINQ 的测试版可在此处获得。

我会把钱放在 PLINQ 上，使其成为 .NET 代码自动并行化的标准。

于 2008-10-19T04:31:37.710 回答