從上到下的系統(tǒng)架構分析方法Intel PMU的詳細資料概述

引言

現(xiàn)代 CPU 大多具有性能監(jiān)控單元（Performance Monitoring Unit, PMU)，用于統(tǒng)計系統(tǒng)中發(fā)生的特定硬件事件，例如緩存未命中（Cache Miss）或者分支預測錯誤（Branch Misprediction）等。同時，多個事件可以結合計算出一些高級指標，例如每指令周期數(shù)（CPI），緩存命中率等。一個特定的微體系架構可以通過 PMU 提供數(shù)百個事件。對于發(fā)現(xiàn)和解決特定的性能問題，我們很難從這數(shù)百個事件中挑選出那些真正有用的事件。 這需要我們深入了解微體系架構的設計和 PMU 規(guī)范，才能從原始事件數(shù)據(jù)中獲取有用的信息。

自頂向下的微體系架構分析方法（Top-Down Microarchitecture Analysis Method, TMAM）可以在亂序執(zhí)行的內(nèi)核中識別性能瓶頸，其通用的分層框架和技術可以應用于許多亂序執(zhí)行的微體系架構。TMAM 是基于事件的度量標準的分層組織，用于確定應用程序中的主要性能瓶頸，顯示運行應用程序時 CPU 流水線的使用情況。

概述

現(xiàn)代高性能 CPU 的流水線非常復雜。 一般來說，CPU 流水線在概念上分為兩部分，即前端（Front-end）和后端（Back-end）。Front-end 負責獲取程序代碼指令，并將其解碼為一個或多個稱為微操作（uOps）的底層硬件指令。uOps 被分配給 Back-end 進行執(zhí)行，Back-end 負責監(jiān)控 uOp 的數(shù)據(jù)何時可用，并在可用的執(zhí)行單元中執(zhí)行 uOp。 uOp 執(zhí)行的完成稱為退役（Retirement），uOp 的執(zhí)行結果提交并反饋到>架構狀態(tài)（CPU 寄存器或?qū)懟貎?nèi)存）。 通常情況下，大多數(shù) uOps 通過流水線正常執(zhí)行然后退役，但有時候投機執(zhí)行的 uOps 可能會在退役前被取消，例如在分支預測錯誤的情況下。

在最近的英特爾微體系結構上，流水線的 Front-end 每個 CPU 周期（cycle）可以分配4個 uOps ，而 Back-end 可以在每個周期中退役4個 uOps。 流水線槽（pipeline slot）代表處理一個 uOp 所需的硬件資源。 TMAM 假定對于每個 CPU 核心，在每個 CPU 周期內(nèi)，有4個 pipeline slot 可用，然后使用專門設計的 PMU 事件來測量這些 pipeline slot 的使用情況。在每個 CPU 周期中，pipeline slot 可以是空的或者被 uOp 填充。 如果在一個 CPU 周期內(nèi)某個 pipeline slot 是空的，稱之為一次停頓（stall）。如果 CPU 經(jīng)常停頓，系統(tǒng)性能肯定是受到影響的。TMAM 的目標就是確定系統(tǒng)性能問題的主要瓶頸。

下圖展示并總結了亂序執(zhí)行微體系架構中自頂向下確定性能瓶頸的分類方法。這種自頂向下的分析框架的優(yōu)點是一種結構化的方法，有選擇地探索可能的性能瓶頸區(qū)域。 帶有權重的層次化節(jié)點，使得我們能夠?qū)⒎治龅闹攸c放在確實重要的問題上，同時無視那些不重要的問題。

例如，如果應用程序性能受到指令提取問題的嚴重影響， TMAM 將它分類為 Front-end Bound 這個大類。 用戶或者工具可以向下探索并僅聚焦在 Front-end Bound 這個分類上，直到找到導致應用程序性能瓶頸的直接原因或一類原因。

設計

Top Level

在最頂層，TMAM 將 pipeline slot 分為四個主要類別：

Front-end Bound

1Front-endBound表示pipeline的Front-end不足以供應Back-end。

Front-end是pipeline的一部分，負責交付uOps給Back-end執(zhí)行。

Front-endBound進一步分為FetchLatency（例如，ICacheorITLBmisses）

和FetchBandwidth（例如，sub-optimaldecoding）。

Back-end Bound

1Back-endBound表示由于缺乏接受執(zhí)行新操作所需的后端資源而導致

停頓的pipelineslot。它進一步分為分為MemoryBound（由于內(nèi)存子系統(tǒng)造成的

執(zhí)行停頓）和CoreBound（執(zhí)行單元壓力ComputeBound或者缺少指令級并行ILP）。

Bad Speculation

1BadSpeculation表示由于分支預測錯誤導致的pipelineslot被浪費，

主要包括(1)執(zhí)行最終被取消的uOps的pipelineslot，以及(2)由于從

先前的錯誤猜測中恢復而導致阻塞的pipelineslot。

Retiring

1Retiring表示運行有效uOp的pipelineslot。理想情況下，

我們希望看到所有的pipelineslot都能歸類到Retiring，

因為它與IPC密切相關。盡管如此，高Retiring比率并不意味著沒有提升優(yōu)化的空間。

后兩者表示非停頓的 pipeline slot，前兩者表示停頓的 pipeline slot。 下圖描述了一個簡單的決策樹來展示向下分析的過程。如果一個 pipeline slot 被某個 uOp 使用，它將被分類為 Retiring 或 Bad Speculation，具體取決于它是否最終提交。如果 pipeline 的 Back-end 部分不能接受更多操作（也稱為 Back-end Stall），未使用的 pipeline slot 被分類為 Back-end Bound。Front-end Bound 則表示>在沒有 Back-end Stall 的情況下沒有操作（uOps）被分配執(zhí)行。

Front-end Bound

在許多情況下，F(xiàn)ront-end 指令帶寬可能會影響性能，特別是在高 IPC 的情況下。一些專用單元被引入，用來隱藏流水線 Fetch 指令延遲以及維持所需的帶寬，例如 Loop Stream Detector (LSD) 以及 Decoded I-cache (DSB)。

TMAM 進一步將 Front-end Bound 劃分為延遲和帶寬兩個子類：

ICache miss 屬于 Fetch Latency 分類

指令解碼器的低效問題屬于 Fetch Bandwidth 分類

這些度量標準都是以自頂向下的方式定義的。Fetch Latency 表示任何原因?qū)е碌闹噶钐崛○囸I（沒有指令輸送）。我們所熟知的 icache and i-TLB miss 就屬于這個類別，但是并不局限于此。Branch Resteers 表示流水線刷新（pipeline flush）之后的指令提取延遲。pipeline flush 可能由一些清除狀態(tài)的事件引起，例如 branch misprediction 或者 memory nukes。Branch Resteers 與 Bad Speculation 密切相關。

Back-end Bound

Back-end Bound 分為 Memory Bound 和 Core Bound，通過在每個周期內(nèi)基于執(zhí)行單元的占用情況來分析 Back-end 停頓。為了達到盡可能大的 IPC，需要使得執(zhí)行單元保持繁忙。例如，在一個有4個 slot 的機器中，如果在穩(wěn)定狀態(tài)下只能執(zhí)行三個或更少的 uOps，就不能達到最佳狀態(tài)，即 IPC 等于4。這些次優(yōu)周期稱為 Execution Stalls。

Memory Bound

1MemoryBound對應緩存和內(nèi)存子系統(tǒng)相關的ExecutionStalls。這些停頓通常表現(xiàn)為執(zhí)行單元在短時間內(nèi)饑餓，例如load操作沒有在緩存中命中。對于常見情況，內(nèi)存訪問的真正代價是調(diào)度程序沒有其他準備好的uOps提供給執(zhí)行單元。后面的uOps可能正在等待進行中的內(nèi)存訪問，或者依賴于其他未準備好的uOps。23ExecutionStalls包含幾個子類，每個子類都與特定的高速緩存級別相關聯(lián)，取決于各個高速緩存級別是否可以滿足所需的數(shù)據(jù)。在某些情況下，ExecutionStall可能會經(jīng)歷顯著的延遲，遠遠大于相應緩存級別的標準延遲，即使沒有發(fā)生相應的緩存未命中。例如，L1D高速緩存通常具有與ALU停頓相當?shù)妮^短的延遲。然而在某些情況下，如load操作被阻塞，無法將數(shù)據(jù)從較早的store操作轉發(fā)（forward）到一個重疊地址，這個load負載可能會遭受較高的延遲，雖然最終能在L1D中命中。在這種情況下，in-flight的load操作將持續(xù)很長時間并且不會產(chǎn)生L1Dmiss。因此，這個問題屬于L1Bound子類。45此外，與store操作相關的ExecutionStalls都屬于StoresBound子類。由于內(nèi)存訪問順序要求，store操作被緩存并異步執(zhí)行。通常，store操作對性能影響很小，但不能完全忽視。TMAM將StoresBound定義為那些執(zhí)行端口利用率（executionportutilization）較低，以及存在大量需要消耗資源用來緩沖store操作的周期。67最后，TMAM在Ext.MemoryBound子類下使用了一個簡單的啟發(fā)式算法來區(qū)分MEMBandwidth和MEMLatency。該啟發(fā)式算法的主要根據(jù)是當前有多少請求依賴從內(nèi)存中獲取的數(shù)據(jù)。每當這類請求的占用率超過一個高閾值時（例如最大請求數(shù)的70％），TMAM將其標記為可能受內(nèi)存帶寬的限制。其他部分都屬于內(nèi)存延遲子類。

Core Bound

1CoreBound對應于執(zhí)行單元存在壓力或者程序中缺少指令級別并行（ILP）。Corebound的

停頓可能表現(xiàn)為較短的執(zhí)行饑餓周期或者執(zhí)行端口利用率不佳，這使得識別Corebound比較困難。

例如，一個長延遲的除法操作可能會序列化執(zhí)行，而服務于特定類型uOps的執(zhí)行端口上的壓力

可能表現(xiàn)為一個周期內(nèi)只有少量端口被使用。23CoreBound的問題一般可以通過更好的代碼生成來緩解。例如，一系列相關的算術

運算將被標記為CoreBound。編譯器可以通過更好的指令調(diào)度來緩解這種停頓。

矢量化（Vectorization）也可以緩解CoreBound的問題。

Bad Speculation

Bad Speculation 表示由于不正確的預測而浪費的 pipeline slot，主要包括兩部分：

執(zhí)行了最終不會被提交的 uOps 的 slots

從錯誤預測中恢復而導致流水線被阻塞的 slots

TMAM 的一個關鍵原則就是將 Bad Speculation 放在了最頂層， Bad Speculation 確定了受到錯誤執(zhí)行路徑影響的工作負載的比例，并反過來決定了其他類別中觀察值的準確性。TMAM 進一步將 Bad Speculation 分類為 Branch Mispredict 和 Machine Clears，這兩種情況導致的問題和 pipeline flush 相像。Branch Mispredict 主要關注如何使程序控制流對分支預測更友好，Machine Clears 則主要指出一些異常情況，例如清除內(nèi)存排序機（memory ordering machine clears）或者自修改代碼（self modifying code）。

Retiring

理想情況下，我們希望看到所有的 slots 都被標記為 Retiring 類別。盡管如此，Retiring 比例高并不意味著沒有更多的性能提升空間。諸如 Floating Point Assists (FP_ASSISTS) 的微指令（Microcode）序列通常會影響性能并且可以避免。這類情況被標記為 MSROM 子類以便引起注意。

非矢量化（non-vectorized）代碼的高 Retiring 比值可能是進行向量化（vectorization）代碼的一個重要提示。這樣做基本上可以讓更多的操作通過單指令 uOp 完成，從而提高性能。TMAM 進一步將 Retiring->Base 子類劃分為 FP Arith，并區(qū)分標量操作和矢量操作。

應用/工具

pmu-tools 是 Adni Kleen 開發(fā)的開源工具包，針對 Intel CPU 提供友好的接口來訪問原始事件，并提供一些附加功能。toplev 是 pmu-tools 中的一個工具，在 Intel CPU 的 Linux perf 基礎上實現(xiàn)了 TMAM 方法。toplev 可以定位 CPU Bound 代碼的瓶頸，不能識別其他（Not bound by CPU）代碼的瓶頸。toplev 是一個計數(shù)工具，它使用 PMU 來計數(shù)事件。toplev 的一個典型使用場景是，用戶已經(jīng)根據(jù)一個標>準工具（例如 perf, sysprof, pyprof）進行采樣，了解 hot code 的分布，但是你想知道為什么這部分代碼運行很慢。

安裝

toplev 在 Linux 上運行，需要安裝 perf 工具。toplev 還需要訪問 PMU，在 VM 中運行時需要注意啟用這個特性。注意，toplev 需要禁用 NMI watchdog，并以 root 身份運行。

1%gitclonehttps://github.com/andikleen/pmu-tools2%cdpmu-tools3%exportPATH=$PATH:`pwd`4%sudosysctl-p'kernel.nmi_watchdog=0'

確定 CPU Bound 任務

第一步是確定程序是否真的是 CPU Bound 型工作負載。toplev 只能幫助定位解決 CPU Bound 問題。如果瓶頸在其他地方，則必須使用其他方法。非 CPU 瓶頸可以是網(wǎng)絡，磁盤IO，顯卡等。

選擇要計數(shù)的代碼

一般來說toplev測量整個系統(tǒng)的性能數(shù)據(jù)；當指定一個工作負載時，toplev將在工作負載運行的時間段內(nèi)測量整個系統(tǒng)，這一點和perf的使用是類似的。

1%toplev.pymy-workload2或者3%toplev.pysleepXXX

讓我們衡量一個簡單的工作負載。這是一個 bc 表達式，在作者電腦上運行大約1秒（在大多數(shù)情況下，使用長時間運行的工作負載可能會更好），使用第一層級（-lxxx 參數(shù)用來設定測量的最大層級）運行以避免任何 PMU 計數(shù)器的多路復用。

1%toplev.py-l1bash-c'echo"7^199999"|bc>/dev/null' 2Willmeasurecompletesystem. 3Usinglevel1. 4... 5C0BADBad_Speculation:31.66% 6Thiscategoryreflectsslotswastedduetoincorrect 7speculations,whichincludeslotsusedtoallocateuopsthat 8donoteventuallygetretiredandslotsforwhichallocation 9wasblockedduetorecoveryfromearlierincorrect10speculation...11C1FEFrontend_Bound:42.46%12ThiscategoryreflectsslotswheretheFrontendofthe13processorundersuppliesitsBackend...14C1BEBackend_Bound:27.25%15Thiscategoryreflectsslotswherenouopsarebeing16deliveredduetoalackofrequiredresourcesforaccepting17moreuopsintheBackendofthepipeline...18C0-T0CPUutilization:0.00CPUs19NumberofCPUsused...20C0-T1CPUutilization:0.00CPUs21C1-T0CPUutilization:0.00CPUs22C1-T1CPUutilization:0.00CPUs

每當首次打印層節(jié)點時，toplev 都會打印一個描述。默認情況下，它顯示一個簡短描述，長描述可以使用--long-desc來啟用。在之后的例子中，我們禁用描述以獲得較短的輸出。toplev 輸出中，一些值以 core 為單位，另一些則以 thread 為單位收集。多 socket 的情況下還會有 socket 分類。

上面的例子中，我們沒有將工作負載（bc）綁定到某個 CPU，所以不清楚 C0 或 C1 的值是否相關。由于 bc 是單線程的，我們可以將它綁定到一個已知的 CPU 核心，并使用--core來過濾該核心上的輸出。

1%toplev.py--coreC0--no-desc-l1taskset-c0bash-c'echo"7^199999"|bc>/dev/null'2Willmeasurecompletesystem.3Usinglevel1.4...5C0BADBad_Speculation:33.29%6C0-T0CPUutilization:0.00CPUs7C0-T1CPUutilization:0.00CPUs

可以結合 taskset 綁定到更多的 CPU 進行多線程工作，并將結果進行過濾。結果顯示bc受限于 Bad Speculation?，F(xiàn)在我們可以選擇更多的節(jié)點并更詳細地分析問題。

如果已知工作負載是單線程的，并且系統(tǒng)當前空閑，那么也可以顯式指定--single-thread選項來測量工作負載，而不是默認測量整個系統(tǒng)

1%toplev.py--no-desc--single-threadbash-c'echo"7^199999"|bc>/dev/null'2..3BADBad_Speculation:32.65%4CPUutilization:0.00CPUs

程序在初始化階段的行為相比生命周期后期的行為有很大的差異。為了精確測量，跳過這個階段通常是有用的。這可以用-D xxx選項來完成，xxx是跳過的毫秒數(shù)（需要較新版本的 perf）。當程序運行時間足夠長時，這通常是不需要的，但是它有助于提高小測試的精度。默認情況下，toplev 同時測量內(nèi)核和用戶代碼。如果只對用戶代碼感興趣，則可以使用--user選項。這往往會減少測量噪聲，因為中斷被過濾掉了。還有一個--kernel選項用來測量內(nèi)核代碼。在具有多個階段的復雜工作負載上，測量間隔也是有用的。這可以用-I xxxi選項指定，xxx是間隔的毫秒數(shù)。perf 要求時間間隔至少需要 100ms。toplev 將輸出每個間隔的測量值。這往往會產(chǎn)生大量的數(shù)據(jù)，所以繪制輸出很有必要。

選擇正確的層次和多路復用

PMU 只有有限數(shù)量的計數(shù)器可以同時測量事件。任何多于一個層次的 toplev 運行，或者啟動了額外的CPU 指標，則需要更多的計數(shù)器。在這種情況下，內(nèi)核驅(qū)動程序?qū)㈤_始多路復用（Multiplexing），并定期更改事件組（在1毫秒和10毫秒之間，通常2.5毫秒，取決于內(nèi)核配置）。多路復用可能會導致測量錯誤，因為 toplev 中的幾個節(jié)點中的公式需要關聯(lián)多個事件組的數(shù)據(jù)。因此 toplev 在反復執(zhí)行同樣事情的工作負載上效果最好，但在執(zhí)行許多不同的短事件的工作負載上效果不佳。

只要沒有使用 PMU 的或者有問題的其他工作負載處于活動狀態(tài)，則第一層次（-l1）和未啟用額外指標的 toplev 不會進行多路復用。一開始的時候，不采用多路復用來進行分析通常是一個好主意。更高的層次和指標提供了額外的信息，但也增加了復用，因此可能導致更多的測量錯誤。如果工作負載非常重復，可以使用--no-multiplex關閉復用。toplev 會根據(jù)需要多次重新運行工作量。在 BIOS 中禁用超線程將使通用計數(shù)器的數(shù)量增加一倍，并減少多路復用。

有關問題的更多詳細信息和解決方法，可以參閱 reasons for measuring issues

數(shù)組求和實例的測試分析

我們考慮測量一些 beating the compiler 的例子。beating the compiler 實現(xiàn)了一個簡單的問題，即數(shù)組求和，從高級腳本語言開始，然后利用底層操作逐步優(yōu)化。測試代碼運行在啟用了 Turbo 的 Intel Core i7-4600U（Haswell）筆記本電腦上。

開始是簡單直接的Python實現(xiàn)。

1defsum_naive_python():2result=03foriindata:4result+=i5returnresult

我們用 toplev 來運行這段代碼，跳過初始化階段（大約80毫秒，通過預先測量得到）。一般來說，測量太短的程序是很困難的（太多的其他影響占主導地位）。在這種情況下，我們通過迭代5000次測試來調(diào)試程序運行至少幾秒鐘。

1%toplev.py-D80-l1--no-desc--coreC0taskset-c0pythonfirst.pynumbers2..3C0FEFrontend_Bound:22.08%4C0RETRetiring:75.01%

所以 Python 是一點 Front-end Bound，但是從 toplev 中沒有其他發(fā)現(xiàn)可見的問題。我們可以通過將層級提高到3來更仔細地分析 Front-end Bound。注意這可能有缺點，因為它會導致多路復用。在這種情況下，工作負載運行時間越長越好（我們將基準函數(shù)循環(huán)5000次）。

1%toplev.py-D80-l3--coreC0taskset-c0pythonfirst.pynumbers 2... 3C0FEFrontend_Bound:21.91% 4C0FEFrontend_Bound.Frontend_Bandwidth:15.91% 5C0FEFrontend_Bound.Frontend_Bandwidth.DSB:32.11% 6ThismetricrepresentsCorecyclesfractioninwhichCPUwas 7likelylimitedduetoDSB(decodeduopcache)fetch 8pipeline... 9C0RETRetiring:74.97%10C0RETRetiring.Base:74.88%

可以觀察到 Front-end Bound 是 DSB (decoded uop cache) fetch。具體描述被簡化了，可以使用--long-desc來查看更具體的描述。

讓我們來看看第二個 Python 版本。這個版本使用 Python 中的內(nèi)建函數(shù) sum() 來數(shù)組求和，以便將更多的執(zhí)行動作從解釋器推送到 Python C 核心。

1defsum_builtin_python():2returnsum(data)

在這種情況下，我們知道 python 代碼是單線程的（系統(tǒng)的其余部分是空閑的），所以可以使用--single-thread。

1%toplev.py--single-thread-l3-D80pythonsecond.pynumbers2...3FEFrontend_Bound:27.40%4FEFrontend_Bound.Frontend_Bandwidth:23.20%5FEFrontend_Bound.Frontend_Bandwidth.DSB:46.30%6ThismetricrepresentsCorecyclesfractioninwhichCPUwas7likelylimitedduetoDSB(decodeduopcache)fetch8pipeline...

然而這并沒有改變多少結果。Python 是相當重（heavy-weight）的，大大加重了 CPU 的前端，但其中大部分至少在解碼的 icache 中運行。

現(xiàn)在我們來看一個標準的C實現(xiàn)，它應該快得多：

1intsum_simple(int*vec,size_tvecsize)2{3intres=0;4inti;5for(i=0;i

這個循環(huán)被編譯成一個簡單的測試工具，使用 gcc 4.8.3 并關閉優(yōu)化，使用 toplev 進行測量：

1%toplev.py-l1--single-thread--force-events./c1-unoptimizednumbers2BEBackend_Bound:60.34%3Thiscategoryreflectsslotswherenouopsarebeing4deliveredduetoalackofrequiredresourcesforaccepting5moreuopsintheBackendofthepipeline...

這個版本比 Python 版本運行速度快4倍。瓶頸已經(jīng)完全進入 Back-end。我們可以在第三層級更仔細地看待它：

1%toplev.py-l3--single-thread--force-events./c1-unoptimizednumbers 2BEBackend_Bound:60.42% 3BE/MemBackend_Bound.Memory_Bound:32.23% 4BE/MemBackend_Bound.Memory_Bound.L1_Bound:32.44% 5ThismetricrepresentshowoftenCPUwasstalledwithout 6missingtheL1datacache... 7Samplingevents:mem_load_uops_retired.l1_hit:pp,mem_load_uops_retired.hit_lfb:pp 8BE/CoreBackend_Bound.Core_Bound:45.93% 9BE/CoreBackend_Bound.Core_Bound.Ports_Utilization:45.93%10Thismetricrepresentscyclesfractionapplicationwas11stalledduetoCorecomputationissues(nondivider-12related)...

可以看到它是 L1 Bound 和 Core Bound。 L1 Bound 可能是因為未優(yōu)化的 gcc 代碼傾向于將所有變量存儲在堆棧上，沒有進行全面的寄存器優(yōu)化。 我們可以用-O2打開優(yōu)化器，看看會發(fā)生什么：

1%toplev.py-l3--single-thread./c1-o2numbers2RETRetiring:83.66%3RETRetiring.Base:83.62%4ThismetricrepresentsslotsfractionwheretheCPUwas5retiringuopsnotoriginatedfromthemicrocode-sequencer...6Samplingevents:inst_retired.prec_dist:pp

L1 Bound 完全消失，工作負載的大部分時間都在 Retire，這是很好的。這個版本也比未優(yōu)化的C版本快了85％。注意這些好處有些極端的情況，可能完全取決于代碼的行為。

優(yōu)化 Retiring 的一種方法是對代碼進行矢量化（Vectorization），并在每條指令上做更多的工作。通過gcc -O3啟用矢量化。不幸的是，它不能矢量化我們簡單的循環(huán)。

1c1.c:9:note:notvectorized:notsuitableforgatherload_32=*_31;

我們可以從 beating the compiler 中嘗試Roguelazer手動優(yōu)化的內(nèi)嵌匯編 AVX2 版本。這應該會減少 Retiring，因為它在每個 SIMD 指令中可以執(zhí)行多達8個加法，同時它還使用了循環(huán)展開。

1%toplev.py-l3--single-thread./c-asmnumbers 2BEBackend_Bound:64.15% 3BE/MemBackend_Bound.Memory_Bound:... 4BE/MemBackend_Bound.Memory_Bound.L1_Bound:49.32% 5ThismetricrepresentshowoftenCPUwasstalledwithout 6missingtheL1datacache... 7Samplingevents:mem_load_uops_retired.l1_hit:pp,mem_load_uops_retired.hit_lfb:pp 8BE/MemBackend_Bound.Memory_Bound.L3_Bound:48.68% 9ThismetricrepresentshowoftenCPUwasstalledonL3cache10orcontendedwithasiblingCore...11Samplingevents:mem_load_uops_retired.l3_hit:pp12BE/CoreBackend_Bound.Core_Bound:28.27%13BE/CoreBackend_Bound.Core_Bound.Ports_Utilization:28.27%14Thismetricrepresentscyclesfractionapplicationwas15stalledduetoCorecomputationissues(nondivider-16related)...

Retiring 瓶頸已經(jīng)消失，我們終于看到了 Backend_Bound.Memory_Bound 瓶頸，在這種情況下，L1 Bound 和 L3 Bound所占百分比幾乎相等，其余的是核心執(zhí)行。