我有一个通常报告的应用程序(time
命令报告):
real 1.59
user 1.42
sys 4.73
但是当我加载共享库并运行它时,时间会变得相当长(time
命令报告):
real 28.51
user 106.22
sys 5.23
虽然由于我的共享库的工作,预计运行速度会出现一定程度的增长(在 CentOS 和 Ubuntu 上报告为 2 到 4 倍,这符合预期),但上述在 Fedora 24 上报告的时间太长了。
我尝试使用perf
报告:
255352.948615 task-clock:u (msec) # 3.895 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
18,127 page-faults:u # 0.071 K/sec
664,852,184,198 cycles:u # 2.604 GHz (50.03%)
19,323,811,463 stalled-cycles-frontend:u # 2.91% frontend cycles idle (50.02%)
578,178,881,331 stalled-cycles-backend:u # 86.96% backend cycles idle (50.02%)
110,595,196,687 instructions:u # 0.17 insn per cycle
# 5.23 stalled cycles per insn (50.00%)
28,361,633,658 branches:u # 111.068 M/sec (50.01%)
777,249,031 branch-misses:u # 2.74% of all branches (50.01%)
65.564158710 seconds time elapsed
这似乎表明 CPU 有大量时间处于空闲状态。但我试图找到代码中发生这种情况的位置(我可以访问我的应用程序和相关共享库的整个源代码)。我还看到perf report
哪个报告了函数/系统调用所花费的时间的百分比。但我对更精细的级别感兴趣,即这些函数中的哪一行,以便我能够理解原因。
我很高兴提供任何具体的建议并不容易,因为我没有提供有关我的应用程序/共享库的太多信息。我只是在寻找建议/工具/想法来找出 CPU 大部分时间花在代码中的位置(或空闲的位置)。
它是带有 glibc 2.23 的 Fedora 24 Linux/x86_64(我的应用程序和共享库都是用 gcc 6.1.1 和 glibc 2.23 编译的)。
答案1
这似乎表明 CPU 有大量时间处于空闲状态。
是的。即 87% 的时间。但这并不意味着处理器不处理其他任务和进程。
664,852,184,198 cycles:u # 2.604 GHz (50.03%)
19,323,811,463 stalled-cycles-frontend:u # 2.91% frontend cycles idle (50.02%)
578,178,881,331 stalled-cycles-backend:u # 86.96% backend cycles idle (50.02%)
110,595,196,687 instructions:u # 0.17 insn per cycle
优化程序以更好地利用 CPU 和内存访问它是一项复杂的任务,如果没有任何代码,就不可能更详细地回答您。