這里我選擇運行計算復雜度較高的算法作為測試方法，雖然不能代表全部，但 是很大程度上展示大家平時開發過程中所面臨的常見場景 和問題。考慮到演示和 理解，就選擇了查找100000以內的所有素數的個數的算法作為演示。另外也順帶演 示如何在WinRT下實現多編程語言和技 術之間的協作吧。

關于基本知識和算法吧詳細的說明，請自行搜索各大引擎吧（關鍵 詞：prime、素數），這里我就列舉在各個語言下我的簡單實現吧，其中包括使用 普通算法和并 行計算的兩個版本。

***部分，從目前.NET主流來看吧，以C# 為例，普通版本，這個沒什么多說的，就是從前往后看某個數是不是素數：

private static int 
CountingInternal(int n) 
{ 
     var numprimes = 1; 
     for (var i = 3; i <= n; i += 2) 
     { 
         var isPrime = true; 
         var limit = Math.Ceiling(Math.Sqrt(i)) + 1; 
         for (var j = 3; j < limit; j += 2) 
         { 
             if (i%j == 0) 
             { 
                 isPrime = false; 
                 break; 
             } 
         } 
         if (isPrime) 
         { 
             numprimes++; 
         } 
     } 
     return numprimes; 
} 

并行版本稍微復雜一點點，選擇Parallel.For來并行執行一個從1至n/2的并行 循環（我這里偷懶了一下，沒有處理奇 偶數的情況，因為我的調用時傳入的都是 偶數），發現是素數，使用Interlocked輔助方法給計數增加1。

private static int 
CountingParallel(int n) 
{ 
     var numprimes = 1; 
     Parallel.For(1, n/2, i => 
     { 
         if (IsPrime(i*2 + 1)) 
         { 
              Interlocked.Increment(ref numprimes); 
         } 
     }); 
     return numprimes; 
} 
  
public static bool IsPrime(int n) 
{ 
     if (n%2 == 0) 
         return false; 
     var limit = (int) (Math.Ceiling(Math.Sqrt(n)) + 1); 
     for (var i = 3; i < limit; i += 2) 
     { 
         if (n%i == 0) 
         { 
             return false; 
         } 
     } 
     return true; 
} 

***種場景，直接嵌入算法到C# WinRT App工程，執行結果如下（單位毫 秒）：

第二種場景，將C#算法包裝在一個類庫里（注意 是CLR類庫，只能在C#/VB直接通用），在C# WinRT App工程中調用這個類庫，執行 結果如下（單位毫秒）：

第三種場景，將C#算法包裝到一個Windows Runtime Component（WRC）中，在C# WinRT App工程中調用這個WRC類庫，執行結 果如下（單位毫秒）：

第四種場景，將C#算法包裝到一個Windows Runtime Component（WRC）中，在WinJS App工程中調用這個WRC類庫，執行結果如 下（單位毫秒）：

小結：以上是從.NET角度來進行的比較，很容易 看出***次CLR加載在這里性能損耗表現的很明顯，完成加載之后性能將穩定在一 定范 圍內波動；另外，并行計算在純算法的應用中有很明顯的性能優勢。

第二部分，接下來我們回歸Native環境，這里我 依然使用普通和并行計算兩種來嘗試，普通的依然沒什么可說的（實際上和C#的沒 區 別，除了關鍵字不一樣）。

static int CountingInternal(int n) 
{ 
     auto numprimes = 1; 
     for (auto i = 3; i <= n; i += 2) 
     { 
         auto isPrime = true; 
         auto limit = ceil(sqrt(i)) + 1; 
  
         for (auto j = 3; j < limit; j += 2) 
         { 
             if (i%j == 0) 
             { 
                 isPrime = false; 
                 break; 
             } 
         } 
  
         if (isPrime) 
         { 
             numprimes++; 
         } 
     } 
     return numprimes; 
} 

static bool IsPrime(int n) 
{ 
     if (n%2 == 0) 
         return false; 
     auto limit = (int) (ceil(sqrt(n)) + 1); 
     for(auto i=3; i<limit; i+=2) 
     { 
         if(n%i == 0) 
         { 
             return false; 
         } 
     } 
     return true; 
} 
  
static int CountingParallel(int n) 
{ 
     auto numprimes = 1; 
     parallel_for(1, n/2, [&](int i) 
     { 
         if(IsPrime(i*2+1)) 
         { 
             InterlockedIncrement((volatile unsigned long*)&numprimes); 
         } 
     }); 
     return numprimes; 
} 

第二種場景，將C++算法包裝在DLL中，在C++ WinRT App中使用，執行結果如下（單位毫秒）：

第三種場景，將C++算法包裝在動態連接庫Dll中，在C# WinRT App中通過 PInvoke來調用，執行結果如下（單位毫秒）：

第四種場景，將C++算法包裝在靜態鏈接庫Lib中，在C++ WinRT App中調用，執 行結果如下（單位毫秒）：

第五種場景，將C++算法包裝在Windows Runtime Component（WRC）中，在C# WinRT App中調用，執行結果如下（單位毫秒）：

第六種場景，將Windows Runtime Component（WRC）中，在WinJS App中調用， 執行結果如下（單位毫秒）：

第七種場景是將C++算法包裝在Windows Runtime Library（WRL，基于COM的底 層開發）中，然后在任何一種WinRT App中調用，可以預見這是一種很強大的方 式，但同時也是最費解的一種方式，我成功的包裝了普通算法的COM版，但是嘗試 了很長時間不能成功實現并行運算 的版本，也就放棄在這里展示了，如果你知道 如何在WRL中實現并行計算并返回 IAsyncOperation<T>，請不吝賜教。　

小結：基于C++的實現在適用性、穩定性和執行效率上無可挑剔，如果對于所有 細節（包括***次啟動）的效率考慮，C++是優先 的；如果考慮到C++的復雜度， 如果項目對性能要求可以適當放松但對進度要求很高的時候，選擇CLR會比較容易 控制的；如果原來已有的Web項目 向WinRT遷移，那么前段展示則可以考慮使用 WinJS+HTML來實現，后臺算法根據需要選擇C++或者CLR。

第三部分，如果所有的算法全部運行在 JavaScript中，那么其性能如何呢？這里我先買個關子，留待你自己去探究和發 掘。

總結，WinRT在編程語言的選擇性上有著非常好的 靈活性，在做選擇的時候需要充分考慮自己的要求，比如性能、比如工期、比如經 驗等 等。對于全新項目，在有經驗的情況下，追求***性能的首先首當其沖是 C++，如果考慮到經驗和掌控，可以選擇使用C++做底層，選擇相對容易上手 的 C#/VB或者HTML+JS做界面的方法；如果項目工期要求很緊，或者從老系統遷移，那 么這時候更多的考慮是使用已有資源，直到性能瓶頸的時 候才采取措 施——以C++重寫性能瓶頸來解決，當然，如果沒有C++經驗，也可以考 慮使用C#/VB來 實現WRC以包裝核心邏輯，從而提升運行效率。

附以上測試源代碼和測試工程，點擊這里下載。

原文鏈接：http://www.cnblogs.com/powertoolsteam/archive/2013/02/19/2916855.html