我使用以下开关编译我的 C++ 代码:
g++ -O0 -g -rdynamic -DNDEBUG -DARMA_NO_DEBUG -std=c++11 -pthread
链接器开关是:
-lboost_system -lboost_thread -lboost_chrono -larmadillo -pthread
但是我在我的应用程序中没有使用线程。我也避免使用任何 delay
函数。
然后我运行代码并使用 perf
工具对其进行测试。
sudo perf record ./bin/my_application
sudo perf report -f
结果对我来说很奇怪:
Overhead Command Shared Object Symbol
50.92% myApplication [kernel.kallsyms] [k] native_sched_clock
24.73% myApplication [kernel.kallsyms] [k] pick_next_entity
17.46% myApplication [kernel.kallsyms] [k] prepend_name
2.57% myApplication myApplication [.] arma::arrayops::copy_small<double>
1.11% myApplication myApplication [.] arma::Mat<double>::Mat
1.11% myApplication myApplication [.] myClass::myMethod
1.11% myApplication libblas.so.3 [.] dgemv_
0.97% myApplication myApplication [.] arma::Mat<double>::init_cold
为什么 kernel.kallsyms
函数支配着执行时间?
native_sched_clock
、pick_next_entity
、prepend_name
分别为我的应用程序做了什么?
最佳答案
您的应用程序太快太短,无法使用 perf record
的默认频率进行分析。所有带有 [k]
和 [kernel.kallsyms]
的行都来自内核,它正在执行一些服务工作,例如加载二进制文件和调度线程/进程 (``)。当您在 xen、kvm 等某种虚拟化平台上使用 perf 时,事情可能会出错,因为大多数虚拟化环境无法访问 guest 内核的硬件性能计数器(AWS 有时会提供基本的周期子集和隔离指令实例);所以 perf 将使用软件定时器中断。
尝试在要测量的代码周围添加循环(重复 100 或 1000 次)和/或增加要处理的数据的大小。您的程序应该至少运行几秒钟。
您也可以尝试运行 perf stat ./program
来获取程序的计时值和基本硬件性能计数(如果支持计数器),并发布结果。
关于c++ - kernel.kallsyms 在 C++ 应用程序运行中的作用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44450021/