本論文一直闡述想的法在第五章介 紹了實作的過程。在這一章將會做五組不 同的實驗來驗證 HMP Scheduler 的動態排 程功能和系統效能。首先我們會介紹實驗 的環境，接著再介紹各組實驗，包括實驗 的方法和討論。
5.1 實驗環境
在這一段落先介紹實驗使用的的應 用程式，它是 H.263 的 decoder。 H.263 decoder 是用來將己經壓製好的 m4v 檔案 解回 yuv 檔案。主要的 function 也就是將 在實驗中註冊為 service 的 function 如下：
idct：對所有 frame 做 inverse DCT。
dequant_inter ： 對 inter frame 做 inverse quantization。
deqaunt_intra：對 intra frame 做 inverse quantization。
interpolation：對 inter frame 做垂直點 之間、水平點之間、和對角線點之間 的 interpolation。
GPP 核心和 DSP 核心都設定 為 96MHz。使用的 bit-stream 是 foreman。
我們準備了三種不同的 bit rate，其特徵如 表 II 所示：
TABLE II. 實驗 bit-stream
Name Type Frame Frame rate
Bit rate
Foreman QCIF 300 30 192k Foreman QCIF 300 30 128k Foreman QCIF 300 30 64k
測定用的 timer 是 OMAP 5912 平台 上 ARM private peripheral timer 2，它的頻 率為 12MHz。time tick 與 micro second 的 轉換如下：
(time tick +1) * 2 / Frequency * 1000 = micro second
ARM Private Timer 2 Registers
BYTE
ADDRESS REGISTER NAME DESCRIPTION ACCESS
WIDTH ACCESS
TYPE FFFE:C600 MPU_CNTL_TIMER_2 Timer 2 Control Timer Register 32 RW
FFFE:C604 MPU_LOAD_TIM_2 Timer 2 Load Timer Register 32 W
FFFE:C608 MPU_READ_TIM_2 Timer 2 Read Timer Register 32 R
表 8 為 timer register 列表。第一欄紀錄每 個 register 在 ARM 記憶體空間的 address。
接著兩欄位是 register 名稱和描敘。第四欄 代表每個 register 的長度是 32 位元。第一 列是 control register，用來開啟或關上 timer，名為 MPU_CNTL_TIMER_2。第二 列的 register 是 MPU_LOAD_TIM2，使用 timer 前可以填入自訂的值，由該值開始倒 數，等於是控制 timer 計時的全部長度。
第三列是 timer 被啟動之後，依時間 MPU_LOAD_TIM_2 遞減所得的新值會出 現在這個 register 中。此 register 稱為 MPU_READ_TIM_2。此外
MPU_CNTL_TIMER_2 尚可控制當 timer 倒數到零時的動作，共有兩種可以選擇，
其一是狀態自動全部重設，再開始倒數；
另一種是直接停止。本實驗將
MPU_LOAD_TIM_2 設為最大值 2^32，足 夠每一次實驗的時間，故當 timer 倒數到 零時就直接停止，不再動作。自下節開始 有各組實驗目的和結果的探討。
5.2 動態排程實驗
這個實驗的目的在於觀察動態排程 的實作結果。在相同環境下，使用 bit rate 192 K-bps 的 bit-stream，執行 HMP
Scheduler。預測每一種 service 各自分佈在 ARM 和 DSP 上的比例會相差無幾，但是 不會每次的數字都不變。下面表 9 到表 11 是相同的實驗執行三次的結果：
動態排程實驗 1
time(ms) ARM(次) DSP(次) sum(次)
idct 3888 18043 3659 21702 dequant inter 2221 14693 3385 18078 dequant intra 455 2949 675 3624 interpolation 4158 25646 5843 31489
service time 10724 app time 14256
sum(次) 61331 13562 74893
動態排程實驗 2
time(ms) ARM(次) DSP(次) sum(次) idct 3886 18059 3643 21702 dequant inter 2220 14699 3379 18078 dequant intra 454 2947 677 3624 interpolation 4162 25625 5864 31489
service time 10723 app time 14258
sum(次) 61330 13563 74893
動態排程實驗 3
time(ms) ARM(次) DSP(次) sum(次) idct 3894 18033 3669 21702 dequant inter 2218 14693 3385 18078 dequant intra 455 2941 683 3624 interpolation 4164 25632 5857 31489
service time 10733 app time 14271
sum(次) 61299 13594 74893
每張表前四列代表不同 service，第 一欄是每個 service 所花費的時間，單位是 毫秒。第二和第三欄分別是該 service 在 ARM 和 DSP 上處理的次數。而最後一欄 是每個 service 總共會處理的次數，因為所 用的 bit stream 相同，故這個值不會改變。
第五列是所有 service 耗去的時間。第六列 代表整個 decoder 執行的時間。第七列則 總和 ARM 和 DSP 的執行次數。
以 interpolation 為例，ARM 上執行 的次數和 DSP 執行的次數三個實驗下來 都是約為 5：1；ARM 和 DSP 執行的總次 數為 6：1。首先看到動態排程在執行時期 確實達到動態分配工作的能力。然而以執 行時間為分配工作的依據，在這個實驗中 可以看到 ARM 所得到的工作量是 DSP 的 6 倍。這是不是意味著 ARM 處理這些 service 的速度較快呢？要探討這個問題，
設計了下面一個相異處理器實驗。
5.3 相異處理器實驗
對於 bit rate 為 192 K-bps 的
bit-stream，實驗在 Pure ARM、Pure DSP、
和 Dual-core 時的效率。在每個處理器上跑 10 次 decoder 再做平均，觀察其效能的不 同。本實驗可以達到兩個目的。第一，探 討 ARM 和 DSP 對 decoder service 的相對 速度。第二，驗證 dual-core 是否可以達到 雙核心加成的能力：
Pure ARM
service time(ms)
application time(ms)
1 12454 15855
2 12451 15853
3 12459 15850
4 12451 15853
5 12452 15845
6 12452 15855
7 12451 15855
8 12450 15853
9 12454 15857
10 12452 15852
average 12453 15853
Pure DSP
service time(ms)
application time(ms)
1 14510 17911
2 14638 18039
3 14892 18301
4 14775 18184
5 14560 17970
6 14475 17876
7 15252 18652
8 13558 16966
9 13577 16987
10 14739 18039
average 14498 17893 Dual core
service time(ms)
application time(ms)
1 11003 14446
2 11055 14502
3 12471 15924
4 14868 18365
5 10170 13598
6 10581 14030
7 11041 14496
8 11803 15287
9 10708 14117
10 11494 14381
average 11520 14915
上方三張表分別是 pure ARM、pure DSP 和 dual-core 三種執行的結果。看到 pure ARM 與 pure DSP 的比較。大家都知 曉 DSP 就是為了處理數位訊號而特別設 計的處理器，其效能應該會比 ARM 來得 好。在這組比較中得知卻是相反的。其中 的原因在於 HMP Scheduler 系統的
overhead。細數 overhead 有下例幾項：
DSP invocation overhead
Memory copy overhead
由第一項開始說明。ARM 如何通 知 DSP 開始工作以及執行哪一個
service？靠著 mailbox 來達成。ARM 如何 得知工作己結束？也是靠 mailbox 來達 成。因此每個 service 交由 DSP 處理無可 避免得承受 mailbox overhead。另外在 DSP 端 kernel 要處理 DSP 上排程問題，也必須 執行 context switch，這些都是 overhead。
測量之下得到一次 DSP invocation
overhead 平均時間要 450 個 time tick。比 較 ARM 和 DSP 對 idct 最長的執行時間，
ARM 為 600 個 time tick；DSP 為 2080 個 time tick。DSP invocation overhead 佔了 DSP 執行時間的五分之一。
另外，第二項 overhead，是 memory copy overhead。DSP 被限制無法存取 ARM 的記憶體空間，除了共用記憶體外。所以 HMP Scheduler 需負責將資料由 ARM heap 區搬到共用記憶提供 DSP 使用；相同 地，DSP 運算完畢後，HMP Scheduler 也 要負責填回到 heap 區。當然這一段時間包 含在 service 給 DSP 處理的執行時間內。
就 idct 而言，必需搬動 64 筆 short 資料兩 次，共要花 100 個 time tick。
表 12、13 和 14 記錄了所有 service 執行時間的總和以及應用程式執行的時 間。現在讓我們檢視各 sercive 在不同處理 器上的執行時間，將表 12 和表 13 各自第 一筆實驗的細部資料列出如下二表；
service time
ARM time(ms) DSP time(ms) idct 3795 idct 4788 inter 2895 inter 3088 intra 591 intra 635 interpolation 5172 interpolation 5998
service time 12454 service time 14510 app time 15855 app time 17911
Reference profile
ARM clock cycles per MB
DSP clock cycles per
MB ratio
(Y)DC pred. & comp. 44268 8465 5.229533373
(Y)Transform 188250 23178 8.121925964
(Y)Quant 247201 39521 6.25492776
(Y)Inv. Quant 238948 30002 7.964402373
(Y)Inv. Transform 202184 27863 7.256361483
(Y)Reconstruct 106392 17835 5.965349033
(DC)DC pred. & comp. 50458 10142 4.97515283
(DC)Transform 88928 11379 7.815097988
(DC)Quant 134689 20814 6.47107716
(DC)Inv. Quant 124131 15410 8.055223881
(DC)Inv. Transform 100497 13907 7.226360825
(DC)Reconstruct 51913 8861 5.858593838
cavlc 396022 46204 8.57116267
ILF 420018 37209 11.28807547
Total 2393899 310790
在表 15 裡面可得到各項 service 的 執行時間、全部 service 總和執行時間、和 應用程式執行時間。我們著重於各項 service 在不同處理器上執行時間的討探，
藉此可以了解不同處理器對同一個 service 的處理速度。以 idct 為例，ARM 和 DSP 的比例是 1：1.26(3.7：4.7)。但是根據研 究室學長過去的的測試[24] ARM 和 DSP 對 idct 的執行時間比為 7.226：1(Inv.
Transform 欄位)，這個數字是在 ARM 沒 有開啟 cache 的情況下產生的。估計 ARM 的 cache 打開後，ARM 的處理時間可能會 下降到為 DSP 的 2 到 4 倍。它意味著 DSP 對 idct 的執行速度比 ARM 快。比對我們 的實驗是 ARM 比 DSP 快。這個差別的來 源是因為我們的 service 是引用 reference software 用 C 寫成，但是[24]的 DSP 部份 是特別以組語寫成，效率上佔極大優勢。
此外 OMAP 5912 的 DSP 是 C55 系例，它 的乘法運算是 16 位元 X16 位元的運算。
在 reference software 中卻有 32 位元 X32 位元的乘法運算，這使得 DSP 必須利用兩 次 16 位元乘法運算來模擬 32 位元乘法運 算。因此我們測量的結果 DSP 效能下降很 多。
何以我們不也改用組語來寫 DSP 部份的程式和改變乘法的使用方式？其原 因是 HMP Scheduler 設計的重點在於減少 platform dependence 以及方便程式的移 植。忠重這個想法，我們對 reference
software 只做最少且必要的修改，其他一 律依原程式的寫法忠實呈現-- 不特別將 C 語言改為組合語言也不特別對程式做最佳 化。所以在這裡 DSP 的效能不如[24]所測 量出來的效能。
5.4 相異 bit rate 實驗
在這個實驗中，考量不同 bit rate 對 HMP Scheduler 效能的影響。以 idct 為例，
在 bit rate 較低的情況下，會有較多的 0 出 現；反之在 bit rate 較高的情況下，0 就比 較少。對於底層硬來說，執行乘以 0 和乘 以非 0 的動作所花費的時間也有所不同。
希望藉由這個實驗探討不同 bit rate 對 HMP Scheduler 的效能有何不同。下面三 個表格依順由 bit rate 高到底排列：
bit rate 實驗：192k bps
service time(ms)
application time(ms) 1 11004 14447 2 11056 14502 3 12471 15925 4 14869 18365 5 10171 13598 6 10582 14031 7 11042 14496 8 11804 15288 9 10708 14117 10 11494 14381 average 11520 14915
bit rate 實驗：128k bps
service time(ms)
application time(ms)
1 9514 11967
2 9139 11565
3 10204 12660
4 9598 12039
5 9525 11969
6 8682 11084
7 8760 11163
8 8633 11033
9 8526 10936
10 9031 11455
average 9161 11587
bit rate 實驗：64 bps
service time(ms)
application time(ms)
1 7082 8541
2 8555 10050
3 7320 8788
4 6367 7789
5 6496 7925
6 7371 8836
7 6356 7781
8 7658 9127
9 8444 9935
10 9074 10559
average 7472 8933
每一張表各執行 10 次 decoder，然 後再取平均值。第一欄 service time 是每一 個 service 所花費的時間的總和；第二欄 application time 代表整個 decoder 完成的時 間，但不包括 I/O 的部份。192 K-bps 的 service time 是 11520 毫秒；128 K-bps 的 service time 是 9161 毫秒；64 K-bps 的 service time 則為 7472. 毫秒。很明顯地解 bit rate 較低的 bit-stream 所使用的時間比 bit rate 較高的 bit-stream 少。以這個 300 張 frame bit-stream 為例，decoder 處理 192 K-bps 的效能為每秒 26 張 frame；128 K-bps 是每秒 33 張 frame；最後，最高效率的 64 k-bps 則是每秒 40 張 frame。可以想像得
到對於 bit-rate 較高的 bit-stream，其運算 量會較高。對於較高的運算量，相較之下 DSP invocation overhead 和 memory copy overhead 這兩個 overhead 和運算量的比例 會降低。可以減低 overhead 對較能的影響。
5.5 DSP delay 實驗
HMP Scheduler 發展的概念是動態 的精細分工排程。換言之，HMP Scheduler 會動態地分辦處理器的狀態。理論上當 DSP 處理 service 的速度快於 ARM，service 會被分配到 DSP。但如果 DSP 同時又因為 有其他工作在做--不是屬於 decoder 的工 作在執行中。在 DSP 上會發生 context switch 輪流處理 service 和另一項工作。這 麼一來 service 的處理，從開始到完成的時 間就會變長。這個影響會使得 HMP Scheduler 將 service 分配給 ARM 執行，以 取得相較之下最好的效能。
我們在 DSP 端隨機地增加不同工 作，分別會使 DSP 上的 service 延遲 1000~5000 的 time ticks 不等。因為測試用 的 services，單次 service 執行的時間在正 常情況下最大不會超過 2500 個 time tick。
選擇延遲最大 5000 個 time tick 就會對 DSP 造成很大的影響，可以達到模擬的目 的。
在實驗中為了使 DSP 延遲，設計除 了 decoder 的 service 之外的另一個給 DSP 執行的延遲用 service，稱之為 D-service。
Kernel 利用隨機的方式決定是否使 DSP 延 遲，如果決定延遲，就同時將 decoder service 和 D-service 一併透過雙核心溝通 機制通知 DSP 執行。D-service 會到上一節 介紹過的 parameter table 讀取 kernel 準備 的參數。此參數告知 D-service 要做多少次 loop，換言之可以決定延遲的 time tick。
經過測量，一次 mailbox 的往返會 花費平均 450 個 time tick。通知 D-service 延遲的時間必需減掉 mailbox 往返的花
費，所以是 550~4550 個 time tick。D-service 內每個 service 設計為消耗 550 個 time tick，於是 550~4550 個 time tick 延遲分別 是 loop 1 ~ 9 次。實驗結果如表 18、19、
20、21 和 22：
dual-core without delay
time(ms) ARM(次) DSP(次) sum(次)
idct 3889 18043 3659 21702 dequant
inter
2221 14693 3385 18078 dequant
intra
456 2949 675 3624
interpolation 4158 25646 5843 31489
service time 10724 application
time
14257
sum(次) 61331 13562 74893
表 18 為對照組，數據內容和表 9 相同。下兩組表格則是本實驗的實驗組。
Dual-core with delay 和 delay distribution 兩 張表格為一組。首先看到 dual-core with delay，第一欄為 service 單獨的執行時間、
service time、和 application time。接著兩 欄分別是各 service 執行在不同處理器的 次數。再來看到 delay distribution 這張表，
delay 這一列顯示的數字是 delay 的 tick
delay 這一列顯示的數字是 delay 的 tick