F# 编译器问题
关于 F# 编译器的几个问题
1) --noframework 的作用是什么？我用它进行了编译，但我仍然需要 .Net 4.0（我想它可能允许移植到早期版本？）它是否删除了 F# 依赖项？
2) F# --optimize+ 启用哪些优化？他们全部？如果有，它们都是什么？
3) --tailcall 的优点/缺点是什么？我知道 x64 有时会忽略 .tailcall，我很好奇是否还有其他问题或者这些问题是否仍然存在。
4)什么是--crossoptimize，它有什么作用？
A couple questions about the F# compiler
1) what does --noframework do? I compiled with it but I still needed .Net 4.0(I thought maybe it allowed a port to an earlier version?) Does it remove an F# dependancy?
2) What optimizations does the F# --optimize+ enable? all of them? if so, what are all of them?
3) What are the advantages/disadvantages of --tailcall? I know that x64 used to ignore .tailcall sometimes, I was curious if there were other problems or if those problems persist.
4) what is --crossoptimize and what does it do?
5) is there actually a fast sublanguage or is that something really old??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是问题 2 的更详细答案。F# 编译器有许多优化选项，--optimize+ 可以启用其中的大多数选项。
从编译器源代码中读取，这里是 --optimize+ 启用的内容列表。
我还为您提供了隐藏的标志，以防您想使用它们。当然，由于它没有隐藏和记录，这可能会在下一个版本中发生变化：
看起来 --optimize+ 未启用 --extraoptimizationloops:1 标志。它执行与最终简化过程相同的优化，但时间不同。可能没什么用。
对于问题 3，尾部调用优化对于防止堆栈溢出非常有用（当您进行多次尾部递归调用时）。它使调试变得更加困难，因此有时您可能希望将其关闭（这是 VS 中调试模式下的默认设置）。
Here is more detailed answer for question 2. F# compiler has many options for optimization, and --optimize+ enables most of them.
Reading from the compiler source code, here is the list of things --optimize+ enables.
I also give you the hidden flags, in case you'd like to play with them. Of course, as it is not hidden and documented, this may change in a next release:
It looks like the --extraoptimizationloops:1 flag is not enabled by --optimize+. It does the same optimizations as the final simplify pass, but at another time. Might be useless.
For question 3, tail call optimization is very useful to prevent stack overflows (when you're doing many tail recursive calls). It makes debugging harder, so you might want to turn it off sometimes (this is the default in VS, in debug-mode).
以下是一些基于记忆的快速答案。 （您始终可以深入了解编译器代码以获取更多详细信息。）
1）它允许针对不同的框架，而不是尝试隐式使用任何 mscorlib/FSharp.Core 程序集。因此，当您显式引用 Silverlight mscorlib/FSharp.Core 来定位 Silverlight 时，您可以使用此选项。
2）是的，几乎全部，但我不知道它们都是什么。您可以查看 opt.fs。
3) 调试 - 当在“调试”模式下使用 VS 时，会传递
--tailcalls-来关闭尾调用并保留所有堆栈帧，以便更轻松地进行调试。4）FSharp可以跨程序集边界进行内联和其他优化。这对于已发布的库来说可能很危险，因为如果 A 引用 B 并且 A 使用交叉优化进行编译然后部署，然后有人更改/重新部署 B，则 A 可能会“调用”“旧”B 中的方法，因为B 中的代码被内联到 A 中，因此 A 仍然具有“旧 B”代码，除非重新编译 A。这在实践中很少重要，但“典型”场景是，如果您有许多依赖但可独立分发的 F# 库，则您需要关闭交叉优化以摆脱脆弱的依赖关系。
5）那不再存在了。
Here are some quick answers based on memory. (You can always go spelunking through the compiler code for more detail.)
1) It allows targetting different frameworks, by not trying to implicitly use any mscorlib/FSharp.Core assemblies. So you use this when e.g. you explicitly reference the Silverlight mscorlib/FSharp.Core to target Silverlight.
2) Yes, nearly all of them, and I don't know what they all are. You might look at opt.fs.
3) Debugging - when using VS in "Debug" mode,
--tailcalls-is passed to turn off tailcalls and preserve all stack frames to enable easier debugging.4) FSharp can do inlining and other optimizations across assembly boundaries. This can be dangerous for published libraries because if A references B and A was compiled with crossoptimize and then deployed, and then someone changes/re-deploys B, it is possible A will "call" a method in the "old" B because that code from B was inlined into A and so A still has the "old B" code unless A is recompiled. This rarely matters in practice, but the 'typical' scenario if you have a number of dependent but independently-distributable F# libraries, you want to turn off crossoptimize to get rid of fragile dependencies.
5) That no longer exists.