※ 引述《tinlans.bbs@whshs.cs.nccu.edu.tw (汀)》之銘言：
: ※ 引述《freaky.bbs@ptt.cc (jon)》之銘言：
: > 所以你的論點是比較的時候只有 unmanaged code 是微調到最佳化的情況，
: > managed code 就不能在最佳情況下嗎？前面也提了 .net 有 NGen.exe
: > (Native Image Generator) 可以在 deployment 的時候做，就沒有什麼
: > 每次執行碰運氣的問題，但實際使用上未必每次都會比讓 CLR 自行調整的
: > 的效能好。C# 的 source compiler 有一些最佳化沒做，所以請你去使用
: > C++/CLI，如果你願意嘗試再討論吧。
: 我倒是覺得 NGen 對 .NET 來說是一把雙面刃，
: 不要忘記 .NET 程式經過 NGen 處理過以後，
: 傳統 compiler 沒辦法在 runtime 做到的即時最佳化，
: 也會變得無法進行了，
: 因為它算是一種 Pre-JIT 的做法，
我前面就說了 NGENed 的程式未必效能會比 JITted 好，提 NGen 只是要指出
如果想減少程式載入的時間可以用 NGen 來達成。另外新版 (2.0) 的 NGen
不論在功能或效能上都有大幅度的改進，例如加入了 asynchronous NGen，
可以 NGen 整個程式而非只能針對單一的 assembly，新版 NGen 過的 native
image 在不同的 application domain 中可以共享，而 dependencies 的變更
不再會 invalidate NGen 過的 native image，也就不會導致必須採用 JIT
編譯。
: 而且就我的印象中，
: 使用 NGen 依然不能刪除原本帶有 IL 的程式，
: 這代表在執行時還是會有參考它的可能性，
: 不過這一點我並不是很確定。
關於這點回在另一篇。
: IL -> NGen -> native 還有一個致命的問題存在，
: IL 這種東西在設計上有兩種目的：
: 1. 為了進行更多最佳化而設計
: 2. 為了方便執行而設計
: 我接觸 C# 的期間有小小研究過 .NET 的 IL，
: 它很顯然是屬於後者的，
.net 的 IL 主要是為了各種高階語言間的 interoperability 而設計的。
: 而傳統 compiler 能夠設計多層次的 IL，
: 將那些對最佳化有利的高階資訊（接近原始程式語言的資訊）保留下來，
: 近期很多 compiler 的產品都會有 back-end 往 front-end/middle-end 的 upcall，
: 原因也是在此，
: 而 .NET 的 IL 和 Java 的 bytecode 都不具備這種特性，
: 因此透過 NGen 所能做到的最佳化相當有限。
.net JIT compiler 和傳統 compiler 做的事幾乎沒什麼差別：
1. Importing.
2. Morphing.
3. Flowgraph analysis.
4. Optimization phase.
5. Register allocation.
6. Code generation.
7. Emit.
沒有保留足夠的資訊也無法完成這些事情。
: 至於 C++/CLI 我應該是不可能主動去學它，
: 畢竟把 C++ syntax 惡搞成那樣讓我蠻反感的，
: 不過一旦有人丟出 C++/CLI v.s. 傳統 C++ 的 benchmark，
: 而且結果是 C++/CLI 比較好的時候，
: 我就會馬上去抓來實際測試看看。
Herb Sutter 最近寫了一篇關於 C++/CLI 的 paper，有興趣的話看看吧：
http://www.gotw.ca/publications/C++CLIRationale.pdf
: 就像我之前雖然不喜歡 Java，
: 但是一有人丟出 Java faster than C++ benchmark，
: 我還是會跑去破解它一樣。
As you like it.
: > C++ 的確可以自行撰寫 custom allocator 來配置記憶體，不過又回到老問題了，
: > unmanaged code 什麼事都可以做，要寫出一個不會有 heap fragmentation
: > 的 allocator 是有實際上的困難的，最佳化也是，對於無從預測的行為要如何
: > 最佳化？
: 雖然 unmanaged code 什麼事都可以做，
: 但是我們不能假設 programmer 都是笨蛋，
: 何況即使是在非 .NET 的環境，
: 一樣存在著所謂的 framework，
: 而在那套 framework 下所定義的遊戲規則，
: programmer 並不會任意的去違背它，
: 其實規模也不需要大到 framework，
: 只要選用的 memory allocator 訂出一套遊戲規則，
: 使用它的 programmer 本來就該遵守。
: 而 heap manager 這種東西在 unmanaged code 裡，
: 還可以由 programmer 視實際需求抽換，
: 所以這一點不但不是效能上的不利因素，
: 還是彈性上的有利因素。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 203.70.36.38