* 要求昂貴的駑馬技術。
</pre> 
      <p>　 
      <h3>應用軟體架構</h3> 
      <p>為了在多CPU下平行地跑應用程式，在同時部份必須被分開來，一個標準的單CPU應用軟體不會比它在多處理器下跑的快，有些工具和編譯器可以做這種工作，但是將程式平行化可不是“隨插即用“。這完全和程式有關，有些程式很容易平行化，有些是極度困難，有些情形受限於algorithm的相關性而根本不可能做到平行。 
      <p>在討論軟體議題之前，先要介紹合適性的觀念。 
      <p>　 
      <h2><a name="suitability"></a><a name="ss4.4">4.4 合適性（Suitability）</a></h2> 
      <p>關平行計算的大多數問題都有相同的答案： 
      <p>全和應用程式本身有關。 
      <p>在我們進入這個議題之前，有一個非常重要的不同點需要釐清—同時（CONCURRENT）和平行（PARALLEL）之間的差異性，為了方便討論起見，我們先定義這二個觀念： 
      <p>程式內同時的部份是指可以單獨個別計算的部份。 
      <p>程式內平行的部份是指那些可以在同一時間內分別由不同處理器執行的同時部份。 
      <p>二者相異的地方是非常重要，因為同時是程式本身的特性，而有效的平行則是機器的特性，理想狀況下，較快的效能肇因於平行執行，平行效能的限制因素在於計算節點之間的傳遞速度和延遲（延遲也會出現在緒SMP應用軟體，主要來自於快閃（cache）的一致性）。大多數通用的平行測試套件都有很高的平行性，傳遞和延遲都不是瓶頸，這類問題可以稱作“顯而易見的平行“（obviously  
      parallel），其他的應用軟體就沒那麼簡單，平行地執行程式中的同時部份可能會造成程式跑得較慢，抵消掉其他同時部份所得到的效能。簡單說，傳遞所花費的時間必須從儉省的計算時間補償，否則平行執行同時部份會很不經濟。 
      <p>程式設計者的工作是要決定程式哪些同時的部份應該平行化，哪些則不要。這將會決定應用程式的效能，下面的圖對程式設計者做了些總結。 
      <p>　 
      <pre>
佔應用程
式的百分比

         | *
         | *
         | *
         | *
         |  *
         |  *
         |  *
         |  *
         |    *
         |     *
         |      *
         |        ****
         |            ****
         |                ********************
         +-----------------------------------
                     傳遞時間 / 計算時間
</pre> 
      <p>在一個理想的平行電腦，傳遞和計算二者相當，任何同時都可以平行化，很不幸地，真實的平行電腦（包括共享記憶體機器）都像上圖所示。當設計Beowulf時，使用者必須牢記這圖，因為對一特定平行電腦，平行效能決定於傳遞時間和計算時間之比，應用程式可能可以在各種平行電腦上執行，但是不能保證一定會有較佳的效能。 
      <p>一般來說，沒有既可攜性又有效能的平行程式。 
      <p>上圖還有其他的延伸議題，當效能取決於傳遞和計算比，改變比值中的某一項不表示一定可以提高效能。改變處理器的速度，但不改變傳遞的速度，程式可以有沒直覺性的效果。舉例來說，CPU速度提升二倍或三倍，但保持傳遞速度，可能使妳的程式有較好的平行效果，比循序執行更有效，that  
      is, it may now be faster to run the previousloy PARALLEL parts as  
      SEQUENTIAL。更進一步，平行地執行沒有效率的部份，可以使妳的程式無法達到最快的速度，因此，藉由增加更快的處理器，妳可以讓程式慢下來（妳正讓新的CPU不用它最快的速度執行程式）。 
      <p>升級到更快的CPU可能反而降慢妳的程式速度。 
      <p>因此，必須知道妳是否可以用平行硬體環境，妳必須對妳的程式在一特定電腦上的可適性有相當的認識，妳必須知道相當多的議題，包括CPU速度、編譯器、訊息傳遞的API、網路等等。請注意，只認識應用程式是不夠的，妳必須指出程式中計算量最重的部份，但是妳不知道這個部份的傳遞花費，對特定系統，它的傳遞所花的時間可能無法讓程式無法有效地平行化。 
      <p>最後要說一些常發生的錯誤觀念，我們經常說：一個程式被平行化，但是真實的情形是程式的同時部份才被平行化，從以上的說明，一個程式並沒有平行化，平行化的效益是機器的特性。 
      <p>　 
      <p>　 
      <h2><a name="ss4.5">4.5 撰寫和移植平行軟體</a></h2> 
      <p>一旦妳決定需要平行計算，並且想要設計和架設一套Beowulf，根據上述的討論來思考一些和妳的應用程式有關的建議將是個很好的主意。 
      <p>一般而言，有兩件事妳能夠做的： 
      <ol> 
        <li>直接架設第一類Beowulf，然後想辦法讓妳的應用程式來適應這套系統，或者在Beowulf上直接跑一個現成的平行應用程式（必須注意上述所提的可攜性和效能的議題）。 
        <li>先思考一下妳將要在妳的Beowulf上跑的應用程式，然後估計何種類型的硬體和軟體是妳所需要的。</li> 
      </ol> 
      <p>兩種情形妳都要考慮效能的議題，一般而言，有三件事妳需要做： 
      <ol> 
        <li>決定妳的程式中的同時部份。 
        <li>估計平行效能。 
        <li>描述出程式中的同時部份。</li> 
      </ol> 
      <p>讓我們一一詳述。 
      <p>　 
      <h3>決定妳的程式中的同時部份</h3> 
      <p>這個步驟通常是要考慮將妳的程式平行化，如何平行化將在第二個步驟，現在妳要決定資料的關連性。 
      <p>&gt;從實際操作的角度來看，應用程式可能有二種形態的同時性：計算（數字的計算）和I/O（資料庫）。雖然大部分情形，計算和I/O同時性是相互正交的（orthogonal），但是有些程式是兩者都需要，有些工具程式可以對現有的程式做同時性的分析，這些工具大部分是為Fortran程式語言設計的，使用Fortran語言有兩種理由：很早以來，大部分的數字計算程式是用Fortran語言寫的，另外Fortran是很容易分析的。假如沒有可利用的工具，這個步驟對現存的應用程式將是非常困難。 
      <p>　 
      <h3>估計平行效能</h3> 
      <p>沒有工具程式的幫助，這個步驟將需要不斷地嘗試錯誤，或是根據舊有經驗來猜測。假如妳心目中已經有特定的應用程式，想要決定這個應用程式是CPU限制（計算限制），還是硬碟限制（I/O限制），根據妳的需求，妳的Beowulf可能會有很大的差異。舉例來說，一個計算限制的問題可能需要一些很快的CPU，高速且低延遲的網路，但是一個I/O限制的問題可能需要較慢的CPU和高速乙太網路。 
      <p>這個建議令大多數人覺得很訝異，一般的想法是處理器越快越好，這想法當然是正確的，但是妳必須要有不受限制的預算經費，實際情形是要在有限的經費得到最高效能的系統，對一個I/O限制的問題，已有現成的規則（稱作Eadline-Dedkov定律）可供利用。 
      <p>對兩套有相同累積CPU效能指數的平行電腦而言，一個擁有較慢處理器（一個較慢的處理器間的傳輸網路）對I/O主導的應用程式將會有較佳的效能。 
      <p>要證明這項規則將會超出本文件的範圍，妳若覺得有趣，可以下載這篇論文  
      <i>I/O主導應用程式在平行電腦上的效能考量（Performance  
      Considerations for I/O-Dominant Applications on Parallel Computers）</i>  
      (Postscript 格式 109K ) <a href="ftp://www.plogic.com/pub/papers/exs-pap6.ps">(ftp://www.plogic.com/pub/papers/exs-pap6.ps)</a> 
      <p>一旦妳已經決定程式中的同時性是何種形態，妳將需要估計一旦平行處理的話，效能將會如何。參見  
      <a href="http://www.linux.org.tw/CLDP/Beowulf-HOWTO-5.html#software">Software</a>  
      有對軟體工具的描述。 
      <p>若沒有這些工具，妳可以透過這個步驟，自行考量，假如每次計算是以分鐘計，資料傳輸則以秒計，那它將是很好的平行對象，但是記住，假如妳將16分鐘的計算時間拆成32份，而每份的資料傳遞需要數秒鐘，那麼事情將變得嚴重。 
      <p>　 
      <h3>描述出程式中的同時部份</h3> 
      <p>有幾種方法找出程式中的同時部份： 
      <ol> 
        <li>明確地平行執行 
        <li>隱含地平行執行</li> 
      </ol> 
      <p>這二者主要的差別在於明確地平行化取決於使用者，隱含地平行化取決於編譯器。 
      <p>　 
      <h3>明確的方法</h3> 
      <p>有一些基本的方法是要靠使用者專為平行電腦來修改原始碼，使用者必須使用  
      <a href="http://www.epm.ornl.gov/pvm">PVM</a> 或 <a href="http://www.mcs.anl.gov/Projects/mpi/index.html">MPI</a>在程式內增加資訊，  
      或是使用POSIX緒（無論如何要牢記心中，緒無法在SMP主機板之間移動）。 
      <p>明確的方法在實行和除錯上最為困難，使用者通常在標準Fortran  
      77或 C/C++原始碼中加入函式。MPI程式庫加入一些函式，使得一些標準平行方法容易實行（例如分散和收集函式），另外還可以使用已經被平行化的標準程式庫。無論如何要將可攜性和效能之間的平衡牢記心中。 
      <p>從歷史上的理由，大多數數值計算的程式是用Fortran語言所寫的，因此在平行計算中，Fortran是受最大的支援（工具、程式庫等）。現在大多數的程式設計者都是用C語言，或是認為C語言可以執行地更快，而用C語言重新改寫現存的Fortran應用程式。由於C語言最接近通用的機器語言，C語言較快可能是正確的，但是它也有一些重要的缺陷。C語言使用指標（pointer）會讓資料相關性的決定極度困難，自動分析指標也是極度困難，假如妳有現成的Fortran程式，並且未來想要變成平行程式—千萬不要把它轉成C語言。 
      <p>　 
      <h3>隱含的方法</h3> 
      <p>隱含方法是使用者放棄一些或全部放棄自行平行，改用編譯器的一種方法，例如  
      FORTRAN 90， 高效能Frotran (High Performance Fortran，HPF),  
      大量協同平行（Bulk Synchronous Parallel，BSP)還有許多正在發展當中。 
      <p>　 
      <p>隱含方法仍要求使用者對於程式同時的特性提供一些資訊，但是編譯器必須對如何平行地執行同時性做出許多決定，這些方法提供某種程度的可攜性和效能，但是對一個平行編譯器，仍然沒有一個最好的方法來描述同時性的問題。 
      <p>　 
      <p>　 
      <hr> 
      <a href="Beowulf-HOWTO-5.html"><img alt="Next" src="next.gif" width="16" height="16"></a> <a href="Beowulf-HOWTO-3.html"><img alt="Previous" src="prev.gif" width="16" height="16"></a> 
      <a href="Beowulf-HOWTO.html#toc4"><img alt="Contents" src="toc.gif" width="16" height="16"></a></td>
  </table>

</body>

</html>