我在评论中找不到太多文件。是否有任何好的博客文章或类似内容?
答案 0 :(得分:7)
有关剖析框架的最佳信息来源可能仍然是Patrick Sansom和Simon Peyton Jones的original paper。其他详细信息可以在Sansom的PhD thesis以及添加正式规范的later paper中找到。 Simon Marlow还谈到了Haskell Implementors' Workshop 2011的GHC状态更新中最近的一些变化。
成本中心分析背后的想法是使用“成本中心”节点注释表达式树,例如使用-auto-all
,程序将具有如下注释:
fib n = {-# SCC foo #-} (case n of
0 -> 0
1 -> 1
n -> fib (n-1) + fib (n-2))
在运行时输入fib
时,程序会查看当前的“成本中心堆栈”并将“foo”添加到顶部。一旦评估再次退出SCC注释的范围,这将被颠倒。有点神奇可以确保,如果n
恰好是一个惰性值并且程序需要执行其代码,那么适当的 代码的成本中心将在必要时恢复。< / p>
然后将此基础架构用于时间和空间分析:
计时器将定期检查成本中心堆栈。每次找到某个成本中心堆栈时,这都算作“滴答”。最后,RTS将根据其滴答计数估算每个成本中心堆栈的时间量,为您提供时间配置文件。
每次分配一个对象时,程序都会保存一个指向当时该成本中心堆栈的指针。这使垃圾收集器能够提供驻留的字节数的统计信息,按分配站点进行细分。
根据评论中的要求,关于优化的几句话:出于显而易见的原因,框架无法允许优化将非固定成本从一个成本中心转移到另一个成本中心,从而迫使优化器有时非常悲观。例如,在上面的示例中,当前版本GHC将不能够取消返回值,这意味着每个递归调用都会执行不必要的堆分配。
根据经验,不应指望在 SCC注释中发生的任何代码转换。如果有疑问,最好在调用堆栈中注释一个足够高的函数,因此性能关键位根本不会被注释。
答案 1 :(得分:0)
你可能会发现琼斯,马洛和他的this paper。辛格很有用,取决于你想要完成的事情。它包括在并行环境中分析GHC程序的实践,并包含一些您可能会觉得有用的案例研究。