在這個算力需求爆炸的大背景下，如何發(fā)揮出已有硬件的最大算力變得非常重要，直觀一點是：我們需要對現(xiàn)有算法，針對特定處理器，進行極致的性能優(yōu)化，盡量滿足目前 AI 算法對算力高要求。

為了能夠做到極致的性能優(yōu)化，可實現(xiàn)的方向有：

• 優(yōu)化算法，使得算法能夠在滿足準確度前提下，訪存和計算量盡量小
• 優(yōu)化程序，使得實現(xiàn)這些算法的程序最大限度發(fā)揮處理器性能

在優(yōu)化程序的過程中，首先要解決的問題是：如何評估程序發(fā)揮了處理器幾成的算力，以及進一步優(yōu)化空間和優(yōu)化方向。

為了讓我們更懂處理器，MegEngine 團隊開發(fā)了一個處理器調(diào)試工具 MegPeak。

該工具主要用于幫助開發(fā)人員進行性能評估，開發(fā)指導(dǎo)等工作，項目代碼目前已完全開源，大家感興趣的話可以看下。

GitHub：??https://github.com/MegEngine/MegPeak???

下面我們來簡單看下，這款工具所擁有的功能，以及項目的技術(shù)實現(xiàn)細節(jié)。

MegPeak 介紹

通過 MegPeak，用戶可以測試目標處理器：

• 指令的峰值帶寬
• 指令延遲
• 內(nèi)存峰值帶寬
• 任意指令組合峰值帶寬

雖然上面的部分信息可以通過芯片的數(shù)據(jù)手冊查詢相關(guān)數(shù)據(jù)，然后結(jié)合理論計算得到，但是很多情況下無法獲取目標處理器詳盡的性能文檔，另外通過 MegPeak 進行測量更直接和準確，并且可以測試特定指令組合的峰值帶寬。

MegPeak 使用方法

使用方法參考 MegPeak 的 Readme 文檔：

??https://github.com/MegEngine/MegPeak#build???

MegPeak 使用示例

測試 ArmV8 上通用指令峰值和延遲，編譯完成之后，在目標處理器上執(zhí)行 megpeak，得到：

如上圖所示，MegPeak 可以精確測試出 CPU 上每條指令的計算峰值以及延遲周期。OpenCL 上將測試出不同數(shù)據(jù)類型進行訪存的 Local Memory，Global Memory 的帶寬，以及 int/float 不同數(shù)據(jù)類型進行計算的峰值。

這些數(shù)值，將有效指導(dǎo)我們評估目前程序的性能，并繪制 RoofLine，幫助用戶診斷出阻塞程序主要因素，是訪存或者計算。具體使用分析方法將在后面介紹。

MegPeak 原理

MegPeak 測試的主要參數(shù)是：

• CPU 不同指令的計算峰值，以及指令延遲，以及內(nèi)存帶寬
• OpenCL 中不同內(nèi)存的數(shù)據(jù)訪存帶寬，以及不同計算數(shù)據(jù)類型的計算峰值

要了解 MegPeak 是如何測試出上面這些性能數(shù)據(jù)，并且做到和數(shù)據(jù)手冊上查詢到盡量一致，因此需要讀者了解下面 CPU 流水線相關(guān)細節(jié)。

處理器流水線

現(xiàn)代處理器為了增加指令的吞吐，引入了指令流水線，指令流水線可以將一條指令的執(zhí)行過程劃分為多個階段，經(jīng)典的 5 級流水線有：取指令，翻譯指令，執(zhí)行指令，訪問寄存器，寫回數(shù)據(jù)。

這 5 個階段，處理器中執(zhí)行每個階段的物理單元獨立，因此理想狀態(tài)下，每個時鐘周期每個階段對應(yīng)的物理單元都能執(zhí)行一次對應(yīng)的操作，這樣就形成了流水線，這樣處理器每個時鐘周期就可以完成執(zhí)行一條指令。

如下表所示，從第 5 個時鐘周期之后，每個時鐘周期都會完成一條指令執(zhí)行：

但是，流水線在實際執(zhí)行時候不可能一直這樣流暢的執(zhí)行下去，會存在以下的冒險，阻塞流水線。

• 結(jié)構(gòu)冒險 —— 如果硬件無法同時支持指令的所有可能組合方式，就會出現(xiàn)資源沖突，從而導(dǎo)致結(jié)構(gòu)冒險
• 數(shù)據(jù)冒險 —— 流水線指令存在先后順序，如果一條指令取決于先前指令的結(jié)果，就可能導(dǎo)致數(shù)據(jù)冒險
• 控制冒險 —— 分支指令及其他改變程序計數(shù)器的指令實現(xiàn)流水化時，可能導(dǎo)致控制冒險

MegPeak 中測量處理器指令的計算峰值和延遲就是通過控制指令間的數(shù)據(jù)冒險，盡可能排除結(jié)構(gòu)冒險和控制冒險來實現(xiàn)的。因為 MegPeak 中需要通過寫 Code 來控制處理器的數(shù)據(jù)冒險，為了排除編譯器編譯 code 時候的優(yōu)化帶來的干擾，所以在 MegPeak 在測試中的核心代碼使用匯編來實現(xiàn)的。

測試指令峰值

為了測量處理器上一條指令的計算峰值，我們需要寫出重復(fù)執(zhí)行這條指令，但是沒有任何冒險的代碼，所以需要代碼控制數(shù)據(jù)冒險和控制冒險。

•   消除數(shù)據(jù)冒險 ---- 消除重復(fù)指令之間的數(shù)據(jù)依賴，讓前后指令之間沒有下面的數(shù)據(jù)相關(guān)，雖然 WAW，WRA 不是真正的數(shù)據(jù)相關(guān)，處理器可能會使用寄存器重命名來解決，但是我們還是盡量不要寫出這樣的數(shù)據(jù)相關(guān)。
  

•   寫后讀（RAW）：上一條指令寫入，下一條指令讀取寫入數(shù)據(jù)，這時候后一條指令需要等上一條指令運行結(jié)束之后再運行
  
•   寫后寫（WAW）：兩條指令前后寫入同一個寄存器，這時候數(shù)據(jù)寫入的先后順序很重要
  
•   讀后寫（WRA） ：上一條指令讀取一個寄存器，下一條指令將新的數(shù)據(jù)寫入這個寄存器，他們的順序也同樣很重要
  

•  盡可能的消除控制冒險 ---- 為了重復(fù)多次執(zhí)行同一條指令，我們可能會用循環(huán)來實現(xiàn)，但是循環(huán)里面有分支，可能會造成控制冒險，所以我們需要盡可能的循環(huán)展開，讓一個循環(huán)里面執(zhí)行更多的數(shù)據(jù)無關(guān)的指令，但是這個數(shù)量會被處理器的寄存器數(shù)量限制。

下面是 MegPeak 測試 Arm64 上 fmla 指令計算峰值時候的核心 Code。

static int fmla_throughput() {
  asm volatile(
      "eor v0.16b, v0.16b, v0.16b\n"
      "eor v1.16b, v1.16b, v1.16b\n"
       ...
      "eor v19.16b, v19.16b, v19.16b\n"
      "mov x0, #0\n"
      "1:\n"
      "fmla v0.4s, v0.4s, v0.4s\n"
      "fmla v1.4s, v1.4s, v1.4s\n"
       ...
      "fmla v19.4s, v19.4s, v19.4s\n"
      "add x0, x0, #1 \n"
      "cmp x0, %x[RUNS] \n"
      "blt 1b \n"
       :
       : [RUNS] "r"(megpeak::RUNS)
       : "cc", "v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7", "v8", "v9", "v10", "v11", "v12", "v13",
        "v14", "v15", "v16", "v17", "v18", "v19", "x0");
  return megpeak::RUNS * 20;
}

上面的內(nèi)嵌匯編代碼中，主要做了幾件事情：

• 初始化 0–19 號 neon 寄存器為零，這一步不是必須的，但可以避免計算過程中出現(xiàn) nan 導(dǎo)致的潛在影響。
• 創(chuàng)建主循環(huán)，主循環(huán)中每條指令執(zhí)行，從對應(yīng)的寄存器讀取數(shù)據(jù)，并執(zhí)行 fmla 指令，將計算結(jié)果寫到相同的寄存器中，同一條指令內(nèi)部沒有數(shù)據(jù)相關(guān)。

這里有一個問題需要解釋，為什么選擇 20 個寄存器：

• 如果寄存器選擇太少，上一次循環(huán)可能還沒有計算完成，下一次循環(huán)讀取相同的寄存器，可能造成數(shù)據(jù)相關(guān)，因此循環(huán)里面執(zhí)行的指令條數(shù)需要大于指令延遲和處理器單個周期內(nèi)能夠執(zhí)行的指令數(shù)的乘積，但是我們不知道這條指令延遲，但是可以估計，除了特殊的指令，延遲一般不超過 10 個時鐘周期。
• Arm64 有 32 個 neon 寄存器，為什么不選擇 32 個寄存器，因為 20 個寄存器已經(jīng)可以避免數(shù)據(jù)和控制相關(guān)了，測試發(fā)現(xiàn)使用更多的寄存器影響很小。

執(zhí)行上面的代碼，可以統(tǒng)計執(zhí)行的時間，加上可以提前通過指令的數(shù)目以及循環(huán)的次數(shù)計算出真正的計算量，因此便可以計算出指令的計算峰值。

測試指令延遲

為了測量處理器上一條指令的執(zhí)行延遲，我們需要寫出重復(fù)執(zhí)行這條指令，并讓這些指令之間存在嚴格的數(shù)據(jù)冒險，盡量排除其他冒險。

• 制造數(shù)據(jù)冒險 ---- 讓前后兩條指令之間的數(shù)據(jù)存在真正的數(shù)據(jù)依賴（RAW），即上一條指令的輸出為下一條指令的輸入；
• 盡可能的消除控制冒險 ---- 同上。

下面是 MegPeak 測試 Arm64 上 fmla 指令延遲的核心 Code。

static int fmla_latency() {
  asm volatile(
      "eor v0.16b, v0.16b, v0.16b\n"
      "mov x0, #0\n"
      "1:\n"
      "fmla v0.4s, v0.4s, v0.4s\n"
      //重復(fù) 20 次
     ...
      "fmla v0.4s, v0.4s, v0.4s\n"
      "add x0, x0, #1 \n"
      "cmp x0, %x[RUNS] \n"
      "blt 1b \n"
     :
     : [RUNS] "r"(megpeak::RUNS)
     : "cc", "v0", "x0"
 );
  return megpeak::RUNS * 20;
}

上面的內(nèi)嵌匯編代碼中，主要將

fmla v0.4s, v0.4s, v0.4s\n

這條指令重復(fù)了 20 次，這樣每條指令都依賴上一條指令的計算結(jié)果，所以存在嚴格的數(shù)據(jù)相關(guān)。

執(zhí)行代碼，統(tǒng)計執(zhí)行時間，通過執(zhí)行的指令條數(shù)，可以計算出這條指令最終的延遲。

上面的代碼在 MegPeak 中實現(xiàn)，不是這么直接，而是通過宏來實現(xiàn) code 的生成。

用 MegPeak 測到的數(shù)據(jù)，可以用來干什么

MegPeak 可以測試出處理器的內(nèi)存帶寬，指令的理論計算峰值，指令的延遲等信息，因此可以幫助我們：

• 繪制 Roofline Model 指導(dǎo)我們優(yōu)化模型性能
• 評估程序的優(yōu)化空間
• 探索指令組合的理論計算峰值

另外 MegPeak 還可以提供對理論的驗證，如我們通過處理器頻率 單核單周期指令發(fā)射數(shù)量 每條指令執(zhí)行的計算量可以計算出理論計算峰值，然后我們可以通過 MegPeak 進行實際測量進行驗證。

繪制指令相關(guān)的 Roofline Model

Roofline 模型被大量的使用在高性能計算中，是評估算法的可優(yōu)化程度和優(yōu)化方向的重要工具。使用 MegPeak 可以繪制出更加具體的關(guān)于指令對應(yīng)的 Roofline 模型，如：在 CPU 中，不同的數(shù)據(jù)類型，雖然訪存帶寬不會改變，但是計算峰值差距比較大，比如在 arm 上 float 的計算峰值和 int8 的計算峰值差距很大。

評估代碼優(yōu)化空間

在優(yōu)化具體算法的時候，可以通過 MegPeak 測試出 kernel 里面的主要指令的最大峰值，如在 Arm 上優(yōu)化 fp32 Matmul 的時候，主要用到的指令是 fmla 指令，這時候可以測試程序?qū)嶋H運行的峰值，如果指令的峰值和程序的峰值差距越小，說明代碼優(yōu)化得越好。

另外，可以根據(jù)算法實現(xiàn)計算出計算量和訪存量，并使用 MegPeak 繪制出上面的 Roofline，通過計算實際的計算密度，然后再對應(yīng)到 Roofline 中，如果計算密度落在上圖中的綠色區(qū)域，說明程序需要更多考慮優(yōu)化訪存，提供更優(yōu)的訪存模型，如分塊，提前 pack 數(shù)據(jù)等。如果計算強度的點落在灰色區(qū)域說明，代碼已經(jīng)最優(yōu)了，如果還想進一步提速，只能考慮從算法角度進行優(yōu)化了，如：在卷積中使用 FFT，Winograd 等算法進行優(yōu)化。

探索最優(yōu)指令組合

很多 Kernel 的優(yōu)化不是單純的某一條指令就可以衡量，可能需要多條指令的組合才能代表整個 Kernel 的計算，因此我們需要探索如何組織這些指令使其達到處理器最優(yōu)的性能。下面列舉在 A53 小核優(yōu)化 fp32 Matmul 的過程中，由于 Matmul 是計算密集型算子，考慮通過多發(fā)射隱藏訪存指令的開銷，使用 MegPeak 配合進行分析，探索如何組合指令實現(xiàn)盡可能多地多發(fā)射。

因為小核上面資源有限，指令多發(fā)射有很多限制：

• 首先使用 MegPeak 出測試 A53 上 fp32 的 fmla 指令的計算峰值，將其定義為 100% 峰值計算性能
• 測試哪些指令組合可以支持雙發(fā)射

• 在 MegPeak 中添加 vector load 和 fmla 1:1 組合的代碼，然后測試其峰值僅僅為 float 峰值的 36%，表明 Vector load 和 fmla 不能雙發(fā)射
• 同樣可以測得通用寄存器 load 指令 ldr+fmla 的組合可以達到 float 峰值的 93%，說明 ldr 可以和 fmla 雙發(fā)射
• 同上可以測得 ins + fmla 能雙發(fā)射，ins + vector load 64 位 可以雙發(fā)射

• 根據(jù) Matmul 最內(nèi)層 Kernel 的 計算原理，如最內(nèi)層 Kernel 的分塊大小是 8x12，那最內(nèi)層需要讀?。?0 個 float 數(shù)據(jù)，計算 24 次 fmla 計算
• 結(jié)合上面的 MegPeak 測試的信息，我們需要找到用最少時鐘完成這：20 個 float 數(shù)據(jù) load，和 24 次 fmla 數(shù)據(jù)計算的指令組合，因此需要將盡可能多的數(shù)據(jù) load 和 fmla 進行雙發(fā)射，隱藏數(shù)據(jù) load 的耗時
• 最后的指令組合是：

• 使用 vector load 64 指令 + ldr + ins 組合成為一個 neon 寄存器數(shù)據(jù)，因為 ldr 和 ins 都可以和 fmla 雙發(fā)射，把他們和 fmla 放在一起可以隱藏他們的耗時
• 在這 3 條指令中穿插 fmla 指令，并盡可能解決數(shù)據(jù)依賴

根據(jù)上面的指令組合可以使得 Matmul 在小核上達到計算峰值的 70% 左右。

總結(jié)

MegPeak 作為一個進行高性能計算的輔助工具，能夠使得開發(fā)人員輕松獲得目標處理器的內(nèi)在的詳細信息，輔助進行對代碼的性能評估，以及優(yōu)化方法設(shè)計。但是 MegPeak 也有一些需要豐富的方向：

• 支持獲取更多的處理器性能數(shù)據(jù)，如：L1，L2 cache 的大小，自動探索各種指令組合的雙發(fā)射情況，并大概繪制出一個處理器后端的縮略圖。如：en.wikichip.org/w/image
• 支持測量移動端 OpenCL 的更多細節(jié)信息，如：warp size，local memory 大小等。

如果有同學(xué)對上面的功能感興趣，可以到 GitHub 上提交代碼，或嘗試使用 MegPeak。