總是會好奇C#效率表現的最高點為何,特別像是video filter處理那塊的效率,因此做一些code的調整,零零星星的大原則處理完畢後,接著是一些比較偏向於編譯器那塊細節的部分,這麼說也不太正確,因為我還沒摸到編譯器內部處理本身,除非自己玩opensource,而是指修改一些code的寫法,盡量讓編譯器產生比較有效率的code....多數都是用stopwatch實際測試看看,平平兩種寫法,在運算吃重時候就是會有差異,但往往會覺得...奇怪? 並不是自己觀念中預料的方式會比較好,有時候自以為簡化運算或是優化,結果反來會有反效果,又x86.x64模式的不同 . .net framework版本不同 . 一般模是執行或debug模是執行 . 是否有開啟優化處理 ,都會有些不太一樣 , 於是整個優化的修改過程比較像是try error , 反正stopwatch數據哪個好就用那種方式去寫,有一種被黑盒子遮蔽住的感覺,特別像是 .net 或是 java 這種會產生中介碼的技術,除了如何產生中介碼本身是一個變數環節外,之後JIT階段如何執行又是一個變數,因此形成一種讓人難以捉摸的感覺,你不知道你的CODE會被編譯器編譯出怎樣的中介碼,然後你也不知道這些中介碼會如何被 JIT 詮釋..
因此得到的結論是,如果真的要掌握和控制,追到中介碼反組譯是不夠的,連 JIT 產生怎樣的Native Code都要下去看看,才知道到底怎麼回事.....
目前是沒摸到這塊,也許以後興致來了再看看吧.
不過想起來很妙,人類傾向將底層的技術包裝起來變成越高階抽象方便的工具 ( ASM -> C -> C++ -> C# ) , 但用了方便的高階工具後又因為想掌握細節和自由,所以從高階抽象的那一層鑽研回底層低階的那塊 .
沒有留言:
張貼留言