= 撰寫 R-MPI 的三種方式 =
 * 根據 R-MPI 的[http://ace.acadiau.ca/math/ACMMaC/Rmpi/structure.html 官網所描述]，R-MPI 平行處理的程式撰寫上，可以分為三種方式:[[BR]]
== Brute Method ==
 * 這是最簡單的方式，我們把 Task 當成是迴圈，假設今天有 10 個迴圈，要同時進行平行處理，那麼就必須要有 10 台 slaves，把所謂的'''Task(任務)'''，平均分配到 10 個不同的 slaves 上面執行。這種方式的優點是寫法最簡單，所需要外加的程式碼也會最少；但缺點是擴充性(scalability)也最差，一旦任務的數目大於 slaves 的數目，那麼此種方式就不適合使用。由於甚少有情況是任務數目剛好等於 slaves 的數目，因此這種寫法雖然簡單但是並不實用，在這裡就不多作介紹。
== Task Push ==
 * 顧名思義，Task push，就是將任務送(push)到 slaves 上去處理，直到所有任務都處理完畢為止。[[BR]]
   這個方式改善了 Brute Method 中 --- "任務數目必須等於 slaves 數目"的這個缺點；也就是說 Task Push 可以處理任務數目大於 slaves 數目的情況。[[BR]]
   但是仍然不夠完美，最主要的原因是，在一般的情況下，不見得每一台 slaves 的運算能力都是一樣的，這個方法最大的缺點就是當 slaves 的運算能力不一時，[[BR]]
   運算能力較強的機器必須花費多餘的時間來等待運算能力較弱的機器。
 * Task Push Flow Chart
[[Image(task_push.JPG)]]
== Task Pull ==
 * 顧名思義，Task Pull，不像 Task Push 是 Server 主動分配任務給 slaves，最主要是因為 Server 端並不會知道各個 slaves 的運算能力，或是各個 slaves 目前有沒有被其它行程佔用住資源。[[BR]]
   相反地，這個方式是由 slaves 主動去向 server 端要任務，因此稱為 Task Pull。只要 slave 處理完畢時，便會告知 server 說: '''我處理完畢了，若還有任務的話，請 send 給我'''! [[BR]]
   這個方式的優點就是: 不管任務的數目是否大於 slaves 的數目；也不管各個 slaves 的運算能力是否相同，所有的任務可以在最短的時間內被處理完畢。
 * Task Pull Flow Chart
[[Image(task_pull.JPG)]]
== Task Push and Task Pull Comparison ==
 * 舉個例子來比較 Task push & Task pull
 * 假設 Task = 20；slaves = 5 [[BR]]
   '''其中，針對一個特定任務來說，slave 5 的處理速度比 slave 1 ~ 4 要慢 15 分'''
 * Task Push
  * 任務分配的順序將會是 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5
  * 因為 slave 5 的處理能力較弱所造成需要額外消耗的時間為 15 x 4 = 60 分
 * Task Pull
  * 假設 Slave 1 ~ 4 每處理一個任務所需要花費的時間不超過 30 秒。
  * 任務分配的順序將會是 1, 2, 3, 4, 5, 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3
  * 因為 slave 5 的處理能力較弱所造成需要額外消耗的時間為 15 x 1 = 15 分
== 心得 ==
 * 若可以將 Task Pull 的概念進一步地延伸到 Grid Computing 上，應該會有不錯的效果。對於使用 Grid 來運算的任務，應該都要採取 Task Pull 的方式來做，重點在於程式流程的設計。