'perf stat'の結果のstalled-cycles-frontendおよびstalled-cycles-backendとは何ですか？

Question 1

perf statの結果で、stalled -cycles-frontendとstalled-cycles-backendの意味を知っている人はいますか？インターネットで検索しましたが、答えが見つかりませんでした。ありがとう

$ sudo perf stat ls                     

Performance counter stats for 'ls':

      0.602144 task-clock                #    0.762 CPUs utilized          
             0 context-switches          #    0.000 K/sec                  
             0 CPU-migrations            #    0.000 K/sec                  
           236 page-faults               #    0.392 M/sec                  
        768956 cycles                    #    1.277 GHz                    
        962999 stalled-cycles-frontend   #  125.23% frontend cycles idle   
        634360 stalled-cycles-backend    #   82.50% backend  cycles idle
        890060 instructions              #    1.16  insns per cycle        
                                         #    1.08  stalled cycles per insn
        179378 branches                  #  297.899 M/sec                  
          9362 branch-misses             #    5.22% of all branches         [48.33%]

   0.000790562 seconds time elapsed

Question 2

その理論：

これから始めましょう。今日のCPUはスーパースカラーです。つまり、サイクルごとに複数の命令（IPC）を実行できます。最新のIntelアーキテクチャは、最大4つのIPC（4 x86命令デコーダー）に対応できます。物事をさらに複雑にするために、マクロ/ミクロの融合を議論に持ち込まないようにしましょう:)。

通常、さまざまなリソースの競合が原因で、ワークロードはIPC = 4に達しません。これは、CPUがサイクルを浪費していることを意味します（命令の数はソフトウェアによって与えられ、CPUは可能な限り少ないサイクルでそれらを実行する必要があります）。

CPUが費やしている合計サイクルを次の3つのカテゴリに分けることができます。

指示が廃止されるサイクル（有用な作業）
バックエンドで費やされているサイクル（無駄）
フロントエンドで費やされたサイクル（無駄）。

IPCを4にするには、リタイアするサイクル数を合計サイクル数に近づける必要があります。この段階では、すべてのマイクロオペレーション（uOps）がパイプラインからリタイアし、その結果をレジスター/キャッシュにコミットすることに注意してください。この段階では、実行ポートの数によってこの数が指定されるため、4uOpsを超えるリタイアが発生する可能性があります。サイクルの25％のみが4 uOpsをリタイアする場合、全体のIPCは1になります。

バックエンドで失速サイクル（ - SQRT、逆数、部門、などなどtranscedentals）CPUがリソースを（通常はメモリ）に待機するか、長い待ち時間の手順を完了する必要があるため廃棄物です。

フロントエンドで失速サイクルはフロントエンドは、マイクロオペレーションとバックエンドを供給していないということを意味するので無駄です。これは、命令キャッシュに欠落があるか、マイクロオペレーションキャッシュでまだデコードされていない複雑な命令があることを意味している可能性があります。ジャストインタイムでコンパイルされたコードは通常、この動作を表します。

もう1つのストールの理由は、分岐予測のミスです。それは悪い憶測と呼ばれます。その場合、uOpsが発行されますが、BPが誤って予測したため、uOpsは破棄されます。

プロファイラーでの実装：

BEとFEのストールサイクルをどのように解釈しますか？

プロファイラーが異なれば、これらの指標に対するアプローチも異なります。vTuneでは、カテゴリ1から3を合計すると、サイクルが100％になります。CPUが停止している（uOpsがリタイアしていない）か、有用な作業（uOps）がリタイアしているため、この継ぎ目は妥当です。詳細はこちら：https：//software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/analyticserxe/snb/index.htm

パフォーマンスでは、これは通常発生しません。フロントエンドで125％のサイクルが停止しているのを見ると、これを実際に解釈する方法がわからないため、これは問題です。> 1メトリックを、4つのデコーダーがあるという事実と関連付けることができますが、推論を続けると、IPCは一致しません。

さらに良いことに、問題がどれほど大きいかはわかりません。何の125％？では、＃cyclesはどういう意味ですか？

私は個人的に、パフォーマンスのBEとFEのストールサイクルについて少し疑わしいように見えますが、これが修正されることを願っています。

おそらく、ここからコードをデバッグすることで最終的な答えが得られます：http：//git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c

Question 3

perfによってエクスポートされた汎用イベントをCPUドキュメントのrawイベントに変換するには、次のコマンドを実行できます。

more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend

それはあなたに次のようなものを表示します

event=0x0e,umask=0x01,inv,cmask=0x01

よると、IntelのドキュメントSDMボリューム3B（私はコアi5-2520を持っています）：

UOPS_ISSUED.ANY：

RATからRSに発行されるUopsの数をサイクルごとにインクリメントします。
このコアのストールしたサイクルをカウントするには、Cmask = 1、Inv = 1、Any = 1に設定します。

私のシステムでevent = 0xb1、umask = 0x01に変換されるstalled-cycles-backendイベントの場合、同じドキュメントに次のように記載されています。

UOPS_DISPATCHED.THREAD：

サイクルごとにスレッドごとにディスパッチされるuopsの総数をカウントします
ストールサイクルをカウントするには、Cmask = 1、INV = 1に設定します。

通常、ストールサイクルは、プロセッサが何か（たとえば、ロード操作の実行後にメモリがフィードされる）を待機していて、他に何もすることがないサイクルです。さらに、CPUのフロントエンド部分は、命令のフェッチとデコード（UOPへの変換）を行うハードウェアの一部であり、バックエンド部分はUOPを効果的に実行する役割を果たします。

Question 4

パイプラインが進行しない場合、CPUサイクルは「ストール」します。

プロセッサパイプラインは多くのステージで構成されています。フロントエンドはこれらのステージのグループであり、フェッチフェーズとデコードフェーズを担当し、バックエンドは命令を実行します。フロントエンドとバックエンドの間にバッファがあるため、前者が停止した場合でも、後者にはまだやるべきことがいくつかあります。

http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/から取得

Question 5

これらのイベントの作成者によると、それらは大まかに定義され、使用可能なCPUパフォーマンスカウンターによって概算されます。私が知っているように、perfは、いくつかのハードウェアイベントに基づいていくつかの合成イベントを計算する式をサポートしていないため、Intelの最適化マニュアル（VTuneで実装）のフロントエンド/バックエンドストールバウンドメソッドを使用できませんhttp：// www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf「B.3.2階層型トップダウンパフォーマンス特性評価方法」

%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N ); 
%Bad_Speculation = 100 * ( (UOPS_ISSUED.ANY – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) / N) ; 
%Retiring = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/ N) ; 
%BE_Bound = 100 * (1 – (FE_Bound + Retiring + Bad_Speculation) ) ; 
N = 4*CPU_CLK_UNHALTED.THREAD" (for SandyBridge)

Andi Kleenのpmu-tools（toplev.py）で行われたように、適切な式はいくつかの外部スクリプトで使用できます：https：//github.com/andikleen/pmu-tools（source）、http：//halobates.de/blog/ p / 262（説明）：

% toplev.py -d -l2 numademo  100M stream
...
perf stat --log-fd 4 -x, -e
{r3079,r19c,r10401c3,r100030d,rc5,r10e,cycles,r400019c,r2c2,instructions}
{r15e,r60006a3,r30001b1,r40004a3,r8a2,r10001b1,cycles}
numademo 100M stream
...
BE      Backend Bound:                      72.03%
    This category reflects slots where no uops are being delivered due to a lack
    of required resources for accepting more uops in the    Backend of the pipeline.
 .....
FE      Frontend Bound:                     54.07%
This category reflects slots where the Frontend of the processor undersupplies
its Backend.

元のユニバーサルの代わりに、stalled-cycles-frontendイベントとstalled-cycles-backendイベントを導入したコミットstalled-cycles：

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a

author  Ingo Molnar <mingo@el...>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <mingo@el...>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)

perfイベント：一般的なフロントエンドとバックエンドのストールサイクルイベント定義を追加します。2つの一般的なハードウェアイベントを追加します：フロントエンドとバックエンドのストールサイクル。

これらのイベントは、CPUがコードを実行しているが、その機能が十分に活用されていない場合の状態を測定します。このような状況を理解して分析することは、コード最適化ワークフローの重要なサブタスクです。

どちらのイベントもパフォーマンスを制限します。ほとんどのフロントエンドストールは、ブランチの予測ミスまたは命令フェッチキャッシュミスによって引き起こされる傾向があり、バックエンドストールは、さまざまなリソース不足または非効率的な命令スケジューリングによって引き起こされる可能性があります。

フロントエンドのストールはより重要なものです。命令ストリームが維持されていないと、コードを高速に実行できません。

バックエンドを使いすぎると、フロントエンドがストールする可能性があるため、同様に注意を払う必要があります。

正確な構成は、プログラムロジックと命令ミックスに大きく依存します。

「ストール」、「フロントエンド」、「バックエンド」という用語を大まかに使用し、これらの概念に近い特定のCPUから利用可能な最良のイベントを使用しようとします。

Cc：Peter Zijlstra Cc：Arnaldo Carvalho de Melo Cc：Frederic Weisbeckerリンク：http：//lkml.kernel.org/n/tip-7y40wib8n000io7hjpn1dsrm@git.kernel.org 署名者：Ingo Molnar

    /* Install the stalled-cycles event: UOPS_EXECUTED.CORE_ACTIVE_CYCLES,c=1,i=1 */
-       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES] = 0x1803fb1;
+       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x1803fb1;

-   PERF_COUNT_HW_STALLED_CYCLES        = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_FRONTEND   = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_BACKEND    = 8,