F#编译问题

Sna*_*ark 4 compiler-construction f# compiler-optimization

关于F#编译器的几个问题

1) -noframework做什么?我用它编译但我仍然需要.Net 4.0(我想也许它允许一个端口到早期版本?)它是否删除了F#dependancy?

2) F#--optimize +启用了哪些优化?他们都是?如果是这样,他们都是什么?

3) --tailcall有哪些优点/缺点?我知道x64过去常常忽略.tailcall,我很好奇是否有其他问题或者这些问题是否仍然存在.

4)什么是--crossoptimize,它做了什么?

5) 实际上有一个快速的子语言还是那个真的老了?

Lau*_*ent 7

这里是问题2的更详细的答案.F#编译器有许多优化选项,而--optimize +支持大多数选项.

从编译器源代码中读取,这里是事物列表--optimize + enable.我还会给你隐藏的旗帜,万一你想玩它们.当然,由于它没有隐藏和记录,这可能会在下一个版本中发生变化:

  • JIT优化(--jit-optimize)
  • 本地优化(--local-optimize),例如消除死私有绑定.
  • 跨模块优化(--crossoptimize +)
  • 允许内联lambda函数(--inlinethreshold:6).大型函数的大小大于给定的threashold,不会内联.
  • 设置ignoreSymbolStoreSequencePoints(这个没有标志)
  • 消除在呼叫站点分配的元组,因为未处理的函数(--detuple:1).有关详细注释,请参阅detuple.fs.
  • 做TLR(--tlr:1).我不知道它是什么,但tlr.fs中有很多注释
  • 最终简化传递(--finalSimplify:1)第二次应用一些优化(在其他优化通过之后).

看起来像--extraoptimizationloops:1标志未被--optimize +启用.它执行与最终简化传递相同的优化,但在另一个时间.可能没用.

对于问题3,尾调用优化对于防止堆栈溢出非常有用(当你进行许多尾递归调用时).它使调试更加困难,因此您可能希望有时将其关闭(这是VS中的默认设置,在调试模式下).


Bri*_*ian 5

以下是一些基于记忆的快速答案.(您可以随时了解编译器代码以获取更多详细信息.)

1)它允许目标不同的框架,而不是试图隐式使用任何mscorlib/FSharp.Core程序集.因此,当您明确引用Silverlight mscorlib/FSharp.Core以定位Silverlight时,可以使用此方法.

2)是的,几乎所有这些,我不知道它们都是什么.你可以看一下opt.fs.

3)调试 - 在"调试"模式下使用VS时,--tailcalls-传递以关闭尾调并保留所有堆栈帧以便于调试.

4)FSharp可以跨程序集边界进行内联和其他优化.这对于已发布的库来说可能是危险的,因为如果A引用B和A使用crossoptimize进行编译然后部署,然后有人更改/重新部署B,则A可能会"调用""旧"B中的方法,因为来自B的代码被内联到A中,因此除非重新编译A,否则A仍然具有"旧B"代码.这在实践中很少有用,但如果你有许多依赖但可独立分发的F#库,那么"典型"场景,你想要关闭crossoptimize以摆脱脆弱的依赖.

5)不再存在.