※ 引述《invalid (everlasting)》之銘言： : ※ 引述《gwliao (gwliao)》之銘言： : : 這是算一次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更能夠帶來巨大的效益啊 資訊產業剛開始的時候 那時候也沒有專門的程式設計師 程式大多是數學家在寫的東西 現在漸漸變成顯學 分工也越來越細 什麼職稱都出來了 但是最終的目的還是開發效率 剛開始在硬體上講究 後來把頭腦動在人身上 每次軟體商一個新名詞新技術出來 大家總是追的如癡如醉 但是講到最後還是 就像李開復講的一樣 核心應該注重於演算法 其他的部分可以用開發速度較快的語言編寫 這樣搭比較smart --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.218.161.130