Microsoft是否有可能在VM执行时或者更可能在编译时制作F程序，以检测程序是使用功能语言构建的，并自动更好地对其进行并行化？

现在，我认为没有必要尝试自动执行由单线程程序构建为多线程程序的程序。

也就是说，开发人员将编写一个单线程程序。然后，编译器将在需要时吐出具有多线程，互斥和同步功能的多线程编译程序。

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

解决方案

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

对于多种语言的自动并行化和自动矢量化，已有积极的研究。并可以希望(因为我真的很喜欢F＃)他们会想出一种方法来确定是否使用了"纯"的无副作用子集，然后对其进行并行化。
同样，由于Haskell的父亲Simon Peyton-Jones在Microsoft工作，我很难不相信会有一些很棒的东西出现。

我认为在不久的将来这不太可能。而且如果确实发生了，我认为它更有可能在IL级别(汇编重写)而不是语言级别(例如F＃/编译器专有的东西)。这是一个有趣的问题，我希望一些聪明的人一直在研究这个问题，并将在一段时间内继续研究这个问题，但是在短期内，我认为重点将放在使人类更容易指导程序的线程化/并行化，而不仅仅是让一切如魔术般发生。

(诸如Fasync工作流之类的语言功能，以及诸如任务并行库之类的库等都是此处近期进展的很好的示例；它们可以为我们完成大部分繁重的工作，尤其是当程序更具说明性而不是命令性的时候，但是他们仍然需要程序员选择加入，进行正确性/有意义性分析，并可能对代码的结构进行一些细微改动以使其全部正常工作。)

无论如何，这都是猜测。谁能说未来会带来什么？我期待发现(并希望使其中的某些事情发生)。 :)

我认为这个问题错过了.NET体系结构的要点-F＃，Cand VB(等等)都被编译为IL，然后通过JIT编译器被编译为机器代码。用功能语言编写程序的事实并不重要-如果IL的JIT编译器有可用的优化(如尾递归等)，则编译器应利用它。

自然，这并不意味着编写功能代码无关紧要-显然，有编写IL的方法可以更好地并行化-但是这些技术中的许多技术都可以在任何.NET语言中使用。

因此，无需将IL标记为来自Fin即可检查其潜在的并行性，也不希望这样。

有可能，但不太可能。微软将大部分时间用于支持和实施其最大客户所要求的功能。这通常意味着C＃，VB.Net和C ++(不一定按该顺序)。 F似乎不在优先级列表中。

我认为不可能以一种普遍有用的方式对代码进行自动向量化，而在这种情况下，Fis的功能性编程方面基本上是无关紧要的。

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

我们已经在科学计算的背景下对此进行了详细研究，并且在Ffor Numerics库中采用了一种混合方法。我们基于Microsoft的Task Parallel Library建立的并行算法，需要一个添加参数，该参数是一个函数，它提供子任务的估计计算复杂性。这使我们的实现避免了过多的细分，并确保了最佳性能。此外，该解决方案对于F编程语言是理想的，因为描述复杂性的函数参数通常是匿名的一流函数。

干杯，
乔恩·哈罗普(Jon Harrop)。

微软目前正在开发两种实现代码并行化的途径：PLINQ(Parallllel Linq，这要归功于功能语言)和Task Parallel Library(TPL)，它最初是Robotics Studio的一部分。这里提供了PLINQ的beta版本。

我会把钱花在PLINQ上，以成为.NET代码自动并行化的规范。