OpenEM 簡介和基于 OpenEM 的大矩陣乘實現(xiàn)

2.3.2 基于 OpenEM 的性能測試結(jié)果

基于 OpenEM的演示用例實現(xiàn)過程中，DSP 代碼中嵌入了少量測試代碼收集運行的 cycle 信息。每個核把自己處理每個 event 的起始和結(jié)束時間記錄在內(nèi)存(我們通過一個全局 timer 來保證所有DSP 核記錄的時間戳在時間軸上是同步的)。這些時間戳用 CCS 存到主機做后處理分析。通過分析，我們可以得到 8 個 DSP 核并行處理消耗的時間。還可以分析每個 DSP 核的忙/閑區(qū)間。

測試結(jié)果是，從第一個 event 開始處理到最后一個 event 處理完，總時間是 31,433,438 cycle，也就是 31.4ms。也就是說，通過 OpenEM把單 DSP 核的工作負(fù)載平衡到 8 個 DSP 核上能達(dá)到的DSP 核利用率是 190,574,214/(31,433,438*8)= 76%。

通過對時間戳的處理我們得到下面的運行圖，“-”表示 receiver 函數(shù)處理 event 的區(qū)間，本文稱之為有效時間。“#”表示 receiver 之外的區(qū)間(也就是代碼在 dispatcher 中執(zhí)行的區(qū)間)，本文稱之為調(diào)度開銷。每個“-”和“#”刻度表示 100,000 CPU cycle。

從上面的執(zhí)行圖看，調(diào)度開銷不小，占了大約 15～20%的時間。但是這只是表面的現(xiàn)象。實際上，調(diào)度開銷的大部分時間里，Dispatcher 是在查詢 hardware queue，等待新的 event。這是因為preload 沒能及時完成導(dǎo)致的。因為同時給 8 個核做 preload 需要很大的數(shù)據(jù)搬移的流量。根據(jù)以往的測試結(jié)果。使用 QMSS 的 packet DMA 從 DDR3 輸入數(shù)據(jù)到 local L2 的流量大約是 4G bytes 每秒。那么 preload 8 個 event 總的數(shù)據(jù)量是 4byte * 2048 rows * 16 columns * 8 core = 1M bytes，需要的時間是 1/4 ms。因為每個“-”和“#”刻度表示 100,000 CPU cycle，運行圖中紅線長度就代表 preload 8 個 event 的時間，它非常接近 250,000 cycle。理論計算和實際值基本吻合，所以我們認(rèn)為調(diào)度延遲是 packet DMA 的傳輸流量不足導(dǎo)致的。

我們也測試了不使用 pre-load 的場景。觀測到 scheduler 調(diào)度一個 event 的延遲大約是 1200 個C66 CPU cycle。但是 DSP 核處理一個 event 的耗時增大到原來的 10 倍。所以，pre-load 雖然會導(dǎo)致 QMSS packet DMA 流量不足成為凸顯的瓶頸，但是從總體效率來看還是非常必要的。

細(xì)心的讀者可能會發(fā)現(xiàn) 76% + 20% = 96%，并不是 100%。我們分析時間戳發(fā)現(xiàn)，8 個 DSP 核同時運行的場景下，每個核處理一個 100*2048 × 2048*16 的矩陣乘的時間比只有一個 DSP 核運行的場景下的時間稍長。原因是： 我們的演示用例中 X 矩陣和 Z 矩陣是存儲在 shared L2 的， 8 個核同時運行就會同時讀寫這兩個 buffer，導(dǎo)致產(chǎn)生 shared L2 的 bank 沖突。 所以性能下降了。

3、總結(jié)

OpenEM具有使用簡單，功能實用，執(zhí)行高效的特點。能在 KeyStone 多核 DSP 上實現(xiàn)動態(tài)的負(fù)載平衡。它一方面提供了強大的功能，另一方面也給應(yīng)用留出了很大的靈活性。例如，通過讓應(yīng)用初始化 free pool 方便了 buffer 的管理。OpenEM 的現(xiàn)有功能已經(jīng)能夠支持基本的應(yīng)用。隨著版本更新功能還將不斷完善。

Reference

Ref[1] ti.openem.white.paper.pdf 位于 OpenEM 安裝目錄