最佳化不是只牽涉到 CPU, 還有執行用戶端的記憶體大小等等，針對成千上萬
的潛在用戶端環境最佳化對傳統編譯程式而言是不切實際的，總不能要求
所有軟體都放 source code 出來讓用戶自己 compile 吧？
再說有些最佳化是傳統的 compiler 無法做的，例如某些常用函式的 inline。
在編譯傳統程式時不像在 managed 環境中，compiler 無從預知 code path，
自然不能實現這方面的最佳化。
※ 引述《tinlans.bbs@whshs.cs.nccu.edu.tw (汀)》之銘言：
: ※ 引述《freaky.bbs@ptt.cc (jon)》之銘言：
: > Managed application 在某些情況下會比 unmanaged application 有著更好
: > 的效能, 例如 JITter 可以針對各種不同的 CPU 做最佳化, CLR (Common
: > Language Runtime) 也會針對 code execution 產生 profile 而重新編譯
: > 某些 IL 來增加效能, 隨著 .net Framework (強調一下這是 Microsoft
: > 對 CLI Standard 的實作, 任何人都可以自由實作) 的演化, 應該會有更好的
: > 最佳化技巧.
: 這個比較方式其實有問題，
: 因為都是在「把編譯好的程式拿去不同平台 run」的前提下，
: 但是這個好處是混合編譯直譯的程式專屬的，
: 不能這麼高興的直接套到編譯式程式上面做比較。
: 我所指的「沒有完全相等或超越的機會」是在兩方都做到最好的前提下，
: 而不是其中一方以相容模式執行的情況下。
: 正如兩方所做的取捨，
: 編譯式的程式拿到不同 CPU 上執行最好要被重新 compile，
: 以 GCC 為例，
: 編譯 for x86 系列的程式可以使用 -mtune 選項，
: 指定 pentium、pentium-mmx、pentiumpro、...、k6、k6-2、...、prescott 等，
: VC++ 的話應該在某個地方有設定，
: 只是微調選項就沒有這麼豐富。
: 對純粹編譯式程式的作者而言，
: 如果他很懶又不打算 open source，
: 放出 binary 檔案時都會採用相容性最高的選項，
: 換句話說這捨棄了絕大多數的最佳化，
: 但這不是標準做法，
: 標準做法是針對不同 CPU 分別編譯一套執行檔和函式庫，
: 安裝時自動偵測或由使用者自行選擇 CPU 類型。
: 比較高竿的做法還有只針對效能瓶頸的地方提供不同版本，
: 把那個部分單獨抽成 dynamic library，
: 這樣就只需要針對這個部分提供不同的 dynamic library 檔即可。
: 至於 profiling based optimization，
: 其實編譯式程式還是有這種功能的，
: 先在測試版本加入產生 profiling result 檔的選項，
: 然後交給測試人員 run 一陣子，
: 編譯正式版的時候把 profiling 的結果餵給編譯器，
: 就能進行這種最佳化，
: 不過這種最佳化的確沒辦法按照 user 實際使用的情形即時重新調整，
: 但是把這種 profiling 功能做在 virtual machine 上也是有代價的，
: 在 runtime 轉換成 native code 然後依據某些機制 cache 起來，
: 結果又因為 profiling 後發現應該生成別的樣子比較好，
: 不時的重新部屬 native code 也是會耗費 CPU 時間，
: 當使用者真的很皮的時候那種 cache native code 的功能就形同虛設，
: 所以在 profiling based optimization 上兩者有好有壞，
: 做比較的時候不提也罷。
: 而且 JIT 能做這類最佳化的情形通常只發生在程式的小片段，
: 但是必須整個軟體的效能瓶頸恰巧落在那個小片段才能獲得改善，
: 就算真的是如此，
: 這種情況純粹編譯式的程式也大都能用 profiling base optimization 偵測到，
: 再加上先天性的執行速度差異，
: 是很難真的撈到什麼好處的。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.248.105.82