面對越來越多的 DNN 專用處理器設計（晶片和 IP），我們很自然的需要解決一個問題「怎樣對不同的 DNN 處理器設計做出公平的比較和評價？」能不能像手機跑分一樣也讓它們跑個分呢？這實際是個基準測試（Benchmarking）問題。正好最近看到兩個在這方面的嘗試，一個是 MIT Eyeriss 團隊給出的 DNN Processor Benchmarking Metrics；另一個是百度 DeepBench 專案的更新。我們可以結合這兩個專案討論一下如何給 DNN 處理器「跑分」。
一
首先，我們還是簡單回顧一下 Benchmark 的背景知識。以下是 Wikipedia 對 Benchmark (computing) 的定義：
In computing, a benchmark is the act of running a computer program, a set of programs, or other operations, in order to assess the relative performance of an object, normally by running a number of standard tests and trials against it.The term 'benchmark' is also mostly utilized for the purposes of elaborately designed benchmarking programs themselves.
實際上，我們非常熟悉的手機跑分也是 Benchmark 的一種。Benchmark 通常用於評估計算機硬體的效能特徵, 例如 CPU 的浮點運算效能,GPU 的影像處理能力，儲存系統訪問的速度等等，有時也用於軟體或者編譯工具。總的來說，Benchmark 提供了一種比較不同軟硬體系統效能的方法。從另一個角度來說，Benchmark 也可以在我們自己的設計過程中幫助我們評價不同版本優化改進的情況，這可以看作是一種縱向比較。
在我們研發的過程中，會用到各種各樣的測試程式。Benchmark 本質上也是測試程式，它的特殊性體現在：大家公認它可以評價（一般是定量的）被測試目標的某些特性。如果不是公認的基準測試，也就談不上橫向比較的作用了。
專用的 DNN Processor（或者 DNN/DL/ML Processor/Accelerator）的研究和應用還是最近幾年的事情，目前還沒有大家公認的基準測試方法和指標。一個原因是，專用硬體針對特定應用（範圍比較窄），一般也進行了特殊的優化，設計能夠相互比較的基準測試比較困難。但是，由於 AI/Deep Learning 的快速發展和廣闊前景，目前很多研究機構和公司都投入到專用的 DNN 處理器的研發當中，對比和競爭在所難免。而技術正是在對比和競爭中不斷髮展的，DNN 處理器的基準測試已經越來越得到大家的關注。
二
MIT 的 Eyeriss 團隊無疑是 DNN Processor 界一股重要的力量。他們最近搞了一個「Tutorial on Hardware Architectures for Deep Neural Networks」[1]，非常全面，建議同學們好好看看。這個 Tutorial 中有一部分就是「Benchmarking Metrics」（基準測試指標）。
通常，我們說 Benchmarking 的時候一般包括兩部分內容，一是測試程式（包括測試方法），即 Benchmark 本身；二是結果的表達（或者評價指標），即 Metrics。例如，經典的 Benchmark：Dhrystone，它的測試方法就是在目標處理器上執行一段精心設計的 C 程式：「simple programs that are carefully designed to statistically mimic the processor usage of some common set of programs」。執行這段程式實際會得到很多資訊，而它採用的 Dhrystone score 的表達為「 the number of Dhrystones per second (the number of iterations of the main code loop per second)」。這裡為什麼不用 MIPS (每秒能執行多少百萬條指令) 這種更常見表達呢？這是因為，對於 RISC 和 CISC 這兩種不同的指令架構，在 task 層面統計結果要比在指令層面更為公平合理。此外，還可以用 DMIPS (Dhrystone MIPS) 作為指標，即 Dhrystone 成績除以 1757（這是當年在 VAX 11/780 機器上獲得的每秒 Dhrystones 的數量，名義上作為 1 MIPS）；或者使用 DMIPS/MHz，這樣可以方便對比執行在不同時脈頻率上的處理器。從 Dhrystone 的例子可以看出，對於一個成功的 Benchmark 來說，合理有效的測試程式和 Metrics 都是非常重要的。
我們回到 Eyeriss 的方案。應該說他們最主要的貢獻在於 Metrics。他們並沒有專門設計「測試程式」，而是直接使用「widely used state-of-the-art DNNs (e.g. AlexNet, VGG, GoogLeNet, ResNet) with input from well known datasets such as ImageNet」。採用「經典」的 DNN 網路作為 Benchmark 相當於用目標應用來作為測試程式，雖然比較直接，但也有很多問題。我們在本文「下篇」分析百度的 DeepBench 的時候再做詳細討論。
Eyeriss 團隊提出兩個層次的 Metrics。第一個是 Metrics for DNN Algorithm，主要是演算法層面的指標。我們重點看第二個，Metrics for DNN Hardware：
Measure energy and off-chip (e.g., DRAM) access relative to number of non-zero MACs and bit-width of MACs
- Account for impact of sparsity in weights and activations
- Normalize DRAM access based on operand size
- To compute the off-chip access, assume the DNN processor is a stand-alone chip. The off-chip access should account for all accesses needed to complete all the layers listed including initial inputs and final outputs from an off-chip device (e.g., DRAM). The goal is to compare the off-chip access at steady state, so accesses during ramp-up/ramp do not need to be included (e.g. loading configuration parameters, or loading weights if all weights can be stored on chip).
Energy Efficiency of Design
- pJ/non-zero MAC
External Memory Bandwidth
- Off-chip access (in Bytes)/non-zero MAC
Area Efficiency
- Total chip mm2/multiplier and storage capacity/multiplier
- Accounts for on-chip memory
這裡列出的一些指標是非常有針對性的。它們和傳統的指標，比如 Run Time，Power，相結合，希望能夠覆蓋：Accuracy，Power，Throughput，Cost 這些硬體相關的基本要素，並能夠提供 External memory bandwidth，Required on-chip storage，Utilization of cores 這些重要資訊。可以看出，很多指標都非常強調效率，Efficiency，特別是對於面積和功耗這些和成本相關的指標。另外，在對 DNN 處理器的核心 MAC 做相關測試時，強調了 non-zero MAC（和稀疏性相關）以及 bit-width of MAC（和精度相關）這兩個條件，反映了 DNN 的特點。
三
說到這裡，順便提一下我剛看到的另一個指標，來自 Intel/Nervana 的 Naveen Rao 在「O'Reilly Artificial Intelligence Conference 2017」上的一個講演。也可參考 [3]
他提出了 Computational Capacity 的概念，涉及的 3 個變數是：1）bit width of numeric representation；2）memory bandwidth；3）OPs/s。其中：b=# bits of representation，m=memory bandwidth in GigaBits/s，o=TeraOPs/s，分母是 10 的 6 次方。這裡使用精度位元數的平方作為一個簡單的表達方式，在指標中考慮實現這個精度的乘法器的相對面積。即，在實際晶片中，16 bit 乘法器的面積大約是 8 bit 乘法器的 4 倍。這個概念的提出，是因為常用的 FLOPS 指標已經不能準確的評價處理器的 DNN 處理能力了，而綜合上述三個因素才是更合理的表示方法。這個指標和上述 Eyeriss 提出的多個指標有一定的類似之處，它的好處是比較簡潔，可以用一個公式來表示，但它包含的資訊也要少一些。
另外一個很有用的指標（或者叫效能評價模型）是 Roofline Model[4]。通過這個 model，既可以評估一個設計的效率，還能很容易看出你的設計倒底是 computation-limited 還是 memory bandwidth-limited，可以幫助你確定進一步優化的思路.
比如 Google 在 TPU 的論文裡採用這 Roofline Model 來和 GPU，CPU 進行了對比，如下圖。
Roofline model 很好的說明了，一個好的評價模型，可以很直觀的給我們展示出最重要的資訊。它的玩法很多，用好了也很有幫助，建議大家好好看看。
四
再回到正題，下面是對 Eyeriss 處理器為例進行 Benchmarking 的結果。首先是處理器的 spec 和晶片整體的測試結果。這些需要指出的是，處理器的 Spec 在進行對比的時候也是很有必要的，是很多對比評價的基礎資訊。
然後是對 Alexnet 各個 layer 分解的測試結果。
最後還給出了用來評價 FPGA 的指標。
由於我們關注的是 Benchmarking 的指標設計，這裡就不具體分析測試結果了。Eyeriss 團隊還設立了一個網站（http://www.rle.mit.edu/eems/dnn-benchmarking-form-2/），供大家提交自己的測試結果。在這個網站上可以下載相應的表格，也可以看到 Eyeriss 處理器的例項。
總的來說，由於 DNN 處理器的特殊性，比如對 memory bandwidth 的需求、DNN 稀疏性的特點、MAC 利用率問題等等，對於它做基準測試的時候很難簡單的借用傳統處理器的評價指標。我們需要綜合性的或更有針對性的指標才能更好的表徵 DNN 處理器的實際效能。Eyeriss 團隊提出一系列比較有針對性的指標，基本上能夠覆蓋了 DNN 處理器的各方面效能。不過這些指標能否以更簡潔直觀的形式表達，也是值得我們思考的問題。
五
Eyeriss 團隊總結的 Benchmarking Metrics，對於評價 DNN 處理器，甚至設計 DNN 處理器都很有啟發。但是，他們使用幾種 DCNN 網路（AlexNet，VGG16，GoogleNet，ResNet-50）作為 Benchmark 的方法是否合有效理呢？
首先，一個實際的問題是，要得到所有這幾個網路在目標硬體上執行的資料，是一項巨大的工程，特別是對於小規模的研究團隊來說。我們看到即使是 Eyeriss 處理器也只給出了 AlexNet 和 VGG16 的結果。實際上，這幾種 DCNN 網路還是有不少相似之處的，用它們作為 Benchmark，是否是做了很多重複和冗餘的測試？
第二個問題是，這幾種網路是否真正覆蓋了各種 DNN 的需求。雖然 Eyress 更關注卷積層的處理，但 FC/RNN/LSTM/GRU 這類網路的應用也很廣泛，在很多新出現非常有效的模型中，FC/RNN 型別的層和卷積層經常是結合在一起使用的。對於這種情況，只用這幾種以 CNN 為主的網路作為 Benchmark 是否有足夠的代表性呢？如果還是採取把實際網路用作 Benchmark 的思路，我們就需要不斷的擴大這個 Benchmark 的集合。顯然這也是不可取的。
解決上述問題的一個思路就是「設計」新的 Benchmark，就像 Dhrystone 這樣的「Synthetic Benchmark」一樣。下面我們就結合 Baidu 的 DeepBench 討論一下「Synthetic Benchmark」的設計問題。
六
DeepBench 專案 [5] 在百度眾多的開源專案中受到的關注相對較少，不過他們對於 Deep Learning 硬體 Benchmarking 的討論和實踐，既是非常有意義的嘗試，也是我們討論 Benchmarking 問題的很好的參考。我們首先看看他們對專案目標的描述：
「The primary purpose of DeepBench is to benchmark operations that are important to deep learning on different hardware platforms. Although the fundamental computations behind deep learning are well understood, the way they are used in practice can be surprisingly diverse. For example, a matrix multiplication may be compute-bound, bandwidth-bound, or occupancy-bound, based on the size of the matrices being multiplied and the kernel implementation. Because every deep learning model uses these operations with different parameters, the optimization space for hardware and software targeting deep learning is large and underspecified.」
「DeepBench attempts to answer the question, "Which hardware provides the best performance on the basic operations used for deep neural networks?". We specify these operations at a low level, suitable for use in hardware simulators for groups building new processors targeted at deep learning. DeepBench includes operations and workloads that are important to both training and inference.」
上述文字中的一個關鍵詞就是「basic operation」，和 Eyeriss 團隊直接用經典的 DCNN 網路作為 Benchmark 不同，DeepBench 嘗試使用基本操作而非完整網路模型來作為 Benchmark。而另一個差別在於，Eyeriss 團隊主要工作在於設計 Inference 專用的硬體加速器，因此他們更關心 Inference 應用，而 DeepBench 則同時考慮 Training 和 Inference 的硬體評測問題。
下面這幅圖是 DeepBench 在一個 Deep Learning 生態系統中的定位。
以下是他們對這個定位的說明：
DeepBench uses the neural network libraries to benchmark the performance of basic operations on different hardware. It does not work with deep learning frameworks or deep learning models built for applications. We cannot measure the time required to train an entire model using DeepBench. The performance characteristics of models built for different applications are very different from each other. Therefore, we are benchmarking the underlying operations involved in a deep learning model. Benchmarking these operations will help raise awareness amongst hardware vendors and software developers about the bottlenecks in deep learning training and inference.
可以看出，DeepBench 試圖設計更具普遍性的 Benchmark，因此選擇使用底層的操作（underlying operations）來評測在 Training 和 Inference 中的瓶頸問題。這實際上也是試圖解決我們在上篇文章中提到的，「使用幾個 DCNN 網路作為 Benchmark 是否具有普遍性？」這一問題。到這裡，我們可以比較清楚的看到 DeepBench 的基本思路是設計類似 Dhrystone 這樣的「Synthetic Benchmark」思路。
需要指出的是，DeepBench 使用了硬體廠家提供的 Library，比如 Nvidia 的 cuDNN，Intel 的 MKL，還有 ARM 的 Compute Library。也就意味著它的「基本操作」是比這些 Library 封裝的「基本操作」（比如矩陣乘法）的粒度要粗的，並且需要 Library 的支援。如果其它硬體廠商也想使用 DeepBench，則也需要提供類似的 Library（當然還包括一些 porting 的工作）。另外，它評估的結果實際是包括了目標硬體加 Library 的整體效能，而非單純硬體本身。由於實際的應用者一般也是基於 Library 進行開發，所以這種方式也是合理的。但是，對於需要定位硬體設計問題或者瓶頸的人來說，使用這樣的方法還需要考慮到 Library 對結果的影響。比如在 DeepBench 最新發布的時候，ARM 的 Compute Library 還只支援單精度浮點的卷積操作，不支援 8 位元定點；同時它也沒有對 RNN 對的支援，這些功能限制對於測試效果的評估還是有比較大的影響的。
和 Eyeriss 提出了很多有特色的「Benchmarking Metrics」不同，DeepBench 的測試指標是比較簡單的，主要就採用執行時間「Time（msec）」進行效能的評價。所以，我們對 DeepBench 的討論主要還是集中於它設計的「測試程式」。
七
下面我們就具體看看 DeepBench 設計的用於 Training 和 Inference 的 Benchmark。
對於 Training，DeepBench 從不同的應用模型（Source 列）中總結出了一些特定的操作（Type of Operations）。如下表所示：
其中最基本的操作包括三類：Dense Matrix Multiplication，Convolution，Recurrent Layers。這些選擇是比較自然的，基本可以覆蓋各種 DNN 的情況。最後一類 All-Reduce 是專門針對多 GPU 並行 Training 的場景。
對於每一種 Operation，都有不同的引數。比如 Converlution 操作，就有如下的引數：W (input - time), H (input), C (channels), N (batch size), K (number f filters), R (filter width), S (filter height), pad_h pad_w, Vertical Stride, Horizontal Stride, Platform (server or device), Forward, wrt Inputs, wrt Parameters。DeepBench 對每種 Operation 都定義並且實現了多種不同的引數組合，反映各種應用中比較常見的配置（可以看作是一個測試核心 Kernel）。具體的各種 case 大家可以看網站提供的 Excel 表格，以及 Kernel 的具體實現。
以下是 Inference 的主要操作和對應的一些典型應用（Source 列）：
對於 Inference 的 BenchMark，除了基本操作以外 DeepBench 還討論了以下幾個問題。
Deployment Platform：分析了 DNN 模型部署在 Server 端（我們之前經常說的 Cloud/Datacenter）和 Device 端（Edge/Embedded）的特點，也說明了 DeepBench 對不同的部署平臺做了有針對性的測試。
Inference Batch Size：分析 Batch Size 對於效率和延時的影響（Batch Size 越大，並行處理的可能性閱讀，實現效率越高，但處理延時也越大），以及在兩者之間如何平衡。從 DeepBench 測試的結果來看，「在 Server 端採用 4~5 的 batch size，而在 Device 端採用 1 的 batch size 是一個比較好的選擇」。
Inference Precision：討論 Inference 精度的問題，以及 DeepBech 對精度選擇的原因。
Sparse Operations：分析稀疏性對 inference 效能的影響。一個有趣的結論是「基於我們的研究，與其密集模型基線相比，具有 90 至 95％稀疏度的神經網路可以實現相對較好的效能。然而，當前實現的稀疏矩陣乘法主要是對更高的稀疏度（大約 99％或更高）而優化的。通過包含稀疏核心（我們在上面的表格中看到的「Sparse Matrix Multiplication」operation），我們希望激勵硬體供應商和軟體開發人員構建為 90％至 95％的稀疏性提供更好效能的硬體和庫。」
Measuring Latency：「許多 Inference 應用具有實時延遲要求。DeepBench 定義的核心可以作為衡量單個操作的最佳延遲的起點。但是，考慮到基礎操作不是完整的應用程式，測量全系統延遲不在本版本 DeepBench 的範圍之內。」這裡反映了使用基本操作作為測試程式的問題：無法統計整個實際應用程式（比如 AlexNet）所花費完整時間。這是目前 DeepBench 面臨的一個主要困難。在未來能否設計出更好的基本操作，並基於這些基本操作設計一些組合操作來模擬實際的應用程式，是值得研究的課題。
對於最後這個問題的討論，也反映出 Synthetic Benchmark 設計的難度：如何通過「設計」，讓不是真實應用的測試程式來準確「模仿」真實的應用，並得到能夠反映現實世界情況的結果。從更大範圍來看，隨著 DNN 軟硬體實現的不斷優化，如何對其進行評價，驗證和測試將會是我們一直要思考的問題。DeepBench 是一個非常有益的嘗試，希望未來還能看到更多更好的解決方案。
Reference:
[1]「Tutorial on Hardware Architectures for Deep Neural Networks」, http://eyeriss.mit.edu/tutorial.html
[2] "Benchmarking DNN Processors" , http://eyeriss.mit.edu/benchmarking.html
[3] "Comparing dense compute platforms for AI", https://www.intelnervana.com/comparing-dense-compute-platforms-ai/
[4] Williams, Samuel; Waterman, Andrew; Patterson, David (2009-04-01). "Roofline: An Insightful Visual Performance Model for Multicore Architectures". Commun. ACM. 52 (4): 65–76. ISSN 0001-0782. doi:10.1145/1498765.1498785
[5]「DeepBench」, https://github.com/baidu-research/DeepBench
作者簡介：唐杉博士先後在 T3G（STE）、中科院計算所、紫光展銳（RDA）工作。具有 15 年以上的晶片設計經驗，在 3G/4G 通訊基帶處理，專用處理器 ASIP，多核 SoC 架構，ESL 級設計和 Domain-specific 計算等方面有深入研究和實際經驗。近一年來主要關注 Deep Learning 處理器和相關技術，現在 Synopsys 公司任職。公眾號：StarryHeavensAbove。