推 micklin:推! 09/19 23:39
※ 引述《gwliao (gwliao)》之銘言：
: ※ 引述《micklin (Mick@Tucson)》之銘言：
: : 當然我是假設不用元件或套件或函式庫, 要自己寫的時候。
: 這是算一次Cost/Fitness value的時間.
: 假如能減少number of iterations的話, Total running time應該會減少.
: 不知你是用別人的Solver還是自己寫?
: 假如是自己寫話, 可以想想產生Next generation的方法.
: 用Solver的話, 那要試試能調的參數.
: : 其實我一開始想知道的就是, 能不能在寫程式前就知道這樣寫有沒有意義?
: : 有專門的書或文章在探討這一類的問題嗎?
: : 或者板友們有可以分享的心得嗎?
: 有啊, 讀多一點書和寫多一點程式.
: 可以未寫程式前, 先猜這有沒有意義.
我覺得在演算法的層次上
在寫之前本來就可以根據演算法本身的time/size complexity
來選擇，如果是自己想的演算法
最好是自己推一下complexity (數學要夠好XD)
這樣才算是真正的設計演算法
必竟實作後牽涉的因素太多，倒推回去有的時候不是很準
而之前討論的部份感覺起來其實滿接近實作的範圍
遞迴與迴圈的比較，相信以看的懂組語的人來說根本就不是問題
而某些rule of thumb的確是可以在profile前提升效能
譬如針對cpu cache或是software pipeline的常識
或是陣列宣告等的小技巧
不過絕大多數的最佳化技巧，可能在某個平台上相當適合
而到另一個平台上就可能因為核心架構的不同而變成累贅
所以大部份的最佳化都會強烈建議等到profile後再進行
不然有可能是事倍功半
書的話比較少，畢竟演算法上的改良才是最有效的
實作上的技巧也會隨硬體演進變化，沒有太多不變的真理
在沒有pipeline上的cpu玩software pipeline就一點用都沒有
比起這個，良好的coding style更能夠帶來巨大的效益啊
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.62.22.95
※ 編輯: invalid 來自: 61.62.22.95 (09/19 16:37)