最近想要找點新的點子來優化之前看到的一些立體比對論文，我之前一直是用圖割做立體比對，剛開始時候用圖割做圖像分割，後來發現這塊都被人做爛了，繼續往下看發現圖割還能搞立體比對，效果也挺好。但是後面發現掉大坑裡面了。
1.什麼是好的research
這篇文章中寫到什麼是好的research？這篇文章中有講到（看到的有點晚了）
<a target="_blank" href="http://www.52cs.org/?p=632">http://www.52cs.org/?p=632</a>
創新性高，性能差：俗稱的“挖坑”的工作。這樣的工作包括提出一個全新的問題或者對一個已有問題的全新解法。這樣的工作雖然可能在文章中隻提出了非常簡單的baseline，或性能并不能比過最好的已有方法，但是可以啟發大量後續的research。
很顯然用圖割算法進行立體比對就屬于這種工作。
在沒有綜合對比其他全局優化算法，或者辦全局優化算法的時候，我就貿然繼續采用圖割算法進行立體比對的工作，僅僅是因為之前看了圖割算法，這不能不說是碩士階段方向性選擇的一大失誤。
2.科研方向的選擇（對于研究所學生而言盡量選擇一個點）
而我因為不懂科研方向的選擇在圖割算法立體比對上下去，現在想想，什麼是選擇在碩士階段科研題目的正确方法呢？我覺的對于一般院校的學生來說，應該是一些在小處上能夠改進的題目，比如圖像分割，人臉表情識别，深度圖像增強這種有成熟架構可以替換算法實質内容，又實驗友善的科目。
比如講圖像分割，用聚類算法進行分割，模糊k均值，或者引入圖論的相關算法多做些實驗，國内的核心期刊還是很好水的。
而對于立體比對這種偏系統性工程性科研題目。而且在沒有師兄師姐代碼或者理論基礎的情況下，光是自己找代碼，自己找例程就
非常耗費時間。
3.有關圖形圖像領域的萬金油灌水（串行改并行）
圖形圖像處理在國内國際有一個萬金油灌水領域，其實也可以說是一個偷懶的領域，就是将傳統算法并行化處理，下面說說我的思路。如何找到并識别并行的機會呢。最好的方法是用代碼性能分析工具分析代碼，對cpu占用率較高的部分單獨拉出來來。代碼分析可以在windows下面用amd的codexl，直接對應exe就能分析出來代碼所在的瓶頸。或者用visual studio自帶的analysis，或者linux下面免費的oprofile
比如下圖我随便找了一個立體比對的程式在codexl中跑過一遍後下面是分析的結果：可以看到熱點函數和代碼都給找出來了。這就是我們通常說的：
性能分析引導優化（profile-guided optimization）
看到程式27%的時間卡在了一個内聯函數的直方圖相加上。
可以直接下載下傳一個Intel parallel studio XE 2016之後在vs2010中打開tools運作優化選項，說明文檔：
<a target="_blank">file:///C:/Program%20Files%20(x86)/IntelSWTools/documentation_2016/en/compiler_c/ps2016/get_started_wc.htm</a>
采用intel 編譯器的優化，intel編譯器安裝好之後在windows下有兩種運作方式，一種是指令行，一種是作為visual studio 2010的一個插件工具：
運作時候需要根據并行優化向導進行一步步配置優化，這基本也算是傻瓜式的優化，其實主要能用到的就是兩部分，編譯優化和，分析引導優化：
注意到開啟不同選項，其優化時間是不同的，甚至更慢：
尋找并行化的機會之二：
檢查應用程式中的關鍵路徑。關鍵路徑是确定任務可以在最短時間内完成的一組步驟。下圖中顯然任務c可以和任務a和b并行。
要點：
除非應用程式用于可并行化代碼的時間超過其運作時間的一半，否則其可擴充性有限。我們用profile分析的時候，程式熱點代碼運作時間在25%-30%以上才有明顯的優化效果。
真正能夠縮短的運作時間，amdahl定律：
參考文獻：
戈夫. 多核應用程式設計實戰[M]. 人民郵電出版社, 2013.