程式算法本身的複雜度
CPU的速度和設計架構
CPU的位元帶寬
自己的程式的寫法
將一個照片RGB格式的彩色圖像轉換成黑白照片。
轉換的公式如下：
Y = 0.299 * R + 0.587 * G + 0.114 * B;
圖像尺寸640*480*24bit，RGB圖像已經按照RGBRGB順序排列的格式了。
以下是輸入和輸出的定義：
已經完成了第一個最佳化
看得出來最佳化在哪裡嗎？
優化原則： 圖像是一個2D資料，我用一個1維陣列來存儲。 編譯器處理1維陣列的效率高過2維陣列
這大概是能想得出來的最簡單的寫法了，實在看不出有什麼毛病，好了，編譯一下跑一跑吧。
這個代碼分別用VC6.0和GCC編譯，產生2個版本，分別在PC上和embedded system上面跑。
速度多少？說出來嚇死你！
第一次試跑的成績
在PC上，因為有硬體浮點運算處理器，CPU頻率也夠高，計算速度為20秒
embedded system ，沒有以上2個優勢，浮點操作被編譯器分解成了整數運算，運算速度為120秒左右
這只是一副圖像的運算速度！！
上面這個代碼還沒有跑，就已經知道會很慢了，因為這其中有大量 的浮點運算。只要能不用浮點運算，一定能快很多。
那這個公式怎麼能用定點的整數運算替代呢？
可以如何化簡？
我們就先簡化算式D吧！
RGB的取值範圍都是0~255,都是整數，只是這個係數比較麻煩， 不過這個係數可以表示為：
這一下，能快多少呢？
化簡後的成績
PC上的速度2秒
Embedded system
上的速度45秒
這個代碼編譯後，又快了20%
還是太慢！
雖然快了不少，還是太慢了一些，
20秒處理一幅圖像，地球人都不能 接受！
仔細看一下這個式子！
RGB的取值有文章可做，RGB的取值永遠都大於等於0，小於等於
255，我們能不能將D,E,F都預先計算好呢？然後用查表算法計 算呢？
我們使用3個數組分別存放DEF的256種可能的取值，然後。。。
查表數組初始化
突破音障!
這一次的成績把我嚇出一身冷汗，執行時間居然從30秒一下提高到 了2秒！在PC上測試這段代碼，眼皮還沒眨一下，代碼就執行完了。
一下提高15倍，爽不爽？
下一程，幾 秒？
120秒 ->45秒 -> 30秒 -> 2秒
還能再 快嗎？
很多embedded sysytem 的32bitCPU，都至少有2個ALU，能不能讓2個ALU都跑起來？
2個ALU處理的數據不能有數據依賴，也就是說：
某個ALU的輸入條件不能是別的ALU的輸出，這樣
才可以並行
到這裡，似乎已經足夠快了，但是我們反覆實驗，發現，還有辦法再快！
Int D[256]，E[256]，F[256]； //查表數組 更改為：
Unsigned short D[256]，E[256]，F[256]； //查表數組
這是因為編譯器處理int類型和處理unsigned short類型的效率不一樣
將函數聲明為inline,這樣編譯器就會將其
嵌入到母函數中，可以減少CPU調用子函 數所產生的開銷
這2個小小的改進帶來的效益！
一次的成績是： 0.5秒
現在，我們已經達到了客戶的要求！
如果加上以下措施，應該還可以更快：
把查表的數據放置在CPU的高速數據CACHE
裡面
把函數calc_lum()用組合語言來寫
同樣的需求，寫法不一樣，速度可以從120秒 變化為0.5秒，說明CPU的潛能是很大的！看你 如何去挖掘。
沒有留言:
張貼留言