我有一些高性能的Haskell代码 - 内部循环编译成6个汇编指令。 修改内部循环使其不那么有效并没有对性能产生任何明显影响，这表明内部循环不是瓶颈。 但是，当我打开分析器时，为内部循环生成的汇编代码变得明显不那么有效，并且分析器报告内部循环花费了85％的时间。
我怀疑某些东西不必要地慢，但是当我使用分析器查看时，我怀疑分析器使内部循环足够慢以至于它占主导地位。 我可以使用什么技术来查看时间去哪里？ 如果有适用于Haskell的采样分析器，那将是很棒的。
高性能Haskell代码的分析技术
49
- Neil Mitchell
10
3也许如果您手动添加成本中心，您就不能将成本中心添加到该循环中，因此它不会变慢？不确定是否可行。 - bennofs
1好主意，但似乎不起作用。即使没有任何成本中心，只是添加“-prof”，在内部循环中会放置一个“call enterFunCCS”，以及大约5个其他附加指令（但“call”将是杀手）。 - Neil Mitchell
2我有一些关于采样的技巧。基本上，你只需与分析启动代码链接即可。问题在于生成的.prof文件会使gprof死机。可能是因为gprof对符号有一些假设。但是一个经过修改的gprof，了解ghc符号的应该能够正常工作。 - augustss
3能否将循环注释掉？这样你就可以对代码的其余部分进行性能分析，而不会被循环干扰性能分析结果。 - Pedro Rodrigues
1也许你可以尝试使用“ticky-ticky”分析工具：https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky（我没有使用过，只是在 GHC 维基上偶然发现的） - bennofs
显示剩余5条评论
1个回答
24
你可以使用Linux perf事件：https://ghc.haskell.org/trac/ghc/wiki/Debugging/LowLevelProfiling/Perf
这将给出如下输出：
# Samples: 9161149923
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. ......
#
30.65% queens queens [.] s1ql_info
18.67% queens queens [.] s1qj_info
12.17% queens queens [.] s1qi_info
9.94% queens queens [.] s1o9_info
5.85% queens queens [.] r1nI_info
5.33% queens queens [.] s1sF_info
5.18% queens queens [.] s1sG_info
3.69% queens queens [.] s1oP_info
1.68% queens queens [.] stg_upd_frame_info
0.88% queens queens [.] stg_ap_2_upd_info
0.62% queens queens [.] s1sE_info
0.56% queens [kernel] [k] read_hpet
0.39% queens queens [.] stg_ap_p_info
0.35% :2030 f76beb [.] 0x00000000f76beb
0.31% queens queens [.] s1oD_info
0.28% swapper [kernel] [k] mwait_idle_with_hints
0.25% queens queens [.] __stg_gc_enter_1
0.23% queens queens [.] evacuate
0.18% swapper [kernel] [k] read_hpet
0.12% queens queens [.] scavenge_block
如果你在编译时保存核心，你可以将这些符号映射回核心中的函数。
虽然比较麻烦，但可以得到更可靠的结果。
目前正在进行自动化处理这个方面的工作。
- tibbe
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接