我有一些高性能的Haskell代码-内环编译到6个组装指令。修改内部循环以降低效率并不会对性能产生任何明显的影响,这表明内环不是瓶颈。但是,当我打开分析时,为内环生成的程序集代码效率大大降低,分析器报告说内环占用了85%的时间。
我怀疑某些事情是不必要的慢,但是当我使用分析来查看什么时,我怀疑分析会使内部循环足够慢,以至于它占据主导地位。我能用什么技术来看时间在哪里?如果Haskell有一个样本分析器的话,那就太好了。
发布于 2014-01-06 10:57:07
您可以使用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
如果在编译时保存核心,则可以将这些符号映射回core中的函数。
有点痛苦,但给你更值得信赖的结果。
有一些工作正在进行,以便自动完成这一任务。
https://stackoverflow.com/questions/20881177
复制相似问题