※ 引述《freaky@bbs.ee.ntu.edu.tw (jon)》之銘言：
> .net 程式並不是直譯式程式，而是被編譯了兩次經過兩次最佳化的程式。
> 至於 Java 剛出來的時候是用 VM 直譯 bytecode, 現在也多半是用編譯的了。
這個我自己在前面的文章就有說過了喔，
上篇之所以直接指名直譯，
是指後半段的直譯執行部分。
另外 MS 的 .NET 我是在 beta 的時候用過它的 C#，
其實也已經建立了不少概念，
倒不至於完全不懂，
所以對 .NET 初學者的說明倒是可以省下來。
我不清楚的其實只有它 CLR 的設定方法和微調方式，
以及詳盡的實作細節。
> : 指定 CPU 型號分別編譯，
> : 然後只釋出 binary 檔依然是可行的，
> : 要不就是現在比較常見的方式：讓關鍵部分的 DLL 檔可抽換，
> : 讓 user 選擇 SSE、SSE2、SSE3 等不同版本進行下載或直接從 CD 安裝，
> : 當然這也是只有講 CPU 的部分。
> 這些都需要使用者有相當的知識，我覺得不是很實際。
我想使用者至少會知道自己的 CPU 是什麼，
就算不知道的話也能寫個小程式替使用者判斷。
> 傳統 compiler 能做的最佳化 managed compiler 也能做，而且是分兩階段
> 在有更充分資訊的情況下做，你可以去試試 C++/CLI。.net 的 managed heap
可以做，但是沒辦法全部做，也沒辦法做到很完美，
不是不可以而是不能，
其實現在傳統的 compiler 在 machine-dependent 的部分耗費最多編譯時間，
如果一個傳統 compiler 在最佳化選項全開的情況下需要編譯 5 分鐘的程式，
其中至少有 3.5 至 4 分鐘是在進行 machine-dependent 最佳化，
而把這 3.5 至 4 分鐘的時間平均分攤在執行期也是很大的開銷，
這就是可以做但是不能做的原因。
何況 JIT compiler 並不是把編譯的結果完全保留下來直到程式結束，
是以某些 policies 把編譯過的 native code 暫時 cache 起來，
當運氣不是很好的時候還是會發生接近純直譯速度的狀況，
甚至更差。
> 只有在 pinned pointer 正指向一塊記憶體，而開始進行 garbage collection
> 時才會產生 heap fragmentation，所以一般情況下存取 managed heap 是比
> unmanaged heap 來得有效率。即使架構上造成了一些 penalty，也有一些
> 設計特性超越傳統程式的地方，因此 managed 程式的效能並非完全不可能
> 比傳統程式好。
這個部分如同之前我所說的是 library issue，
和傳統 compiler 的行為其實完全無關，
無論是 C 的 malloc()/free() 函式或是 C++ 的 new/delete operator，
實際對 heap 的操作行為都在於背後的 library 撰寫方式，
因此要製作一個類似 managed heap 的 library 並不困難，
一樣可以很高興的狂 malloc()/new 免用 free()/delete，
其它傳統語言的狀況我是不知道，
不過傳統的 C/C++ compiler 從不幫 user 管理 heap，
實際行為取決於 libc 和 libstdc++ 的實作內容，
高興的話也能直接選用別套 heap managing library，
因此這一點倒不至於成為 unmanaged heap 架構做不到的事。
--
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/07 19:23:10 <218-171-137-182.dynamic.hinet.net>