F#未来可能会比其他.Net语言更优化吗？

微软是否有可能在虚拟机执行时制作F#程序,或者更有可能在编译时,检测程序是用函数式语言构建的,并自动更好地并行化？

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

也就是说,开发人员会编写单线程程序.并且编译器会吐出一个多线程的编译程序,并在需要时使用互斥锁和同步.

这些优化是否会在进程线程计数中的任务管理器中可见,还是会低于该级别？

我认为这在不久的将来不太可能.如果它确实发生了,我认为它更有可能在IL级别(汇编重写)而不是语言级别(例如F#/编译器特有的东西).这是一个有趣的问题,我希望一些优秀的人一直在关注这一点,并将继续关注这一点,但在短期内,我认为重点将是让人类更容易指导程序的线程化/并行化,而不仅仅是通过魔术来实现它们.

(像F#异步工作流这样的语言功能,以及像任务并行库和其他库这样的库,是这里近期进展的好例子;他们可以为你做大部分繁重的工作,特别是当你的程序比声明更具说明性时,但是他们仍然需要程序员选择加入,对正确性/意义进行分析,并且可能对代码结构进行轻微改动以使其全部工作.)

无论如何,这都是猜测; 谁能说出未来会带来什么？我期待找到(并希望能够实现一些).:)

由于F#源自Ocaml和Ocaml编译器可以比其他编译器更好地优化您的程序,它可能可以完成.

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

最困难的问题是没有检测到何时可以并行执行子计算,它确定何时不会降低性能,即当子任务需要足够长的时间来计算是否值得采用并行生成的性能命中时.

我们在科学计算的背景下详细研究了这一点,我们在F#for Numerics库中采用了混合方法.我们的并行算法建立在Microsoft的任务并行库之上,需要一个额外的参数,该参数是一个给出子任务的估计计算复杂度的函数.这允许我们的实现避免过度细分并确保最佳性能.此外,此解决方案是F#编程语言的理想选择,因为描述复杂性的函数参数通常是匿名的第一类函数.

干杯,Jon Harrop.