Re: [程式] as vs cast

看板C_Sharp (C#)作者 (.)時間9年前 (2015/12/02 14:07), 9年前編輯推噓1(105)
留言6則, 2人參與, 最新討論串2/2 (看更多)
※ 引述《iterator (rotareti)》之銘言: : 作者的程式以及測試數據, 顯示 as 比起 cast 要來得快. : 但, 我們也可以看到文章下方的留言, 2006 年有人指出在 .NET 2.0 上, : 可能因為微軟實作及最佳化不同, 所以 cast 又比 as 快. : 而後續也有數個留言提到這篇文章的結論有誤. : 那在 .NET Framework 到了 4.6 的 2015 年, 又是什麼狀況呢? 不知道你對這有興趣想討論的目的為何? 最快的方式就是實際跑出來怎樣就怎樣就可以了, 頂多再深入可以看看編譯出來中介碼看看差異... 說真的這種比速度的問題,因為個人需要,也做過類似測試, 影響到的包括執行為x86或是x64模式.RAM的速度.編譯器選項. 編譯器版本.執行環境可能都會有影響. 有時候你覺得先把結果算成TABLE,靠查表可能比較快, 結果查表就是比較慢,因為記憶體一次存取的時間甚至會慢於你直接重算一次.. 有時候你直覺X64應該會比傳統X86跑得比較快,但結果就是X64跑得比較慢, 有時候DEBUG模式下兩者速度差不少,一般正常執行模式加最佳化後,兩者又差不多, 一大堆有的沒的.... So?? StopWatch + loop 跑看看 結果怎樣就怎樣瞜 甚至為了加速考慮直接寫.net的IL Code,後來想想走火入魔了,也未必好到哪裡去.. 回歸到本質上,如果真在效率上有極端需求,不是就直接玩c/c++或是直接寫組語了嗎? 或是把重要費時的部分核心至少用c/c++寫成dll呼叫. .NET 你在這種編譯性質上的部分鑽牛尖,不然就乾脆鑽到IL層或是JIT議題上去, 不然怎樣鑽,一旦變成IL code都是黑盒子,且一旦搭配jit機制下去... 內部怎麼處理怎麼跑完全無從認識.... -- ※ 編輯: erspicu (60.248.56.181), 12/02/2015 14:12:48 ※ 編輯: erspicu (118.171.242.102), 12/02/2015 16:15:30

12/04 02:21, , 1F

12/04 02:22, , 2F
用WinDbg還是能一窺黑盒子最深處的assembly code,研究這
12/04 02:22, 2F

12/04 02:23, , 3F
可以更深入的比較差異。但由於JIT特性,同樣的執行檔,拿
12/04 02:23, 3F

12/04 02:24, , 4F
到別台電腦執行,實際跑的asm code可能不一樣
12/04 02:24, 4F
讓我想到 微軟在VS 2015有C#.NET的Native編譯功能.....真正c#語法, 但接近Native或是Native效能,不過只能綁定在universal專案用... 其實我覺得微軟若有心要做,把c#變成native編譯本來技術上就滿可行的... 畢竟都搞出了JIT了...可能是啥商業上的策略吧... ※ 編輯: erspicu (118.171.244.172), 12/04/2015 16:52:55

12/05 13:22, , 5F
直接編成 native code 在維護上就不可行, 太多平台了
12/05 13:22, 5F

12/05 13:23, , 6F
技術上可行但人力可不是無限啊
12/05 13:23, 6F
文章代碼(AID): #1MNeg9vi (C_Sharp)
討論串 (同標題文章)
本文引述了以下文章的的內容:
1
21
完整討論串 (本文為第 2 之 2 篇):
1
21
文章代碼(AID): #1MNeg9vi (C_Sharp)