2015年10月18日 星期日

C# 效能感想

會嘗試使用C#撰寫模擬器,有很多因素,

一方面這是我工作主要使用的語言,

二方面想看看 C# 是否能勝任模擬器的工作,

三方面是希望撰寫出方便教學與理解.移植的程式,不像C/C++很多地方與OS.硬體特性.函式庫有關係上的相連,如果移植有些地方都要花心思磨合一下,這也就是為何我盡量以.NET C#原生官方的資源為主,而沒使用到像是DirectX之類的第三方原件或是直接call win32 api等等做法(不過遊戲搖桿讀取有用到sharpdx,內部是包directx利用的).

這樣搞一搞之後,以現在普通的電腦來說,如果程式寫得還算適當,並且避開某些地雷寫法(C#某些物件導向的高階元件千萬別用,一切用最簡單的方式去做),然後在處理畫面部分,直接用指標去做處理(C#的BitMap物件很慘...一定得用指標直接去讀寫pixel value),整體跑起來其實也沒啥問題 (比較早期的2D遊戲主機,像是GB.GBC.FC.SFC.GBA等等之類的....) , 但這就僅止於跑起來ok而以,如果再加上像是畫面用filter倍率放大,一套用上比較複雜的演算法下去,fps馬上掉到60fps內,甚至一半都不到....

也就是說c# ok ,但僅止於ok而以.

如果真的要求完善完美,不然就是得call native,不然就是得借用dirextx wRapper直接使用硬體加速(GDI真的不適合當成動態畫面播放的媒介,特別是圖片大張時候,記憶體量一大,整個顯示速度就死翹翹),而放大即時的filter運算,c#也很不夠力....

所以c# ok ,但求完美部分關鍵得借用d2d.win32 api或是直接call c method去處理,有沒有發現一個問題? 如果這樣做,那不就跟當初理念違背? 如果跟os.硬體綁上,用c.c++不是更快? 恩...這的確就是一個矛盾的地方.

最後歸納起來,會用c#的原因,大概就最主要是funny和熟悉吧....

如果一開始追求一個寬裕的效能,而不僅止於ok的話,c/c++會是更好的選擇,前提是你熟習它們.

目前效能障礙在

1.real time image filter (如果是hq2x這套,光2x就死翹翹....)
2.bitmap投影速度 (GDI圖越大張,速度越慢)

有些c/c++的專案還會用組語更進階加速.

沒有留言:

張貼留言