2012-07-12 599 views
10

在使用gprof来剖析我编写的C++程序的过程中,我注意到绝大多数执行时间都花在函数“frame_dummy”上。更准确地说,gprof的输出中的平面配置文件中的第一个条目显示调用名为frame_dummy的函数中的样本时间的76.38%和24611191调用。frame_dummy在分析的上下文中意味着什么?

简而言之,我试图理解frame_dummy是指什么 - 因为我没有任何名为这样的函数 - 以及这对我的优化工作意味着什么。

虽然这不太可能是相关的,但我应该补充一点,该程序旨在使用多重网格算法解决泊松方程,并使用MPI来并行化任务。但是,尽管存在MPI函数调用,但上述gprof输出仅源自运行一个进程。我还应该注意到我的程序除了MPI之外没有任何依赖关系,并且用g ++ 4.6.1编译。

+0

它是C运行时库的一部分。 – Barmar 2012-12-27 05:49:28

回答

7

这里有一个很好的解释:http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html。但是我不确定你的程序为什么会在frame_dummy中花费那么多时间,或者为什么它会被调用这么多次。

也许您的二进制文件中的调试信息以某种方式损坏,或者被gprof误读?或者gprof可能会被MPI弄混吗?这里有一些可以尝试的方法:在gdb中运行程序,并在frame_dummy函数中使用断点。看看它是否真的被称为2400万次,如果真的这样做,那么它会被调用。

另外,你能确认这是crtbegin.o中的frame_dummy,而不是其他一些frame_dummy吗?

这是the source for frame_dummy in crtbegin.c - 通过阅读代码,应该只能调用一次。

此外,我假设你的程序运行并产生正确的结果? (特别是,如果有一个在你的程序中的内存错误,那么你可以得到一些非常奇怪的行为。)

+0

感谢您的链接! – 2012-12-28 10:20:57

+1

Edward,gprof如何找到一个函数名?可能是约翰没有在自己的程序编译中加入'-pg'选项;但将其添加到链接步骤。 ''crtbegin'使用'-pg';但在他的代码中没有调用gprof工具。 – osgx 2012-12-28 14:27:20

+0

非常感谢!我最终发现了乔尔提到的同样的现象;使用-O3进行编译会执行某种优化,导致gprof读取几个频繁调用的函数,作为对frame_dummy的调用。 – Ben 2013-04-16 23:13:47

4

我遇到了同样的问题,这里是从gprof的我的输出:

% cumulative self    self  total 
time seconds seconds calls ms/call ms/call name 
52.00  16.27 16.27 204000  0.08  0.08 frame_dummy 
47.46  31.12 14.85 418000  0.04  0.07 f2 
    0.51  31.28  0.16 21800  0.01  1.42 f1 
    0.03  31.29  0.01  1980  0.01 14.21 f5 

在我的案例

Each sample counts as 0.01 seconds. 
    % cumulative self    self  total 
time seconds seconds calls ms/call ms/call name 
53.12  22.24 22.24 200000  0.11  0.11 f4 
45.65  41.36 19.11 598000  0.03  0.03 f2 
    0.69  41.65  0.29 20000  0.01  1.45 f3 
    0.45  41.84  0.19 39800  0.00  0.32 f1 
    0.10  41.88  0.04        evaluate 

也就是说,gprof的误认f4frame_dummy:当我编译gcc -Os,而不是gcc -O3它得到了解决。

+0

这正是问题所在,尽管实际上好像有几个不同的函数被frame_dummy包含。不过,这有点令人沮丧,因为关闭优化会显着改变配置文件结构,因为函数会受到编译器优化的不同程度的影响。 – Ben 2013-04-16 23:17:32