※ 引述《tinlans.bbs@whshs.cs.nccu.edu.tw (汀)》之銘言：
: ※ 引述《freaky.bbs@ptt.cc (jon)》之銘言：
: 大都是 programming 技巧的影響性較大。
: 至於 garbage collection 並非直譯式程式的專利，
: 編譯式程式也能靠 library 實現它而不需要靠 VM，
: 一樣能針對實際的執行環境做最佳化。
.net 程式並不是直譯式程式，而是被編譯了兩次經過兩次最佳化的程式。
至於 Java 剛出來的時候是用 VM 直譯 bytecode, 現在也多半是用編譯的了。
: Java 那個 server mode 的跑法似乎很容易讓程式 fail 掉，
: 可能是我不會下參數吧，
: 它只要狂 allocate memory 到上限程式就會結束了，
: NET 的話我是不清楚。
你有興趣試 .net 的話可以討論一下，因為 Java 我也不懂。
: 指定 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 下來完全一樣快或是更差。
傳統 compiler 能做的最佳化 managed compiler 也能做，而且是分兩階段
在有更充分資訊的情況下做，你可以去試試 C++/CLI。.net 的 managed heap
只有在 pinned pointer 正指向一塊記憶體，而開始進行 garbage collection
時才會產生 heap fragmentation，所以一般情況下存取 managed heap 是比
unmanaged heap 來得有效率。即使架構上造成了一些 penalty，也有一些
設計特性超越傳統程式的地方，因此 managed 程式的效能並非完全不可能
比傳統程式好。
: 很多商業廣告拿出來的 benchmark 有以下特性：
: 1. 不是實際上大家在使用的完整程式
: 2. 比較單一語言機制，忽略在 programming 技巧限制上的差異
: 3. 刻意把另一邊的程式寫爛
: 4. 最佳化參數故意隨便亂下
: 仔細注意一下就可以簡單的破解了，
: 以前 Java 出來的時候就破掉不少騙人的 benchmark 程式，
.net 支援很多種語言，你可以挑你喜歡的寫，例如 C++ versus C++/CLI。
: NET 則是從它出來到現在這段時間我比較忙沒去實驗，
: 但是看起來都是差不多的手法。
那等你有空去實驗看看再討論比較有意義。
--
※ Origin: 臺大電機 Maxwell 站 ◆ From: 60-248-105-82.HINET-IP.hinet.net