通常、以下を報告するアプリケーションがあります(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とメモリアクセスをよりよく活用するようにプログラムを最適化することは複雑な作業であり、コードがなければより詳細に答えることは不可能です。