重視 CPU 運算(CPU-bound)的應用程式

在這小節內我們挑選了gnupg-1.4.1 與 gawk-3.1.0 來評量。前者主要用 來產生電子信件的訊息文摘(message digest)和簽章(signature)，其執行的時 間隨電子信件的大小增加成ㄧ定比例增長。後者為一個簡單的腳本程式直 譯器(script interpreter)，執行的時間與腳本程式的大小與複雜度有關。由於 這兩個實驗都需要讀入檔案，我們以執行時間為橫軸與記憶體使用量（不 包含程式本文所佔的空間）為縱軸，觀察實驗數據對不同大小檔案變化的 趨勢。

gnupg 的實驗中將 gnupg 三種版本對六種大小分別為 512 KB、1024 KB、1536 KB、2048 KB、2560 KB 和 3072 KB 的檔案做密鑰大小為 4096 位元的RSA 加密，之後再使用 gnupg 對前一個實驗後加密過的檔案做解 密。我們也量測了BODAR 在 64 位元電腦上的實驗結果。

3200

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

CRED

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

(a)

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

CRED

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

(b)

圖3-3 gnupg 的實驗結果。(a)不同版本的 gnupg 用 RSA 加密六個檔案的 結果，(b)不同版本的 gnupg 用 RSA 解密六個檔案的結果。以上右圖均為左

圖移除 CRED 版本後的結果。

圖3-3 可看到執行時間與檔案大小成等量增長，gnupg-Original 的加密 與解密執行時間增加量上分別是0.13±0.006 秒與 0.09±0.006 秒，而

gnupg-CRED 的增加量則是 3.08±0.1 秒與 3.57±0.09 秒，為原先的 23 倍與 41 倍，不難想見 CRED 機制對於程式的效能影響相當大。反觀

gnupg-BODAR 的增加量是 0.14±0.005 秒與 0.10±0.008 秒，為原來的 1.07 倍與1.16 倍，且在 64 位元電腦上這個倍率會更小，受 BODAR 保護的 gnupg 幾乎不會造成太大的效能負擔。

此外，圖中可見到輸入檔案大小與記憶體使用量無關，在32 位元電腦 上，gnupg-BODAR 在記憶體空間使用量上，加密與解密與原來版本比較分 別多了440 KB 與 700 KB，而在 64 位元電腦上則多了 440 KB 與 712 KB，

雖然在64 位元的電腦上 gnupg-Original 的記憶體使用量由於基本型態大小

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

CRED

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

(a)

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

CRED

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

(b)

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

CRED

Execution time (s)

Data size (KB)

Original Original-64

BODAR BODAR-64

(c)

圖3-4 gawk 的實驗結果。(a) gawk 執行 A 腳本程式，(b) gawk 執行 P 腳 本程式，(c) gawk 執行 S 腳本程式。以上右圖均為左圖移除 CRED 版本後

的結果。

在gawk 的實驗方面，我們設計讓 gawk 執行三支不同的的腳本程式，

access-time.awk、proxy_stat.gawk 和 scalar.awk（以下分別稱 A、P、S 腳本

程式），這三支腳本程式都是用來處理squid 代理伺服程式(proxy)所產生出 的記錄檔，A 腳本程式的大小與複雜度最小，S 腳本程式最大。實驗結果如 圖3-4。gawk-BODAR 在 A 腳本程式中的效能表現相當良好，只多增加了 約7%的效能負擔。但是隨著腳本程式越來越大且越來越複雜，gawk 需要 配置越多的緩衝區，因此效能會負擔越來越高。即是如此gawk-BODAR 執 行P 與 S 腳本程式時增加的效能負擔約為 80%，相比於 gawk-CRED 的 14 倍至28 倍，在效能方面 BODAR 版本亦擁有不錯的表現。

在記憶體使用量方面，直譯器需要剖析(parse)腳本程式，經常會進行字 串切割並且產生相當多的小型的緩衝區來容納切割的字符(token)。但是 BODAR 在設計上透過硬體分頁保護機制，配置緩衝區的最小單位為一個分 頁。當程式越大越複雜將會使用比以往更多的空間。此外，記錄檔大小亦 會影響gawk 配置緩衝區的數目而使問題更嚴重，實驗結果中除了 A 腳本 程式對此幾乎無影響外，P、S 腳本程式的記憶體使用量均會隨者紀錄檔大 小增加而增加，尤以S 腳本程式更為明顯。gawk-BODAR 在實驗中最糟糕 的情況下將花費271 MB 的虛擬記憶體使用量，這是原來程式的 25 倍