隆乳

全排列 Permutation (2) VC++出場!說到C果然就是指標! 文字的全排列 C# vs VB.NET vs C++後，C系列語言的大戰挑起了我的興趣這次參賽者加入了VC++，版本為Microsoft Visual C++ 2008使用Win32 Console介面。程式碼請參考文字的全排列 (VC++)另外在此修正之前文字的全排列 (Dev-C++)中的bug，算是優化效能。由於C++在配置記憶體時 ( Ans = new char[n])，並不會初始化，所以我在建立陣列後使用了memset把陣列Ans全部歸零一次才使用。但這其實是不需要的，且Ans大小並不小 (使用11個字作全排列時，Ans佔用空間大約500MB)，即使memset效率比逐一寫入高，但仍然會拖慢整體效能。為什麼說不必要？因為在全排列的情況下，Ans的所有空間必定會被填滿，在每次寫入答案時加入字串終點'\0'即可。測試條件同說到C果然就是指標! 文字的全排列 C# vs VB.NET vs C++1.參賽者均以編譯後執行個體(.exe)進行比試，而非除錯模式。2.統一輸入字 串"ABCDEFGHIJK"，長度11。由於是單位元組字元，可選用byte來存放結果。3.程式內需附有PrintAll的指令以供輸出結 果，在戰鬥前輸入字串"ABCD"驗證。但戰鬥時不用輸出，僅需輸出結果組數以供簡單驗證。4.整個演算法5次迴圈為一次戰鬥，並統計平均花費時 間。5.清理場地(重新開機)後馬上進行第一位的表演，表演完畢記錄數據後再次清理場地，才輪到第二位。以下測試環境有三，數據直接建表而不附上每次的擷圖了：1.XP 3200 (2.2Ghz)Windows XP SP3 32-bit VB.NETC#VC++Dev-CDev-C++ 遞迴檢驗法88418266481285477250 遞迴檢驗法 比例100%107%184%103%122% 字串循環法 154901488179720622218 字串循環法 255311702184422662422 字串循環法 355371735185922812422 字串循環法 455091737184422822422 字串循環法 555271738185922652422 字串循環法 平均5518.816801840.62231.22381.2 字串循環法 比例100%329%300%247%232% 名次51234演算法效能比160.20%492.02%261.44%383.07%304.47% 2.Atom 230 (1.6Ghz)Windows 7 64-bit VB.NETC#VC++Dev-CDev-C++ 遞迴檢驗法207571970593291399311560 遞迴檢驗法 比例100%105%222%148%180% 字串循環法 1132702950627159757035 字串循環法 2134262924631859906895 字串循環法 3134713003633460227052 字串循環法 414014300263345990# 字串循環法 513559300063026022# 字串循環法 平均135482975.86311.85999.86994 字串循環法 比例100%455%215%226%194% 名次51324演算法效能比153.21%662.17%147.80%233.22%165.28% 3.PIII 667MhzWindows XP SP3 32-bit由於記憶體不足，只做10個字的全排列。  VB.NETC#VC++Dev-CDev-C++ 遞迴檢驗法26312600155220131772 遞迴檢驗法 比例100%101%170%131%148% 字串循環法 11629581491881962 字串循環法 21621583541912981 字串循環法 316946085619411011 字串循環法 416226045719411012 字串循環法 516026175609321021 字串循環法 平均1633.6598.6544.8921.4997.4 字串循環法 比例100%273%300%177%164% 名次52134演算法效能比161.06%434.35%284.88%218.47%177.66% 在指標的戰鬥中，VB淪落到成為其他C語系比試中比對的標準...A.遞迴檢驗法傳統的C與C++完全把需要CLR的VB與C#壓著打。而VB與C#在伯仲之間。尤其是VC++，表現非常突出，無論在哪個平台上都能拔得頭籌。而Dev-C與C++之間，則全數由Dev-C++勝出。B.字串循環法讓人驚奇的！在這個案例中，C#的指標在所有平台都有極佳的表現。尤其是在64bit平台，使用CLR的C#直接無視32bit與64bit的轉換，硬是把唯一的對手：Win32的VC++壓得死死，直接取得了VC++兩倍以上的成績！但VC++也不是省油的燈，由於執行成本較低，馬上就在中古電腦PIII 667上扳回一城。低執行成本且不用執行階段編譯轉換的結果，使得VC++在比較舊型、記憶體較少的P3上全數勝利。至於Dev-C與C++這對兄弟之間，剛好與遞迴檢驗法中相反，全數由Dev-C勝出。另外可以再證實：演算法影響效能甚鉅！表現最差的VB也有50%的提升。而C#更恐怖...因為一個有用指標一個沒用，導致有約500%的差別。令人感慨的是，VC++即使使用效率較差的遞迴檢驗法，一樣贏使用字串循環法的VB，C#如果不使用指標也是類似的結果。可以得到很無聊的結論：重視效能的話，首重演算法，想法對了在哪個平台都可以有很大的進步空間。但選擇平台與編譯環境也很重要，以此案例來說，VC++的表現很不錯。C#...還不能馬上下定論，實在是搞不懂他，看來還需要更多的測試。但可確定的是，如果程式容易指標化，C#使用指標可以提升許多效能！如果以後有類似的題目可供測試，我會再拿出來玩的。 .msgcontent .wsharing ul li { text-indent: 0; } 分享 Facebook Plurk YAHOO! .