微软是否有可能在VM执行时或更有可能在编译时制作F＃程序，检测程序是否使用功能语言构建并自动更好地并行化？
现在我相信没有这样的努力来尝试执行一个程序，该程序作为单线程程序自动构建为多线程程序。
也就是说，开发人员会编写单线程程序。并且编译器会吐出一个多线程的编译程序，并在需要时使用互斥和同步。
这些优化是否会在进程线程计数的任务管理器中可见，还是会低于该级别？
答案 0 :(得分：12)
我认为这在不久的将来不太可能。如果它确实发生了，我认为它更有可能在IL级别（汇编重写）而不是语言级别（例如F＃/编译器特有的东西）。这是一个有趣的问题，我希望一些优秀的人一直在关注这一点，并将继续关注这一点，但在短期内，我认为重点将是让人类更容易指导程序的线程化/并行化，而不仅仅是通过魔术来实现它们。
（F# async workflows等语言功能以及task-parallel library and others等图书馆是近期进展的好例子;他们可以为您完成大部分繁重工作，特别是当您的计划更多时声明性而非命令式，但它们仍然需要程序员选择加入，对正确性/有意义进行分析，并且可能对代码结构进行轻微改动以使其全部工作。）
无论如何，这都是猜测;谁能说出未来会带来什么？我期待找到（并希望能够实现一些）。 ：）
答案 1 :(得分：7)
由于F＃派生自Ocaml，Ocaml编译器可以比其他编译器更好地优化您的程序，它可能可以完成。
答案 2 :(得分：5)
我不相信以一般有用的方式自动向量化代码是可能的，而F＃的函数式编程方面在这种情况下基本上是无关紧要的。
最困难的问题是没有检测到何时可以并行执行子计算，它确定何时不会降低性能，即当子任务需要足够长的时间来计算是否值得采用并行生成的性能命中时。
我们在科学计算的背景下对此进行了详细的研究，我们在F＃for Numerics库中采用了混合方法。我们的并行算法建立在Microsoft的任务并行库之上，需要一个额外的参数，该参数是一个给出子任务的估计计算复杂度的函数。这允许我们的实现避免过度细分并确保最佳性能。此外，此解决方案非常适合F＃编程语言，因为描述复杂性的函数参数通常是匿名的第一类函数。
干杯， Jon Harrop。
答案 3 :(得分：4)
我认为这个问题忽略了.NET体系结构的重点--F＃，C＃和VB（等）都被编译为IL，然后通过JIT编译器编译成机器代码。程序是用函数式语言编写的这一事实并不重要 - 如果有来自IL的JIT编译器可以进行优化（如尾递归等），编译器应该利用它。
当然，这并不意味着编写功能代码是无关紧要的 - 显然，有很多方法可以编写IL并且可以更好地并行化 - 但是这些技术中的许多技术都可以在任何.NET语言中使用。
因此，没有必要将IL标记为来自F＃，以便检查它是否具有潜在的并行性，也不需要这样做。
答案 4 :(得分：2)
对各种语言的自动并行化和自动矢量化进行了积极的研究。人们可能希望（因为我真的很喜欢F＃）他们会想出一种方法来确定是否使用了“纯”副作用自由子集，然后将其并行化。 此外，自从Haskell的父亲Simon Peyton-Jones在微软工作以来，我很难不相信那里有一些奇妙的东西。
答案 5 :(得分：2)
这可能但不太可能。微软花费大部分时间来支持和实施其最大客户所要求的功能。这通常意味着C＃，VB.Net和C ++（不一定按顺序）。 F＃似乎并不是优先考虑的事项。
答案 6 :(得分：2)
微软目前正在开发两种代码并行化的途径：PLINQ（Pararllel Linq，很大程度上归功于函数式语言）和任务并行库（TPL），它最初是Robotics Studio的一部分。 PLINQ的测试版可用here。
我会把我的钱放在PLINQ上，成为.NET代码自动并行化的标准。