※ 引述《tinlans.bbs@whshs.cs.nccu.edu.tw (汀)》之銘言：
: ※ 引述《freaky@bbs.ee.ntu.edu.tw (jon)》之銘言：
: > .net 程式並不是直譯式程式，而是被編譯了兩次經過兩次最佳化的程式。
: > 至於 Java 剛出來的時候是用 VM 直譯 bytecode, 現在也多半是用編譯的了。
: 這個我自己在前面的文章就有說過了喔，
: 上篇之所以直接指名直譯，
: 是指後半段的直譯執行部分。
那我也說了後半段不是直譯的。
: > 傳統 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 起來，
: 當運氣不是很好的時候還是會發生接近純直譯速度的狀況，
: 甚至更差。
所以你的論點是比較的時候只有 unmanaged code 是微調到最佳化的情況，
managed code 就不能在最佳情況下嗎？前面也提了 .net 有 NGen.exe
(Native Image Generator) 可以在 deployment 的時候做，就沒有什麼
每次執行碰運氣的問題，但實際使用上未必每次都會比讓 CLR 自行調整的
的效能好。C# 的 source compiler 有一些最佳化沒做，所以請你去使用
C++/CLI，如果你願意嘗試再討論吧。
: > 只有在 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 架構做不到的事。
C++ 的確可以自行撰寫 custom allocator 來配置記憶體，不過又回到老問題了，
unmanaged code 什麼事都可以做，要寫出一個不會有 heap fragmentation
的 allocator 是有實際上的困難的，最佳化也是，對於無從預測的行為要如何
最佳化？
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 203.70.36.38