Top-Down Microarchitecture Analysisとは何か(3. Top-Down Analysis の主要カテゴリと計算要素)

前回の続き。

msyksphinz.hatenablog.com

Top-Down Analysis の主要カテゴリと計算要素

カテゴリ	計算式（概念）	主な構成イベント	意味
Bad Speculation	(SlotsIssued − SlotsRetired + RecoveryBubbles) / TotalSlots	SlotsIssued, SlotsRetired, RecoveryBubbles	実行されたが無駄になった slot + 回復中の空き slot
Frontend Bound	FetchBubbles / TotalSlots	FetchBubbles	Backend は受け取れるが frontend が uop を供給できない
Backend Bound	1 − (Retiring + BadSpeculation + FrontendBound)	上記3つの補数	Backend 側の資源不足による stall
Retiring	SlotsRetired / TotalSlots	SlotsRetired	正しく実行された uop

各イベントの意味

Top-Down Analysis の理解で重要なのは、各イベントが何を意味しているかである。

• TotalSlots: CPU が理論的に利用可能な issue slot 数 = issue width × cycle 数
• SlotsIssued: 実際に uop が発行された slot 数
• SlotsRetired: 最終的に commit された uop の slot 数
• FetchBubbles: backend は受け取れる状態だが frontend が uop を供給できなかった slot
• RecoveryBubbles: misprediction などの回復中に失われた slot

Top-Down Analysis の探索順序まとめ

function analyze_topdown (metrics)
    # Top-Level classification
    if metrics.BadSpeculation is large:
        analyze_bad_speculation(metrics)
        return
    if metrics.FrontendBound is large:
        analyze_frontend(metrics)
        return
    if metrics.BackendBound is large:
        analyze_backend(metrics)
        return
    # If none dominates
    report("No dominant bottleneck; workload is well balanced")
    return

---

Bad Speculation の解析 (analyze_bad_speculation)

function analyze_bad_speculation(metrics)
    if metrics.BranchMispredict is large:
        report("Branch misprediction bound")
        suggest("improve branch predictability, restructure control flow")
        return
    if metrics.MachineClears is large:
        report("Machine clear / speculation failure")
        suggest("check memory ordering, unexpected pipeline flush causes")
        return
    report("General speculation overhead")

サブカテゴリ	計算	意味
Branch Mispredict	BrMispredRetired / (BrMispredRetired + MachineClears) × BadSpeculation	分岐予測ミスによる無駄
Machine Clears	BadSpeculation − BranchMispredict	パイプラインフラッシュ系

Bad Speculation とは何か

Bad Speculation は「投機実行の失敗によって無駄になった slot」である。

具体例は次の通りである。

• branch misprediction
• machine clear
• memory ordering violation

ここで論文の重要な設計思想がある。それは「speculation は最初に評価する」ということである。理由は明確である。speculation の割合が大きい場合「他のイベントの信頼性が低下する」ためである。

例えば branch misprediction が大量に発生している状態では「cache miss の統計」を見ても意味が薄い。なぜなら「間違った経路の命令」も実行されているからである。

そのため Top-Down Analysis では Bad Speculation を Top-Level に配置している。

Frontend Bound の解析

function analyze_frontend(metrics):
    if metrics.FrontendLatency is large:
        report("Frontend latency bound")
        check:
            - i-cache miss
            - iTLB miss
            - branch resteer
        return
    if metrics.FrontendBandwidth is large:
        report("Frontend bandwidth bound")
        check:
            - decoder throughput
            - uop cache / fetch width
        return
    report("General frontend inefficiency")

サブカテゴリ	計算	意味
Frontend Latency	FetchBubbles（大きなバブルのみ） / Clocks	i-cache miss, iTLB miss, branch recovery
Frontend Bandwidth	FrontendBound − FrontendLatency	decode / fetch 幅不足

Frontend Bound とは何か

Frontend Bound とは「backend は実行可能」「しかし frontend が uop を供給できない」状態である。つまり CPU の実行ユニットは空いているのに命令が来ない。

典型的な原因は次の通りである。

• i-cache miss
• iTLB miss
• branch resteer
• decode bandwidth 不足

ここで重要なのは「frontend で問題が起きた」ことではなく「backend が idle になった」ことである。Top-Down Analysis は常に「性能に影響したかどうか」を基準に分類する。

ここが従来のイベントベース解析と異なる点である。

---

Frontend Bound はさらに分解される

Frontend Bound はさらに次の2種類に分解される。

• Frontend Latency Bound
• Frontend Bandwidth Bound

これは非常に重要な区別である。

---

• Frontend Latency Bound

これは「命令が来るまで待たされている」状態である。

例えば

• i-cache miss
• iTLB miss
• branch misprediction recovery

などである。

---

• Frontend Bandwidth Bound

これは「命令は来ているが供給量が足りない」状態である。

例えば

• decoder throughput 不足
• fetch 幅不足
• uop supply 不足

などが該当する。この区別は最適化方針を決める上で非常に重要である。