※ 引述《freaky.bbs@ptt.cc (jon)》之銘言：
> 最佳化不是只牽涉到 CPU, 還有執行用戶端的記憶體大小等等，針對成千上萬
> 的潛在用戶端環境最佳化對傳統編譯程式而言是不切實際的，總不能要求
> 所有軟體都放 source code 出來讓用戶自己 compile 吧？
其實僅針對 CPU 做的最佳化已經足以造成實際執行速度上的明顯差異，
至於和 memory size 相關的最佳化，
除了狂暴性的把 code 展開以外其實也沒有其它有利的部分，
大都是 programming 技巧的影響性較大。
至於 garbage collection 並非直譯式程式的專利，
編譯式程式也能靠 library 實現它而不需要靠 VM，
一樣能針對實際的執行環境做最佳化。
Java 那個 server mode 的跑法似乎很容易讓程式 fail 掉，
可能是我不會下參數吧，
它只要狂 allocate memory 到上限程式就會結束了，
NET 的話我是不清楚。
指定 CPU 型號分別編譯，
然後只釋出 binary 檔依然是可行的，
要不就是現在比較常見的方式：讓關鍵部分的 DLL 檔可抽換，
讓 user 選擇 SSE、SSE2、SSE3 等不同版本進行下載或直接從 CD 安裝，
當然這也是只有講 CPU 的部分。
> 再說有些最佳化是傳統的 compiler 無法做的，例如某些常用函式的 inline。
> 在編譯傳統程式時不像在 managed 環境中，compiler 無從預知 code path，
> 自然不能實現這方面的最佳化。
雖然無從預知 path，
但有兩種已經廣泛應用的方式：
1. 猜
2. 用 profiling 出來的 data 當 input 做最佳化
至於 inline 的話，
動態 inline 的確是傳統的方式做不到，
但也能透過事先 profiling 得知，
而做出適當的最佳化，
更何況動態 inline 並不是沒有代價的，
背後要做的事也不單純只是 copy code 這麼簡單而已，
而這些 overhead 可都是算在 execution time 上。
其實傳統 compiler 做不到的部分，
都有相當近似的實作方式可以實現，
雖然不是 100% 準確，
卻也有相當不錯的效果。
在大多數的最佳化還是贏很多的情況下，
小輸幾個地方並不會造成整個真實可用的程式 run 下來完全一樣快或是更差。
很多商業廣告拿出來的 benchmark 有以下特性：
1. 不是實際上大家在使用的完整程式
2. 比較單一語言機制，忽略在 programming 技巧限制上的差異
3. 刻意把另一邊的程式寫爛
4. 最佳化參數故意隨便亂下
仔細注意一下就可以簡單的破解了，
以前 Java 出來的時候就破掉不少騙人的 benchmark 程式，
NET 則是從它出來到現在這段時間我比較忙沒去實驗，
但是看起來都是差不多的手法。
--
Name: Tseng, Ling-hua E-mail Address: uranus@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝ ╰ ＊ From：218-171-137-182.dynamic.hinet.net
─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎
--
* Modify: tinlans 06/03/06 19:11:34 <218-171-137-182.dynamic.hinet.net>