用於嵌入式多 核 心 架構 的前瞻式任務管理單元 A Look-Ahead Task Management Unit for Embedded Multi-Core Architectures

1. 2012/12/17 用於嵌入式多核心架構的前瞻式任務管理單元A Look-Ahead Task Management Unit for Embedded Multi-Core Architectures 指導教授 ：周 哲 民 學 生 ：陳 佑 銓 CAD Group Department of Electrical Engineering National Cheng Kung University Tainan, Taiwan, R.O.C

2. 大綱 • Introduction • Parallel Applications with Task Dependencies • Task Management • Task Management Unit • Evaluation Setup • Results • Conclusions

3. Introduction(1/3) • 當前的趨勢是增加更多的電腦體系結構核心來提高效能。這也同樣適用在嵌入式領域。 • 為了在多核心架構上提高效能，應用程式的切分成數個任務是必要的，如此可以平行執行在單獨的核心。 • 在多媒體領域，一個應用程式的劃分，通常都會引入任務之間的相依關係，迫使要依一定的順序來執行任務。 • 對於這類的應用程式的工作負載，任務調度成為一個任務管理問題。 • 任務的創建與分配，必須引入演算法，去追朔的相依關係和確定何時準備好要執行的任務。 • 對於Super HD H.264清晰度的並行解碼器（3840×2160 pixels），用於追蹤一個任務可以被執行的code，占並行的執行時間9％。

4. Introduction(2/3) • 一般來說管理任務的代碼是簡單的，具算數運算（如整數加法，減法，和比較），分支和不可分割的(atomic)載入和儲存。 • 這些操作可以有效地實現在任務管理單位，將相依的計算從傳統的核心中卸載。 • 任務管理單元可以等待，直到某個核心所執行的任務完成之前，更新它的相依關係。 • 任務管理單元會有當前相依關係狀態和確切地知道哪些任務可以執行。 • 如果不是先前任務在當前執行的核心完成之後所準備執行的，它必須等待的任務管理單元去更新相依關係，並檢查是否準備執行新的任務。 • 這增加了額外的延遲

5. Introduction(3/3) • 在一般情況，無法在任務執行完成前更新其相依關係。然而，當任務正在執行，或許能找到一些當前執行的任務所應解決的相依關係。 • 如果有任務只相依於當前執行的任務，這些任務將會做好執行的準備，一旦當前正在執行的任務完成。任務管理單元可以讓這些準備任務準備執行，一旦核心已完成當前執行的任務，它可以立即開始執行下一個任務。 • 一個附加的好處是，彼此相依的任務執行在相同的核心，它可以提高資料的局部性。 • 本文所提出的前瞻式Task Management Units（TMUs），能夠執行任務相依關係的檢查，且與任務的執行平行處理。 • 每個TMU從一些常規的核心卸載相依關係的檢查/更新，並試圖調度相依任務到相同的核心上，從而保持資料的局部性。 • TMUs透過任務佇列來完成分配任務。

6. Parallel Applications with Task Dependencies(1/7) • 我們針對的應用程式的工作負載，是切分應用程式到任務中，這將引入任務之間的相依關係。 • 例如H.264並行視頻解碼 • 對於具有任務間的相依關係的應用程式，正確的執行順序是應用程式運作的關鍵。 • 執行順序並不總是在編譯時靜態確定的，因為在執行任務時會有變化。 • 因此，我們的方法是在運行時動態管理任務相依關係。

7. Parallel Applications with Task Dependencies(2/7) • 本文所提出的驅動應用程式的架構為Super HD（3840 x 2160 pixels）的H.264視頻解碼[4] 。 • 先進的H.264 視訊壓縮標準在嵌入式市場佔有主導地位，在高清晰度視頻（如藍光播放機）和低頻寬段(Sony PSP) 。 • 隨著目前市場上的最強大的單核心解決方案，它是可以對HD(720p)進行H.264即時解碼[5]。 • 而Super HD要求約9倍以上的效能，在目前的趨勢，需要更多的核心，而不是一個更快的核心。 • 所以需要一個多核心架構來運行Super HD H.264解碼。

8. Parallel Applications with Task Dependencies(3/7) • Frame經由entropy解碼開始處理，存在不論是兩種Context-Adaptive Binary Arithmetic Coding（CABAC）或者Context-Adaptive Variable Length Coding（CAVLC），而且這兩種解碼方式本質上是連續的。 • 之後傳遞到的圖像預測的階段。 • 在此階段，對於每個巨集塊的圖片間的預測和運動向量(motion-vector)的估計都會計算出來。 • 然後通過去塊篩檢程式過濾以減少在圖片預測階段所引入在區塊邊界的加工。已解碼完畢的frame可以傳送去顯示。解碼後的frame也是圖片間預測的緩衝。 圖1示出了一個H.264視頻解碼器的主要部件。

9. Parallel Applications with Task Dependencies(4/7) 圖.2 在H.264影像壓縮巨集塊間的相依關係 圖.3 H.264解碼器的任務相依圖

10. Parallel Applications with Task Dependencies(5/7) • 圖片的預測和去塊濾波器適合並行化，其中的巨集塊的執行可以視為一個任務。 • 然而，一個巨集塊不能在若干相鄰的巨集塊有執行時之前執行[2]。圖.2表示在巨集塊中的相依關係的廣義圖。 • 從圖中可以看出，以灰色標記的巨集塊可以執行前，巨集塊的左側和三個在頂部均須執行。 • 任務依賴關係圖可以由巨集塊的依存關係構建出來，如圖.3所示。 • 該圖開始的左上角的巨集塊中，由於所有的依賴都解決了。 • 當第一任務（0/0）已經執行，第二個任務（1/0）就可以開始。 • 每個潛在的新的任務可以開始執行一個或兩個其他任務。

11. Parallel Applications with Task Dependencies(6/7) 圖.4 檢查巨集塊間的相依關係的虛擬code

12. Parallel Applications with Task Dependencies(7/7) • 任務相關關係可以由儲存的相依任務數量來追朔。 • 對於H.264這個值可以是零個，一個或兩個。 • 對於每一個完成的任務，具有相依關係的陣列更新時，相依於已完成任務的任務的值會逐漸遞減。一旦陣列中的值變為零，任務就可以執行 [6]。 • H.264解碼器相依關係的更新可以用圖.4中虛擬代碼(pseudo coed)來描述。 • 在這裡X和Y是剛剛完成執行的巨集塊之索引(index)。 • 第一個if語句檢查所相依的巨集塊是否在frame內。如果在巨集塊在frame的範圍內，它的依賴關係值會遞減1。 • 一旦該值變為零，即巨集塊沒有更多的相依關係和準備執行的巨集塊。 • 需要注意的是遞減操作，必須以不可分割地(atomically)執行。

13. Task Management(1/5) • 在一個任務調度以任務佇列為基礎的架構上，一個任務的執行後跟隨著由一段程式代碼（圖5），這段程式代碼更新相依關係和檢查準備好要執行的任務。 • 為簡單起見，圖中假定每個的任務執行時間是相同的，與實際中的情況下不同。任務相依關係的檢查代碼往往是簡單的，但對整體執行時間，它仍然是一個顯著的部分。對於Super HD H.264解碼器，相依檢查已發現增加一個任務的平均執行時間的9％。 • 在每11個核心的架構，計算管理任務需要一個完整的核心的計算能力。 圖.5傳統的執行系統架構。

14. Task Management(2/5) • 為了增加具有任務相依關係的應用程式的執行速度，與增加在等面積上的效率，相依關係的檢查可以由任務管理單元(TMU)來加快，去追朔任務的相依關係和確定何時準備好要執行的任務。 • 一個簡單的方式去實施這樣的TMU，是去簡單地從核心卸載執行計算相依關係的任務。一旦任務完成後，它將發送任務完成的信號到TMU，然後並且TMU開始尋找一個新的執行任務給核心。 圖.6 一個簡單的方式TMU

15. Task Management(3/5) • 這樣實現的選擇會有兩個主要缺點： • 如果有比核心較少的任務，在TMU可以找到給核心執行的新任務之前，TMU仍然必須執行任務的相依關係代碼，因此增加了類似於直接(straight-forward)的解決方案所造成的延遲。 • 總是透過在任務佇列中儲存任務，資料局部性可能會喪失，因為相依於彼此的任務很有可能在不同的核心上執行。這將導致額外的壓力在記憶體子系統上，並對執行時間有負面影響。

16. Task Management(4/5) • 在執行過程中找到所有與正在執行中任務相依的任務是可能的。所有找到的任務是由核心執行的候選人。這些任務之一可以立即被核心執行，一旦核心完成其當前任務。 • 例如，在圖3，當處理（1/0）時，TMU可以找到兩個任務，（2/0）和（0/1），可以在（1/0）執行後，立即開始。 • 更新相依關係的任務可以由TMU並行完成。 • 這使得任務之間的執行的時間最小量(以下稱為周轉時間turn-around time) • 相依任務執行在相同的核心，因此提高了資料局部性。 • 在TMU不能夠找到一個任務已經準備好的情況下，它依然能改善任務之間的周轉時間。確定所有相依的任務和讓他們隨時可用，相依關係的更新可以快速地進行。

17. Task Management(5/5) • 圖.7示出一個例子，其中12個正在四個不同的核心上執行的任務，配合在TMU上平行執行的前瞻式的代碼。 • 第一個執行任務在第一核心上和第二執行任務在第二核心上，若發現一個任務其相依關係已經完成，則一旦核心的已完成的當前執行的任務，此任務可以立即開始。 • 對於其他的任務，找到一個要執行的任務之前必須要更新其相依關係。 圖.7 TMU加上前瞻式執行

18. Task Management Unit(1/6) • 任務管理單元（TMU）的目的，是在多核系統中從傳統的核心卸載任務管理。因此TMU緊密相連的到數個的核心，這些核心會發送信號到TMU當他們已經完成了任務。當核心正在執行任務時，TMU試圖找到準備好要執行的任務，並讓他們做好準備，如此當核心完成目前的執行的任務，它可以直接開始執行新的任務。 • 對於每一個正在執行的任務，TMU執行即時前瞻的功能，為了嘗試找到準備好了的任務。在一個系統中具有更多的核心，則在單一的時間點需要執行更多的前瞻功能。 • TMUs和核心之間的比率依賴於任務負載與控制負載的比率。 TMU從幾個核心中卸載控制負載並且依序執行。

19. Task Management Unit(2/6) 圖.8具有四個TMUs的16核心架構

20. Task Management Unit(3/6) • 圖8示出具有四個TMUs的結構，每個TMU連接到四個核心。在這種情況下TMUs共用一個任務佇列。 • TMU應為可程序化的，允許複雜的任務相依關係，能夠執行簡單的算術操作，並快速的執行分支。 • 此外，可程式化的TMU可以支援不規則任務的相依關係，甚至不清楚任務在編譯時的靜態相依關係。 • 為了更具靈活性，每個TMU也有一個關聯的硬體mailbox可用於訊息的傳遞。

21. Task Management Unit(4/6) • 任務指向器：任務指向器保持第一條任務的指令的位址。 • 參數指向器：位址保存到任務存儲的參數 。 • 前瞻指向器：前瞻指向器告訴TMU執行前瞻功能，當任務由核心執行時。 • 相依關係指向器：保持記憶體位置的位址，存放在任務可以執行前，仍需解決的相依關係數目。 • 旗標：旗標是用來核心的同步和TMU的同步，去告知任務所在的狀態。

22. Task Management Unit(5/6) • 候選者表主要目的是，加快正由核心所執行的任務之間的turn-around time。 • 允許核心直接訪問到列表中。 • 如果有準備執行的任務，則核心的讀出任務和參數指向器的候選名單，並開始執行新的任務。 • 然後，與執行的任務並行處理，TMU將減少沒有被執行的任務的相依關係指向器的值。

23. Task Management Unit(6/6) • 候選清單是具有固定的硬體結構數目的條目。這限制了相依任務的數量(子)，可以有一個特定的任務(父)。 • H.264解碼器不會有兩個以上的子任務，但在其他應用程式的情況下是有可能發生的。 • 為了讓任務具有無限數量的子任務，必須添加任務與其他任務的相依關係的更新。 • 這將引入的間接費用， • 所以候選名單中應該有足夠的項目給運行在系統中最常見的數個子應用程式。 • 然而，Stavrou等人在文獻[7]指出，大多數資料驅動在多執行緒任務最多具有兩個相依關係，所以四個項目的候選者名單應該適用在大多數情況下。

24. Results(1/2)

25. Results(2/2) • TMU結構優於任務隊列結構。模擬結果，在當前任務完成其執行時，有82％的任務已經在等待執行。 • 在8個核心配置效能改善了4.5％ 。 • 最低的16個核心配置效能提高了3.4％。 • 這構成了減少40％至50％從任務佇列模擬中的任務管理開銷。 • 核心的數目增加時，每個核心來執行較少的任務，因此，在某些情況下，將會有閒置的核心。 • 這就解釋了為什麼會隨著核心數量的增加而增速下降。

26. 結論 • 任務管理單元（TMU）優於以任務池為基礎的多核心架構，由於其前瞻能力 • 總體而言，以TMU為基礎的多核心架構在1 6個核心上運行Super HDH.264視頻解碼，達到14倍以上的增速。 • 以TMU為基礎的多核心架構可以執行不相依的任務，如同任務佇列架構依樣快速。

27. Thanks for your attention.