最近做了一些影象處理的演算法，跑在高通的開發板上，其中使用了opencl進行加速。在此過程中，也總結了幾個加速的小技巧。今天就來談其中乙個不太有用的小技巧：預建立所有kernel。
第一次進行opencl加速時，我注意到，建立cl_kernel時，會耗費幾毫秒到二十幾毫秒的時間。如果演算法中需要建立幾十個cl_kernel，那花費的時間也有幾百毫秒了。這讓人很難接受。
後來我又注意到，對於同乙個kernel，只有第一次建立時才會花費那麼多時間，後續再次建立(無論前面建立的是否已經釋放掉)所花費的時間將會大大減少，幾乎可以忽略不計。那麼機會就來了：我們可以在初始化時預先建立好所有kernel，再全部釋放掉。然後在實際的處理演算法中，和平時一樣使用clcreatekernel()和clreleasekernel()，同時也不用擔心建立kernel所花費的額外時間了。
為什麼我說這個小技巧不太有用呢？因為只有使用原始碼，也就是clcreateprogramwithsource()建立program時，才會出現建立kernel耗時嚴重的現象。而一般發布出來的演算法都會使用二進位制檔案，也就是clcreateprogramwithbinary()，在儲存為二進位制時，一定已經先建立所有kernel了，耗時問題也就不存在了。
但是在加速未完成之前，我們一般還是會直接使用原始碼來除錯。此時預建立所有kernel，可以排除掉建立kernel的時間，使得對演算法的最終執行時間估計更準確。所以，這個小技巧還是有一點用的:)。
效能優化技巧 預關聯
sql中join的效能是個老大難問題，特別是關聯表較多時，計算效能會急劇下降。sql實現join一般是採用hash分堆的辦法，即先計算關聯鍵的hash值，再將相同hash值的記錄放到一起再做遍歷對比。每乙個join都要做一輪這樣的運算。如果資料量相對於記憶體並不是很大，可以事先全部載入到記憶體中，那...
效能優化技巧 部分預關聯
在 效能優化技巧 預關聯 中，我們測試了將資料表事先全部載入進記憶體並做好關聯後的查詢效能優化問題，但如果記憶體不夠大，不能將維表和事實表全部裝入，那怎麼辦呢？此時，可以將維表預先裝入記憶體，建好索引，實現維表部分的預關聯，省去一半hash計算。我們下面再來測試一下這種場景，這次用資料量最大 記憶體...
Oracle I O優化小技巧
重做日誌檔案與歸檔日誌檔案放到不同硬碟.資料檔案與重做日誌檔案放到不同硬碟.不同的重做日誌檔案 控制檔案 歸檔日誌檔案最好放到不同硬碟 控制檔案 重做日誌檔案放到高速硬碟。不行就放到同一硬碟高速區，即柱面號低的硬碟外部半圈。歸檔日誌可以放在低速硬碟或分割槽 單純增加硬碟大小不太管用。最好增加硬碟物理...