.NET4.0平行計算技術基礎（2）

iDotNetSpace發表於2009-10-27
  .NET4.0平行計算技術基礎（2） 收藏 此文於2009-09-14被推薦到CSDN首頁
如何被推薦？
 .NET4.0平行計算技術基礎（2）

上一部分介紹了CPU與“核”以及“並行”和“併發”的區別，這一部分我們將進一步介紹平行計算的效能衡量與平行計算系統的大致分類，為後面介紹.NET 4.0的平行計算打下基礎。

3 如何衡量平行計算的效能提升？
         之所以要研究平行計算，其目的是獲得更好的效能。一個軟體系統的效能，通常使用兩個指標來進行衡量：

（1）       響應速度（Responsiveness）：使用者向軟體系統提交一個工作任務，軟體系統要花費多長的時間才能處理完畢並將結果通知使用者？

（2）       吞吐率（Throughput）：在單位時間間隔內軟體系統最多可以處理多少個工作任務？

         平行計算的優勢就在於它可以縮短系統完成單個工作任務的時間和提升系統的吞吐率。

         那麼，我們怎樣定量衡量因為“並行”而帶來的系統效能提升？很明顯，這裡所說的“提升”是有參照物的，對於並行演算法，最直觀的參照物就是完成同樣功能的序列演算法。

         人們使用 “加速係數（speedup factory）[1]”來定量衡量一個並行演算法的好壞：

      

   加速係數越大，說明效能提升越明顯。

         我們感興趣的是：

         在p個處理器上執行並行演算法，到底比在單個處理器上執行序列演算法理論上能快多少？如果增加處理器的個數，加速係數能否進一步增大？這種增大有沒有一個限制？

         針對這個問題，平行計算理論中有一個著名的“阿姆達爾定律（Amdahl’s law）”回答了這個問題。

         鑑於在實際中“100%純粹”的並行演算法很少，此定律假設演算法應同時包容序列執行和並行執行兩部分，其中，序列執行的部分佔整個演算法的比例為f，並且假設並行執行部分除了計算外並無其他開銷，則在p個處理器上執行此演算法，其加速係數為：

 



 

         從這個公式可以得到一個有趣的結論。試著讓pà∞，則上述公式變為：



 

 

 

         這說明：在演算法中序列部分的比例不變的情況下，不算你使用多少個處理器，加速係數最大也超不過1/f！

         例如，假設某演算法中有20%的序列演算法，則不管後面你如何加速，最大加速係數超不過5（1/0.2=5）。

         實際情況可能更糟，因為使用並行演算法必然會有其它一開銷，比如並行演算法都是使用執行緒來執行的，因此，執行緒的上下文切換就必須耗用系統資源，考虎到這一點，修正後的“阿姆達爾定律”變為：

 

 

 

  其中H(p)代表演算法並行部分在單個處理器上執行所帶來的系統開銷，不同的演算法H(p)的值也不一樣。

         這說明，如果系統開銷非常大，那麼採用多執行緒並行執行一個演算法，不但沒有加速，反而會降低了程式的執行效能。

         依據“阿姆達爾定律”得出的這個結論令人沮喪！但由此也可以得到一個重要的結論：如果希望使用平行計算來提升程式的效能，那麼應儘可能地減少程式中序列程式碼的比例。



--------------------------------------------------------------------------------

[1] 有的書中將其稱為“加速比”。

 

擴充閱讀：

“樂觀”的Gustafson定律

       “阿姆達爾定律”的結論讓人沮喪，但到了20世紀80年代晚期，Sandia國家實驗室的科學家們在對具有1024個處理器的超立方體結構上觀察到了3個實際應用程式隨著處理器的增加發生線性加速的現象，科學家John L. Gustafson基於此實驗資料在1988年提出了一個新的計算加速係數的公式：



與“阿姆達爾定律”一樣，S(p)代表加速系統，p代表處理器數量，f代表演算法中序列部分所佔的比例。

       Gustafson定律說明在許多實際的應用程式中得到接近線性的加速效果是可能的。

       “阿姆達爾定律”的問題出在它的前提過於理想化。因為並行演算法通常能處理比序列演算法更大規模的問題，即使演算法仍然存在著序列部分，但由於問題規模的不斷擴大，往往會導致演算法中序列部分所佔比例的持續減少。  Gustafson定律又點燃了人們繼續研製整合更多處理器（或整合更多執行核的處理器）的計算機系統的熱情。可以預測，未來的計算機將整合更多的處理器，當前雙核個人電腦的普及只不過是一個開始罷了。

 

4 實際測量並行程式的效能
         不管是“悲觀”的阿姆達爾定律還是“樂觀”的Gustafson定律都只是一種理論上的結果，在真實的執行環境中，影響程式效能的因素有許多，僅靠幾個簡單的公式並不能真正計算出一個真實的“並行”程式比相應的“序列”版本到底快了多少。最可靠的方法還是實地測試，在同樣的軟體和硬體環境中，先後執行程式的“並行”和“序列”兩個版本，比對它們的執行時間，就知道結果了。

         在.NET程式中，我們可以使用StopWatch類來測試演算法的效能。

         以下是使用StopWatch測試演算法執行時間的程式碼框架：

 

    Stopwatch sw = new Stopwatch();

    sw.Start(); //啟動計時

     //編寫程式碼執行被測試的演算法

     sw.Stop();//停止計時

    //獲取演算法執行時間

     long UsedTime = sw.ElapsedMilliseconds;

//...

 

         另外，呼叫StopWatch物件的Reset()方法可以重置計時值，再接著呼叫Start()方法就可以開始一個新的計時。

5 平行計算系統的大致分類
         有兩種主要的平行計算系統型別。一種稱為“共享儲存器（Shared Memory）的多處理器”系統，其思想很簡單，所有處理器都可以訪問同一個主儲存器，從而允許執行在多個處理器上的各個執行緒可以通過主儲存器方便地共享資訊。

 



 

基於共享儲存器的平行計算系統發展已有許多年，人們也為開發執行於這種平臺的軟體提供了不少工具，其中得到廣泛應用的是OpenMP，它可以幫助程式設計師使用Fortran（或C/C++）語言高效地開發多執行緒平行計算程式。

         C#和Visual Basic編譯器沒有遵循OpenMP標準，但通過給.NET基類庫新增並行擴充套件（Parallel Extensions），可以使用比OpenMP更方便的方法設計平行計算程式。

擴充閱讀：

 

OpenMP簡介

       針對共享儲存器的平行計算系統，為了簡化軟體開發工作，人們設計了一個OpenMP標準，通過給程式碼中新增特定的編譯指令，讓實現了此標準編譯器自動地幫助我們生成並行指令程式碼。例如，以下是一個典型的迴圈程式碼：

 

    for (int i = 0; i < 100000; i++)

    {

        //……

    }

 

   給上述程式碼新增一個特殊的編譯指令: 

 

#pragma omp parallel for    

    for (int i = 0; i < 100000; i++)

    {

        //……

    }

 

       遵循OpenMP標準開發的編譯器 “認識”此指令，在編譯時會自動生成相關的指令讓此程式碼可以並行執行。OpenMP的實現機制決定要建立的執行緒個數，以及如何能夠盡善盡美地管理這些執行緒。開發人員只需告訴OpenMP哪個迴圈應該以多執行緒方式執行，至於那些為了利用並行性而進行的執行緒建立、初始化、執行緒同步等工作都可以交給OpenMP編譯器來完成。

       OpenMP的標準形成於1997年，支援使用Fortran、C/C++語言編寫的程式。

 

         另一種稱為“訊息傳遞的多處理機”系統，其特點是往往由多臺相互連線的計算機構成一個平行計算平臺，計算機之間通過“訊息”的傳遞協同工作。



 

 

基於訊息傳遞構造的平行計算系統本質上是一個分散式軟體系統，由於網際網路的無孔不入，利用互聯的計算機實現平行計算是當前一個非常活躍的領域。在微軟平臺之上，使用WCF可以很方便地開發這種型別的軟體系統。本書第9篇詳細介紹WCF。

=====================



本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/bitfan/archive/2009/09/13/4547812.aspx

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-617525/，如需轉載，請註明出處，否則將追究法律責任。

相關文章