※ 引述《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 偵測到，
再加上先天性的執行速度差異，
是很難真的撈到什麼好處的。
--
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/05 21:09:02 <218-171-137-182.dynamic.hinet.net>