作者：曠視 MegEngine 架構(gòu)師 張孝斌

快速了解 mperf

在移動(dòng)/嵌入式平臺(tái)，為了最大程度發(fā)揮硬件算力，對(duì)算子極致性能的追求變成必然，不同于桌面/服務(wù)器平臺(tái)，移動(dòng)/嵌入式平臺(tái)在算子性能調(diào)優(yōu)方面可選擇的工具很少。

MegEngine 團(tuán)隊(duì)一直在探索什么樣的工具能夠在算子調(diào)優(yōu)流程中帶來助益，來幫助達(dá)成如下的算子性能調(diào)優(yōu)反饋回路，這也是 mperf 誕生的背景。

mperf 是一個(gè)微架構(gòu)層次的算子性能調(diào)優(yōu)工具箱，主要面向移動(dòng)/嵌入式平臺(tái)的 CPU/GPU 核心，目標(biāo)是“為構(gòu)建一個(gè)更接近閉環(huán)的算子調(diào)優(yōu)反饋回路”提供系列基礎(chǔ)工具。

核心功能：

• [基礎(chǔ)能力] 測(cè)試微架構(gòu)層次的各類常用性能分析參數(shù)（GFLOPS/Multi-level Bandwidth/Latency...）

• [基礎(chǔ)能力] 提供 PMU（Performance Monitoring Unit） 數(shù)據(jù)獲取能力

• [性能分析] 繪制 Hierarchical Roofline

• [問題定位] 加工 PMU 數(shù)據(jù)得到各種指標(biāo)（如 IPC, Instructions per cycle）、TMA（Top-Down Microarchitecture Analysis Method）（https://www.intel.com/content/www/us/en/develop/documentation/vtune-cookbook/top/methodologies/top-down-microarchitecture-analysis-method.html#top-down-microarchitecture-analysis-method_GUID-FA8F07A1-3590-4A91-864D-CE96456F84D7）分析能力，可以作為部分 vendor 提供的 GUI 分析工具的平替

• [優(yōu)化指引] 提供 OpenCL Linter 方案（后續(xù)版本提供）

• ...

作為一個(gè) C++ API 級(jí)別的工程，mperf 外部依賴少，可以簡(jiǎn)單方便（侵入式）集成到目標(biāo)工程中，目前已經(jīng)開源到 GitHub（https://github.com/MegEngine/mperf），歡迎大家試用交流。

使用方法參考?README 文檔（https://github.com/MegEngine/mperf#readme）；快速上手指南見?Tutorial 文檔（https://github.com/MegEngine/mperf/blob/master/doc/how_to_optimize_matmul/%E5%80%9F%E5%8A%A9mperf%E8%BF%9B%E8%A1%8C%E7%9F%A9%E9%98%B5%E4%B9%98%E6%B3%95%E6%9E%81%E8%87%B4%E4%BC%98%E5%8C%96.md）

對(duì) mperf 的實(shí)現(xiàn)原理感興趣的同學(xué)，可以繼續(xù)往下看~~

展開說說 mperf 的工程實(shí)現(xiàn)

緣起

算子調(diào)優(yōu)目前還是一個(gè)難以閉環(huán)的工作，需要開發(fā)者對(duì)目標(biāo)硬件架構(gòu)特性、算子優(yōu)化水平評(píng)估、性能瓶頸定位、豐富的優(yōu)化技巧等都有很深的了解之后才能變得游刃有余。同時(shí)隨著 CPU/GPU 架構(gòu)越來越多，越來越復(fù)雜，普通的開發(fā)者很少有精力去深入理解各個(gè)架構(gòu)的特性，問題變得更加棘手。

理想中的調(diào)優(yōu)過程是能夠形成如上圖所示的閉環(huán)，甚至可以走向編譯器全自動(dòng)化調(diào)優(yōu)方案，過程中往往需要依賴工具完成，在桌面/服務(wù)器平臺(tái)的工具較為完備，如 linux perf,?lmbench/stream，NVIDIA?NSight Compute，Intel?vtune/Advisor/pmu-tools?等開閉源工具等都提供了一部分能力，通過人為組合還是能得到比較全的能力；與此同時(shí)，在移動(dòng)/嵌入式平臺(tái)，也有?simpleperf、Arm mali streamline、snapdragon profiler、MegPeak、ArchProbe、HWCPipe?等優(yōu)秀的開閉源工具，但是完備性和易用性方面都存在很多問題：

• GUI 工具不支持函數(shù)級(jí)/代碼片段分析(如基于 PMU 的指標(biāo)分析等，詳見下方“PMU 數(shù)據(jù)搜集、加工和分析”)，還不容易擴(kuò)展新的分析指標(biāo)

• 不支持 ARM CPU 的 TMA 分析(詳見下方“PMU 數(shù)據(jù)搜集、加工和分析”)

• 繪制 Roofline 等所依賴的基礎(chǔ)數(shù)據(jù)的獲取能力散落在多個(gè)工具中，普通同學(xué)很難入手

• 很少的優(yōu)化指導(dǎo)能力

因此我們啟動(dòng)了 mperf 項(xiàng)目，希望提供系列工具來完整獲得這些基礎(chǔ)能力：

• 常見 CPU/GPU 微架構(gòu)參數(shù)，目前已經(jīng)支持 ARM CPU/Mali GPU/ Adreno GPU 的部分型號(hào)

• 通過 Hierarchical Roofline 模型評(píng)估算子優(yōu)化水平

• 通過豐富的指標(biāo)和 TMA 分析模型來定位性能瓶頸/提示性能問題

• 通過 OpenCL Linter 等工具能固化專家優(yōu)化經(jīng)驗(yàn)，掃描用戶代碼后給出性能優(yōu)化建議

• ...

常見 CPU/GPU 微架構(gòu)參數(shù)

為 Roofline 繪制/Metrics (指標(biāo))計(jì)算等模塊提供架構(gòu)相關(guān)的基礎(chǔ)參數(shù)，如多級(jí)存儲(chǔ) bandwidth/latency，指令 throughput/latency，各種基礎(chǔ) micro-kernel的bandwidth，GPU 特有的參數(shù)(warp size 等)等，這部分是常規(guī)功能，測(cè)試原理很多都參考了 MegPeak/lmbench/ArchProbe 等工程的實(shí)現(xiàn)，此處不再展開，僅舉一個(gè)小例子方便大家看到它的價(jià)值。

例1. 在移動(dòng)端 GPU 上在做向量計(jì)算的時(shí)候，我們會(huì)關(guān)心 int8:int16:int32 算力是否一定存在 4:2:1 的關(guān)系？mperf 實(shí)測(cè)數(shù)據(jù)顯示在 Adreno A640 呈現(xiàn)難以解釋的 int16>int8>int32，在 Mali G78 上則滿足比例關(guān)系，實(shí)測(cè)的詳實(shí)數(shù)據(jù)會(huì)告知開發(fā)者 float->int16 定點(diǎn)化是否能帶來性能收益。

Hierarchical Roofline 繪制

原生 Roofline Model 建模了“算子計(jì)算模式、目標(biāo)硬件架構(gòu)、性能”三者之間的關(guān)系，可以為算子調(diào)優(yōu)提供大方向的指引，比如：

• 確認(rèn)瓶頸：位于 Machine Balance Point 左側(cè)是訪存 bound，右側(cè)是計(jì)算 bound

• 指導(dǎo)優(yōu)化方向： 如果是訪存 bound，可以考慮結(jié)合各種已知的專家經(jīng)驗(yàn)如 tiling/prefetch/aligned allocator 等進(jìn)行優(yōu)化嘗試，也就是知道了努力的方向

• 提示停止優(yōu)化的時(shí)機(jī)：如果是計(jì)算 bound 且已經(jīng)接近屋頂（峰值性能上限），可以考慮停止優(yōu)化

• 預(yù)測(cè)性能：如果已知架構(gòu)峰值性能數(shù)據(jù)、算子本身的計(jì)算訪存比、計(jì)算規(guī)模這三個(gè)數(shù)據(jù)就能算估算出執(zhí)行時(shí)間

但因?yàn)樵?Roofline Model 存在一些問題：

• 未區(qū)分多級(jí)存儲(chǔ)的情況，一般只考慮 DRAM Bandwidth，如果輸入 Tensor 小到可以塞入 L1 Cache，采用 L1 Cache Bandwidth 更加準(zhǔn)確

• 未區(qū)分執(zhí)行環(huán)境的復(fù)雜性，比如是否啟動(dòng)多線程，處于 Turbo Mode 等，這些都影響實(shí)際理論峰值

• 未區(qū)分指令類型（instruction mixes），一般默認(rèn)采用單一指令如 FMA 進(jìn)行測(cè)試，實(shí)際理論峰值可以是不同指令性能的加權(quán)求和

• 未區(qū)分 read/write/access，比如 sum(Tensor)，采用 read Bandwidth 更加準(zhǔn)確

之后發(fā)展出了 Hierarchical Roofline，實(shí)際中為了方便繪制，mperf 提供了不同的手段來獲取上述基礎(chǔ)數(shù)據(jù)。

繪制Roofline需要兩組數(shù)據(jù)：

• 架構(gòu)理論峰值性能（GFLOPS）和帶寬（Bandwidth）

• 理論峰值性能：?jiǎn)沃噶顪y(cè)試原理參考此文（https://zhuanlan.zhihu.com/p/522007924）；分析不同指令占比的方案還在驗(yàn)證中；

• 理論帶寬： 提供的方案可以測(cè)試多級(jí)存儲(chǔ)帶寬，并提供各種基礎(chǔ) micro-kernel （如純 read 函數(shù)）來測(cè)試貼近實(shí)際訪存模式的帶寬上限

• 算子實(shí)測(cè)性能/帶寬: 通過 PMU 的方式獲取

PMU 數(shù)據(jù)搜集、加工和分析

PMU 數(shù)據(jù)搜集

CPU/GPU 架構(gòu)大多都包含 PMU 硬件，用于計(jì)數(shù)一些底層硬件事件，如 CPU Core 所屬的執(zhí)行指令數(shù)和時(shí)鐘周期，Cache 所屬的 L1 Cache Miss 等；mperf 提供了 CPU/GPU 的 PMU 數(shù)據(jù)獲取能力，特別是 Adreno GPU 這種缺乏官方開源支持的平臺(tái)。

加工指標(biāo)（又名 Metrics）

以 ARM A55 Core 為例，有超過 100 種硬件事件，Adreno A6xx 系列 GPU 則有約 125 種硬件事件，這些事件的數(shù)值可以用來加工計(jì)算各種指標(biāo)，如 IPC=INST_RETIRED 計(jì)數(shù)（指令數(shù)）/ CPU_CYCLES 計(jì)數(shù)（Cycle 數(shù)），也可以用來計(jì)算 DRAM Bandwidth、算子 GFLOPS、L1 MISS Ratio 等等，具體的指標(biāo)支持列表及其計(jì)算方式可閱讀文檔及源碼。

TMA 分析

TMA 是一套自頂向下的 Intel CPU 算子性能瓶頸分析方法，這套思想可以擴(kuò)展到其它架構(gòu)。上圖描述了 A76 Core 指令的生命周期，過程中涉及到的硬件資源（如可執(zhí)行 FMA 的端口數(shù)量）都可能成為指令執(zhí)行過程中的瓶頸，TMA 用于分析瓶頸所在，從而指引優(yōu)化方向，詳細(xì)思想大家可以閱讀官方文檔。（https://www.intel.com/content/www/us/en/develop/documentation/vtune-cookbook/top/methodologies/top-down-microarchitecture-analysis-method.html#top-down-microarchitecture-analysis-method_GUID-FA8F07A1-3590-4A91-864D-CE96456F84D7）

mperf 計(jì)算得到的所有指標(biāo)中一部分可以歸類進(jìn) TMA 范式，另一部分作為單獨(dú)的指標(biāo)存在用于輔助性能分析。不管是 TMA 還是獨(dú)立指標(biāo)都可以提供細(xì)粒度的優(yōu)化方向指引。

在 mperf 里面我們將 TMA 擴(kuò)展到了 ARM CPU 上，過程中我們得到了一些經(jīng)驗(yàn)：

• 因?yàn)?ARM CPU 提供的硬件事件的類別/定義與 Intel CPU 有很多差異，完美復(fù)刻 TMA 各類別的定義很困難也不現(xiàn)實(shí)，但是 ARM CPU 本身提供的硬件事件的類別也很豐富，可以摸索和總結(jié)出適合自身的 TMA 方案和獨(dú)立指標(biāo)，實(shí)踐中我們證明了這條路行的通。

• ARM 不同系列 CPU 微架構(gòu)之間有明顯差異，比如 A55（in-order）與 A76（out-of-order）在 TMA 各類別/定義上有很多不同，每個(gè)架構(gòu)都需要單獨(dú)處理。

• 由于 vendor 相關(guān)資料開放程度不同，部分指標(biāo)的定義可能會(huì)在長(zhǎng)期實(shí)踐驗(yàn)證中被修正。

本模塊 GPU 部分的長(zhǎng)期目標(biāo)是成長(zhǎng)為移動(dòng)端 GPU 類似 NVIDIA Nsight Compute 的等價(jià)物。目前已經(jīng)總結(jié)了很多有優(yōu)化指導(dǎo)意義的 GPU 指標(biāo)，但 TMA 在 GPU 上可行性和必要性我們還在探索中。在通用計(jì)算相關(guān)指標(biāo)方面(不涉及渲染相關(guān))，目前已經(jīng)具備替代 ARM 官方 GUI 工具 streamline 和高通官方 GUI 工具 snapdragon profiler 的能力，使用這兩個(gè) GUI 工具的同學(xué)可以嘗試替換為 mperf，一方面 API 級(jí)別更加靈活，另一方面可以享受到不斷增補(bǔ)指標(biāo)（Metrics）帶來的好處。

這里同樣舉一個(gè)實(shí)際例子來展示 mperf 的工作邏輯：

例2：GPU 支持不同向量寬度的浮點(diǎn)數(shù)據(jù)加載，如 vload4/8/16 等等，不同的架構(gòu)有不同的限制，并不是向量寬度越寬越好，我們觀察到 Mali G78 GPU 上 vload4 比 vload16 快很多，在 mperf 中的分析邏輯如下：

首先搜集一系列 event 的數(shù)值（下圖 3 展示了其中一部分），如 ExternalMemoryReadBytes 含義是 DDR→Unified L2 Cache 的 read 數(shù)據(jù)量，可以看出 vload16 相對(duì) vload4 增加了 4 倍還多， LoadStoreReadFull（LS_MEM_READ_FULL) 含義是 full-width read 的次數(shù)，LoadStorePartial（LS_MEM_READ_SHORT）代表了 partial-width read 的次數(shù)，發(fā)現(xiàn)在 vload16 的時(shí)候 partial-width read 的次數(shù)增大了很多，額外發(fā)射了更多的 read 指令，解釋了速度變慢的原因。為了方便快速發(fā)現(xiàn)此類問題，mperf 也專門整理了一個(gè) PartialReadRatio 的指標(biāo)，其計(jì)算公式見下方。

更多關(guān)于 PMU 數(shù)據(jù)搜集、加工和分析的細(xì)節(jié)，歡迎大家閱讀源碼。

OpenCL Linter

MegEngine 團(tuán)隊(duì)在做 OpenCL 算子開發(fā)的過程中積累了一系列優(yōu)化經(jīng)驗(yàn)，希望能通過工具化的方式將這部分經(jīng)驗(yàn)固化下來。

目前初步計(jì)劃參考 Linter 思路，大體有兩個(gè)部分：

• 靜態(tài)代碼分析掃描 OpenCL Kernel，檢查規(guī)則是預(yù)置的 OpenCL 專家優(yōu)化經(jīng)驗(yàn)，如使用 select 指令而非三目運(yùn)算符，對(duì)齊檢查等，給出優(yōu)化建議。

• 在動(dòng)態(tài)執(zhí)行過程中監(jiān)測(cè)各種預(yù)置的指標(biāo)，結(jié)合專家經(jīng)驗(yàn)對(duì)一些異常數(shù)據(jù)給出提示，如寄存器使用量分析等，引導(dǎo)用戶調(diào)優(yōu)。

這部分工作目前正在做 POC 驗(yàn)證，敬請(qǐng)期待。

總結(jié)

mperf 為移動(dòng)/嵌入式平臺(tái)性能調(diào)優(yōu)提供了系列工具，其中在 PMU 獲取/ARM TMA/分層 Roofline 繪制/OpenCL Linter 等方面都有不同程度的創(chuàng)新，希望這個(gè)工具箱能為開發(fā)人員提供更多的分析手段和調(diào)優(yōu)建議。

當(dāng)前階段 mperf 開發(fā)方向會(huì)以優(yōu)先豐富基礎(chǔ)工具為主，部分工具暫時(shí)還需要一些體系結(jié)構(gòu)的知識(shí)才能用好，更長(zhǎng)遠(yuǎn)來看，我們會(huì)做更多的工作來降低使用門檻，朝著更易用更自動(dòng)化的方向努力。與此同時(shí)，大家都希望有一套閉環(huán)的方法論來告訴我們算子調(diào)優(yōu)的時(shí)候每一步先分析什么指標(biāo)，然后建議嘗試 N 種優(yōu)化方法，不斷迭代到最優(yōu)，但是目前業(yè)內(nèi)距離這個(gè)愿景還有點(diǎn)遠(yuǎn)，mperf 也是如此，它的主要能力此刻還停留在為開發(fā)者提供更多決策信息的階段。

為了能更近一步，下一階段我們會(huì)先從積累豐富的實(shí)操案例入手，和 mperf 的使用者一起探索在不同的案例下什么樣的指標(biāo)能發(fā)現(xiàn)問題，什么樣的優(yōu)化方法可以嘗試；之后在發(fā)現(xiàn)特定指標(biāo)異常的時(shí)候可以將積累的優(yōu)化方法展示給用戶。因此，mperf 是一個(gè)具有成長(zhǎng)性的工程，歡迎大家一起參與共建，聚沙成塔，打造好用的調(diào)優(yōu)工具！

mperf 開發(fā)過程中受到了上面提到的各種優(yōu)秀開源工程的啟發(fā)和指引，方法論上參考了大量包括 Intel/ARM 官方文檔在內(nèi)的諸多資料，在此一并致謝！

附：

更多 MegEngine 信息獲取，您可以：

查看文檔：

https://www.megengine.org.cn/doc/stable/zh/

和 GitHub 項(xiàng)目：

https://github.com/MegEngine，或加入 MegEngine 用戶交流 QQ 群：1029741705。歡迎參與 MegEngine 社區(qū)貢獻(xiàn)，

成為 Awesome MegEngineer：

https://www.megengine.org.cn/community-AMGE，榮譽(yù)證書、定制禮品享不停。