[問題] run-time優化使用metaprogram

看板C_and_CPP作者 (幽影藏原)時間13年前 (2010/10/08 20:45), 編輯推噓9(9推 0噓 37→)
留言46則, 6人參與, 最新討論串1/1
( *[1m *[m 為色碼，可以按 Ctrl+V 預覽會顯示的顏色 ) ( 未必需要依照此格式，文章條理清楚即可 ) 遇到的問題： (題意請描述清楚) 各位先進, 請問一下, 如果用連結內的方法來計算0+1+...+100的和, 算不算是run-time優化 ? 會問這個問題是對run-time優化的定義很模糊 謝謝 開發平台： (例: VC++ or gcc/g++ or Dev-C++, Windows or Linux) g++, Windows 有問題的code： (請善用置底文標色功能) http://nopaste.info/d54cb08f83.html -- 佐助：你跟大蛇丸是什麼關係？ 紅豆：老師的舌頭好勵害哦>///< 櫻：佐助…為什麼要離開木葉？ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.41.160.165
推
10/08 21:12, , 1F
定義，有變比較快就是優(氧)化
10/08 21:12, 1F
→
10/08 21:27, , 2F
但這是 compile time 耶..
10/08 21:27, 2F
→
10/08 21:28, , 3F
感覺是不同世界的人...使用模版引數推導/展開, 除了一
10/08 21:28, 3F
→
10/08 21:29, , 4F
些特別的技術真的能夠加快執行時間, 不過以你的程式碼
10/08 21:29, 4F
→
10/08 21:29, , 5F
頂多就只是把執行時間提前罷了
10/08 21:29, 5F
推
10/08 21:38, , 6F
我錯了，原PO這應該改叫 compiler time 弱化，因為變慢了
10/08 21:38, 6F
→
10/08 21:38, , 7F
多打了r
10/08 21:38, 7F
→
10/09 08:57, , 8F
purpose, 為什麼會變慢 @@?
10/09 08:57, 8F
推
10/09 09:05, , 9F
我把這裡的compile time解釋成，編譯所需要花得時間
10/09 09:05, 9F
→
10/09 09:58, , 10F
對不起這麼晚回應, 我就是和我的同學有這方面的爭議
10/09 09:58, 10F
→
10/09 09:59, , 11F
他認為這樣就是優化執行時間, 而原本的問題是1加到100的
10/09 09:59, 11F
→
10/09 10:01, , 12F
迴圈, 不能用公式和直接填5050的情況下, 要求加速
10/09 10:01, 12F
→
10/09 10:05, , 13F
我個人是認為不算, 因為把原本run-time的工作拿掉, 變成
10/09 10:05, 13F
→
10/09 10:06, , 14F
在run-time前就算出答案了, 已經不關run-time的事了
10/09 10:06, 14F
→
10/09 10:07, , 15F
何來的run-time優化? 但是又對run-time優化的定義不是很
10/09 10:07, 15F
→
10/09 10:08, , 16F
清楚, 所以想詢問其他人的看法, 謝謝
10/09 10:08, 16F
推
10/09 10:10, , 17F
我覺得最佳化的purpose，就只是嫌原本程式效能不好要改進
10/09 10:10, 17F
→
10/09 10:10, , 18F
如此而已。不是為了要達到哪種XXX最佳化而去做最佳化
10/09 10:10, 18F
→
10/09 10:11, , 19F
像法律人一樣字字斟酌。當然如果是寫文章要嚴謹就例外...
10/09 10:11, 19F
推
10/09 10:15, , 20F
補充一下，這種題目硬是要求不用公式去算，本身就怪到爆
10/09 10:15, 20F
→
10/09 10:18, , 21F
沒辦法, 不知道哪來的題目...以目的來說, 這樣算優化了
10/09 10:18, 21F
→
10/09 10:19, , 22F
感謝你的幫助 ^_^
10/09 10:19, 22F
推
10/09 10:47, , 23F
最佳化的purpose大..0.0
10/09 10:47, 23F
→
10/09 10:48, , 24F
不是不關runtime time的事, 如果硬要把編譯時間計算的
10/09 10:48, 24F
→
10/09 10:49, , 25F
那一部分放進去, 其實根本沒有優化
10/09 10:49, 25F
推
10/09 10:50, , 26F
我提一個爛方法，印象中很常被用，就是空間換取時間
10/09 10:50, 26F
→
10/09 10:50, , 27F
而且既然是編譯時期就能得到的值把它寫死在code裡, 跟
10/09 10:50, 27F
→
10/09 10:51, , 28F
把部份答案存起來，run time 時再提出來用，比如 1+..+50
10/09 10:51, 28F
→
10/09 10:51, , 29F
動態去取得1+ ...+ n這裡的n, 兩種程式的效率根本不
10/09 10:51, 29F
→
10/09 10:51, , 30F
這就要是虛擬機器、直譯器在跑的
10/09 10:51, 30F
→
10/09 10:51, , 31F
能比較, 因為架構不一樣
10/09 10:51, 31F
推
10/09 11:05, , 32F
剛舉例不太清楚，重舉。Run-time最佳化的方法，比如很多
10/09 11:05, 32F
→
10/09 11:06, , 33F
個Java程式，都會在執行時由使用者輸入參數到某遞迴函數去
10/09 11:06, 33F
→
10/09 11:06, , 34F
Java就可以用空間換取時間，把某個參數記下來，比如6
10/09 11:06, 34F
→
10/09 11:06, , 35F
下次另外一個程式要算7時，就用6的結果去多一點點運算就好
10/09 11:06, 35F
→
10/09 11:07, , 36F
那因為C++是編譯完寫死，應該就不能用這種run-time最佳化
10/09 11:07, 36F
推
10/09 17:44, , 37F
現在有一些在off-line時期就已經建好某些table
10/09 17:44, 37F
→
10/09 17:45, , 38F
然後在on-line的時候可以節省很多時間，而且還可以
10/09 17:45, 38F
→
10/09 17:46, , 39F
得到更好結果的approach，其實理念上是類似的
10/09 17:46, 39F
→
10/09 17:48, , 40F
不過跟原PO所說的差別在於，這些approach利用固定增加
10/09 17:48, 40F
→
10/09 17:48, , 41F
的compile time，卻可以隨著input的不同，省下大量的
10/09 17:48, 41F
→
10/09 17:49, , 42F
runtime，效果上也有所差異
10/09 17:49, 42F
→
10/09 17:50, , 43F
根據領域的不同，找得出某些好方法，可能就是一篇不錯
10/09 17:50, 43F
→
10/09 17:50, , 44F
的paper
10/09 17:50, 44F
→
10/09 17:51, , 45F
我自己是認為...如果不管input，總時間還是一樣
10/09 17:51, 45F
→
10/09 17:51, , 46F
那就沒什麼用了
10/09 17:51, 46F
‣ 更多 BILLBADY 的文章
文章代碼(AID): #1Chn9j37 (C_and_CPP)