為什麼多一個空的檔案（只 #inlcude
為了多工，徹底壓榨 CPU ，所以有些程式需要用到 openmp ，來達成平行化的效果。不過用了之後，神奇的事是層出不窮啊。快！當然是比較快，不過很奇怪，在 M$ Visual Studio 2005 上跑的都很符合預期，一換到 FreeBSD 後 (gcc 4.2.1），竟然跑的特別久，比 single thread 還慢，是該說 FreeBSD 有先做 SMP 最佳化嗎？ :p
這倒不是重點，重點是最近困擾我許久的問題。大家都知道 code refactoring 是吾輩師程工或是生士博所不可不備的練習，就像是每天都要運動一樣。所以當實驗室來了個壓榨 CPU 效能的奇才工讀生，我就把年久失修的程式搬出來啦。工讀生動作很快，沒幾天就改好了，在四核的電腦上執行快 35% 。啊我在這其中，也開始做這份程式的 code refactoring ，結果就在我把一些不該在某些地方的程式想獨立出來。 Boom！！（有沒有 CSI:NY 的 Danny fu 呀？ 
）竟然慢了 20% ！！！
正所謂「由簡入奢易，由奢入簡難」，要是當初一開始就看到這個結果，在 35% – 20% > 0 的情況下，我也是會豎起大姆指說：「openmp 就甘心咧」
試到最後，發現原來的程式跑的很好，但只要我一加入新檔，然後該檔 #include 個大一點的 header file （像 time.h 這小咖就沒差啦）如
我想說會不會是因為 M$ Visual Studio 2005 只有支援到 openmp 2.0 ，也許有點問題。啊換到 M$ Visual Studio 2008 也是 openmp 2.0 ，不過也許會好一點？
結果，真好，一開始就跟我在 VS2005 加了一個檔的效果一樣，慢了 20% 。
然後我就不知道該怎麼寫下去了…. 難不成又要回頭去用 MPICH 嗎？
結果是 boost library 惹的禍…..
how did you fix that ?
re-write code which involves boost lib