未来 F# 是否有可能比其他 .Net 语言得到更多优化？
Microsoft 是否有可能使 F# 程序（无论是在 VM 执行时，还是更有可能在编译时）检测到程序是使用函数式语言构建的，并自动更好地并行化它？
现在我相信没有这样的努力来尝试和自动执行作为单线程程序构建的程序作为多线程程序。
也就是说，开发人员将编写一个单线程程序。 编译器会生成一个编译后的程序，该程序是多线程的，在需要时带有互斥体和同步。
这些优化在任务管理器的进程线程计数中是否可见，或者是否会低于该级别？
Is it possible that Microsoft will be able to make F# programs, either at VM execution time, or more likely at compile time, detect that a program was built with a functional language and automatically parallelize it better?
Right now I believe there is no such effort to try and execute a program that was built as single threaded program as a multi threaded program automatically.
That is to say, the developer would code a single threaded program. And the compiler would spit out a compiled program that is multi-threaded complete with mutexes and synchronization where needed.
Would these optimizations be visible in task manager in the process thread count, or would it be lower level than that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
由于 F# 源自 Ocaml，并且 Ocaml 编译器可以比其他编译器更好地优化您的程序，因此这可能是可以做到的。
Being that F# is derived from Ocaml and Ocaml compilers can optimize your programs far better than other compilers, it probably could be done.
我认为不可能以通用的方式自动向量化代码，并且 F# 的函数式编程方面在这种情况下本质上是不相关的。
最困难的问题不是检测何时可以并行执行子计算，而是确定何时不会降低性能，即子任务何时需要足够长的时间来计算，值得承受并行生成的性能影响。
我们在科学计算的背景下对此进行了详细研究，并在 F# for Numerics 库中采用了混合方法。 我们的并行算法基于 Microsoft 的任务并行库构建，需要一个附加参数，该参数是给出子任务的估计计算复杂性的函数。 这使得我们的实现能够避免过度细分并确保最佳性能。 此外，此解决方案非常适合 F# 编程语言，因为描述复杂性的函数参数通常是匿名的一类函数。
干杯，
乔恩·哈罗普。
I don't believe it is possible to autovectorize code in a generally-useful way and the functional programming facet of F# is essentially irrelevant in this context.
The hardest problem is not detecting when you can perform subcomputations in parallel, it is determining when that will not degrade performance, i.e. when the subtasks will take sufficiently long to compute that it is worth taking the performance hit of a parallel spawn.
We have researched this in detail in the context of scientific computing and we have adopted a hybrid approach in our F# for Numerics library. Our parallel algorithms, built upon Microsoft's Task Parallel Library, require an additional parameter that is a function giving the estimated computational complexity of a subtask. This allows our implementation to avoid excessive subdivision and ensure optimal performance. Moreover, this solution is ideal for the F# programming language because the function parameter describing the complexity is typically an anonymous first-class function.
Cheers,
Jon Harrop.
我认为这个问题没有抓住 .NET 架构的重点——F#、C# 和 VB（等）都被编译为 IL，然后通过 JIT 编译器编译为机器代码。 程序是用函数式语言编写的这一事实并不重要——如果 JIT 编译器可以从 IL 进行优化（如尾递归等），则编译器应该利用它。
当然，这并不意味着编写函数代码是无关紧要的——显然，有一些方法可以编写可以更好地并行化的 IL——但其中许多技术可以在任何 .NET 语言中使用。
因此，没有必要将 IL 标记为来自 F# 来检查其潜在的并行性，这样的事情也不是可取的。
I think the question misses the point of the .NET architecture-- F#, C# and VB (etc.) all get compiled to IL, which then gets compiled to machine code via the JIT compiler. The fact that a program was written in a functional language isn't relevant-- if there are optimizations (like tail recursion, etc.) available to the JIT compiler from the IL, the compiler should take advantage of it.
Naturally, this doesn't mean that writing functional code is irrelevant-- obviously, there are ways to write IL which will parallelize better-- but many of these techniques could be used in any .NET language.
So, there's no need to flag the IL as coming from F# in order to examine it for potential parallelism, nor would such a thing be desirable.
针对各种语言的自动并行化和自动矢量化正在进行积极的研究。 人们可能希望（因为我真的很喜欢 F#）他们会想出一种方法来确定是否使用“纯”无副作用子集，然后将其并行化。
另外，自从 Haskell 之父 Simon Peyton-Jones 在 Microsoft 工作以来，我很难不相信会有一些奇妙的东西即将到来。
There's active research for autoparallelization and auto vectorization for a variety of languages. And one could hope (since I really like F#) that they would concive a way to determine if a "pure" side-effect free subset was used and then parallelize that.
Also since Simon Peyton-Jones the father of Haskell is working at Microsoft I have a hard time not beliving there's some fantastic stuff comming.
这是可能的，但可能性不大。 Microsoft 大部分时间都花在支持和实现其最大客户所要求的功能上。 这通常意味着 C#、VB.Net 和 C++（不一定按此顺序）。 F# 似乎并不是优先考虑的对象。
It's possible but unlikely. Microsoft spends most of it's time supporting and implementing features requested by their biggest clients. That usually means C#, VB.Net, and C++ (not necessarily in that order). F# doesn't seem like it's high on the list of priorities.
Microsoft 目前正在开发两种代码并行化途径：PLINQ（Pararllel Linq，这在很大程度上要归功于函数式语言）和任务并行库 (TPL)，后者最初是 Robotics Studio 的一部分。 PLINQ 测试版现已推出 在这里。
我愿意相信 PLINQ 会成为 .NET 代码自动并行化的标准。
Microsoft is currently developing 2 avenues for parallelisation of code: PLINQ (Pararllel Linq, which owes much to functional languages) and the Task Parallel Library (TPL) which was originally part of Robotics Studio. A beta of PLINQ is available here.
I would put my money on PLINQ becoming the norm for auto-parallelisation of .NET code.
我认为这在不久的将来不太可能发生。 如果确实发生，我认为更有可能发生在 IL 级别（程序集重写）而不是语言级别（例如 F#/编译器特有的东西）。 这是一个有趣的问题，我希望一些聪明的人已经在关注这个问题，并将继续关注这个问题一段时间，但在短期内，我认为重点将放在让人类更容易地指导这个问题上。程序的线程化/并行化，而不是像魔术一样让这一切发生。
（诸如 F# 异步工作流程 以及诸如任务并行库和其他之类的库，都是近邻的很好的例子-术语进展在这里；他们可以为你完成大部分繁重的工作，特别是当你的程序更具声明性而不是命令性时，但他们仍然需要程序员选择加入，对正确性/意义进行分析，并可能对使一切正常工作的代码结构。）
无论如何，这都是猜测； 谁能预测未来会发生什么？ 我期待着找到答案（并希望能够实现其中一些）。 :)
I think this is unlikely in the near future. And if it does happen, I think it would be more likely at the IL level (assembly rewriting) rather than language level (e.g. something specific to F#/compiler). It's an interesting question, and I expect that some fine minds have been looking at this and will continue to look at this for a while, but in the near-term, I think the focus will be on making it easier for humans to direct the threading/parallelization of programs, rather than just having it all happen as if by magic.
(Language features like F# async workflows, and libraries like the task-parallel library and others, are good examples of near-term progress here; they can do most of the heavy lifting for you, especially when your program is more declarative than imperative, but they still require the programmer to opt-in, do analysis for correctness/meaningfulness, and probably make slight alterations to the structure of the code to make it all work.)
Anyway, that's all speculation; who can say what the future will bring? I look forward to finding out (and hopefully making some of it happen). :)