從BSP模型到Apache Hama

 

一、什么是BSP模型

• 概述

　　BSP(Bulk Synchronous Parallel，整體同步並行計算模型)是一種並行計算模型，由英國計算機科學家Viliant在上世紀80年代提出。Google發布的一篇論文(《Pregel: A System for Large-Scale Graph Processing》)使得這一概念被更多人所認識，據說在Google 80%的程序運行在MapReduce上，20%的程序運行在Pregel上。和MapReduce一樣，Google並沒有開源Pregel，Apache按Pregel的思想提供了類似框架Hama。

• 並行計算模型介紹

　　並行計算模型通常指從並行算法的設計和分析出發，將各種並行計算機（至少某一類並行計算機）的基本特征抽象出來，形成一個抽象的計算模型。從更廣的意義上說，並行計算模型為並行計算提供了硬件和軟件界面，在該界面的約定下，並行系統硬件設計者和軟件設計者可以開發對並行性的支持機制，從而提高系統的性能。

　　常用的並行計算模型有：PRAM模型、LogP模型、BSP模型、C3模型、BDM模型。

 

 

二、BSP模型基本原理

 

　　BSP模型是一種異步MIMD-DM模型（DM: distributed memory，SM: shared memory），BSP模型支持消息傳遞系統，塊內異步並行，塊間顯式同步，該模型基於一個master協調，所有的worker同步(lock-step)執行, 數據從輸入的隊列中讀取，該模型的架構如圖所示：

　　另外，BSP並行計算模型可以用 p/s/g/I 4個參數進行描述：

1. P為處理器的數目(帶有存儲器)。
2. s為處理器的計算速度。
3. g為每秒本地計算操作的數目/通信網絡每秒傳送的字節數，稱之為選路器吞吐率，視為帶寬因子 (time steps/packet)=1/bandwidth。
4. i為全局的同步時間開銷,稱之為全局同步之間的時間間隔 (Barrier synchronization time)。

   那么假設有p台處理器同時傳送h個字節信息，則gh就是通信的開銷。同步和通信的開銷都規格化為處理器的指定條數。

   BSP計算模型不僅是一種體系結構模型，也是設計並行程序的一種方法。BSP程序設計准則是整體同步(bulk synchrony)，其獨特之處在於超步(superstep)概念的引入。一個BSP程序同時具有水平和垂直兩個方面的結構。從垂直上看,一個BSP程序由一系列串行的超步(superstep)組成,如圖所示:

   

   這種結構類似於一個串行程序結構。從水平上看，在一個超步中，所有的進程並行執行局部計算。一個超步可分為三個階段，如圖所示:

       

   1. 本地計算階段，每個處理器只對存儲本地內存中的數據進行本地計算。
   2. 全局通信階段，對任何非本地數據進行操作。
   3. 柵欄同步階段，等待所有通信行為的結束。

 

三、BSP模型特點

1. BSP模型將計算划分為一個一個的超步(superstep)，有效避免死鎖。

2. 它將處理器和路由器分開，強調了計算任務和通信任務的分開，而路由器僅僅完成點到點的消息傳遞，不提供組合、復制和廣播等功能，這樣做既掩蓋具體的互連網絡拓撲，又簡化了通信協議；

3. 采用障礙同步的方式以硬件實現的全局同步是在可控的粗粒度級，從而提供了執行緊耦合同步式並行算法的有效方式，而程序員並無過分的負擔；

4. 在分析BSP模型的性能時，假定局部操作可以在一個時間步內完成，而在每一個超級步中，一個處理器至多發送或接收h條消息（稱為h-relation）。假定s是傳輸建立時間，所以傳送h條消息的時間為gh+s，如果 ，則L至少應該大於等於gh。很清楚，硬件可以將L設置盡量小（例如使用流水線或大的通信帶寬使g盡量小），而軟件可以設置L的上限（因為L越大，並行粒度越大）。在實際使用中，g可以定義為每秒處理器所能完成的局部計算數目與每秒路由器所能傳輸的數據量之比。如果能夠合適的平衡計算和通信，則BSP模型在可編程性方面具有主要的優點，而直接在BSP模型上執行算法（不是自動的編譯它們），這個優點將隨着g的增加而更加明顯；

5. 為PRAM模型所設計的算法，都可以采用在每個BSP處理器上模擬一些PRAM處理器的方法來實現。

 

四、BSP模型的評價

 

1. 在並行計算時，Valiant試圖也為軟件和硬件之間架起一座類似於馮·諾伊曼機的橋梁，它論證了BSP模型可以起到這樣的作用，正是因為如此，BSP模型也常叫做橋模型。

2. 一般而言，分布存儲的MIMD模型的可編程性比較差，但在BSP模型中，如果計算和通信可以合適的平衡（例如g=1），則它在可編程方面呈現出主要的優點。

3. 在BSP模型上，曾直接實現了一些重要的算法（如矩陣乘、並行前序運算、FFT和排序等），他們均避免了自動存儲管理的額外開銷。

4. BSP模型可以有效的在超立方體網絡和光交叉開關互連技術上實現，顯示出，該模型與特定的技術實現無關，只要路由器有一定的通信吞吐率。

5. 在BSP模型中，超級步的長度必須能夠充分的適應任意的h-relation，這一點是人們最不喜歡的。

6. 在BSP模型中，在超級步開始發送的消息，即使網絡延遲時間比超級步的長度短，該消息也只能在下一個超級步才能被使用。

7. BSP模型中的全局障礙同步假定是用特殊的硬件支持的，但很多並行機中可能沒有相應的硬件。

 

五、BSP與MapReduce對比

 

　　執行機制：MapReduce是一個數據流模型，每個任務只是對輸入數據進行處理，產生的輸出數據作為另一個任務的輸入數據，並行任務之間獨立地進行，串行任務之間以磁盤和數據復制作為交換介質和接口。

　　BSP是一個狀態模型，各個子任務在本地的子圖數據上進行計算、通信、修改圖的狀態等操作，並行任務之間通過消息通信交流中間計算結果，不需要像MapReduce那樣對全體數據進行復制。

　　迭代處理：MapReduce模型理論上需要連續啟動若干作業才可以完成圖的迭代處理，相鄰作業之間通過分布式文件系統交換全部數據。BSP模型僅啟動一個作業，利用多個超步就可以完成迭代處理，兩次迭代之間通過消息傳遞中間計算結果。由於減少了作業啟動、調度開銷和磁盤存取開銷，BSP模型的迭代執行效率較高。

　　數據分割：基於BSP的圖處理模型，需要對加載后的圖數據進行一次再分布的過程，以確定消息通信時的路由地址。例如，各任務並行加載數據過程中，根據一定的映射策略，將讀入的數據重新分發到對應的計算任務上（通常是放在內存中），既有磁盤I/O又有網絡通信，開銷很大。但是一個BSP作業僅需一次數據分割，在之后的迭代計算過程中除了消息通信之外，不再需要進行數據的遷移。而基於MapReduce的圖處理模型，一般情況下，不需要專門的數據分割處理。但是Map階段和Reduce階段存在中間結果的Shuffle過程，增加了磁盤I/O和網絡通信開銷。

　　MapReduce的設計初衷：解決大規模、非實時數據處理問題。"大規模"決定數據有局部性特性可利用（從而可以划分）、可以批處理；"非實時"代表響應時間可以較長，有充分的時間執行程序。而BSP模型在實時處理有優異的表現。這是兩者最大的一個區別。

 

六、BSP模型的實現

 

1.Pregel

　　Google的大規模圖計算框架，首次提出了將BSP模型應用於圖計算，具體請看Pregel——大規模圖處理系統，不過至今未開源。

http://blog.csdn.net/strongwangjiawei/article/details/8120318

2.Apache Giraph

　　ASF社區的Incubator項目，由Yahoo!貢獻，是BSP的java實現，專注於迭代圖計算（如pagerank，最短連接等），每一個job就是一個沒有reducer過程的hadoop job。http://giraph.apache.org/

3.Apache Hama

　　也是ASF社區的Incubator項目，與Giraph不同的是它是一個純粹的BSP模型的java實現，並且不單單是用於圖計算，意在提供一個通用的BSP模型的應用框架。http://hama.apache.org/

4.GraphLab

　　CMU的一個迭代圖計算框架，C++實現的一個BSP模型應用框架，不過對BSP模型做了一定的修改，比如每一個超步之后並不設置全局同步點，計算可以完全異步進行，加快了任務的完成時間。http://graphlab.org/

5.Spark

　　加州大學伯克利分校實現的一個專注於迭代計算的應用框架，用Scala語言寫就，提出了RDD（彈性分布式數據集）的概念，每一步的計算數據都從上一步結果精簡而來，大大降低了網絡傳輸，同時保證了血統的純正性（即出錯只需返回上一步即可），增強了容錯功能。Spark論文里也基於此框架實現了BSP模型（叫Bagel）。值得一提的是國內的豆瓣也基於該思想用Python實現了這樣一個框架叫Dpark，並且已經開源。https://github.com/douban/dpark

6.Trinity

　　這是微軟的一個圖計算平台，C#開發的，它是為了提供一個專用的圖計算應用平台，包括底層的存儲到上層的應用，應該是可以實現BSP模型的，文章發在SIGMOD13上，可恨的是也不開源。

　　主頁http://research.microsoft.com/en-us/projects/trinity/

 

以下幾個也是一些BSP的實現，不過關注度不是很高，基本都是對Pregel的開源實現：

7.GoldenOrb

另一個BSP模型的java實現，是對Pregel的一個開源實現，應用在hadoop上。

官網：http://www.goldenorbos.org/（要翻牆）

源碼：https://github.com/jzachr/goldenorb

8.Phoebus

Erlang語言實現的BSP模型，也是對Pregel的一個開源實現。

https://github.com/xslogic/phoebus

9.Rubicon

　　Pregel的開源實現。https://launchpad.net/rubicon

10.Signal/Collect

　　也是一個Scala版的BSP模型實現。http://code.google.com/p/signal-collect/

11.PEGASUS

在hadoop上實現的一個java版的BSP模型，發表在SIGKDD2011上。

http://www.cs.cmu.edu/~pegasus/index.htm

 

七、Apache Hama簡介

• Hama概述

背景：

　　2008年5月Hama被視為Apache眾多項目中一個被孵化的項目，作為Hadoop項目中的一個子項目，BSP模型是Hama計算的核心，並且實現了分布式的計算框架，采用這個框架可以用於矩陣計算(matrix)和面向圖計算(graph)、網絡計算(network)。

　　Hama是建立在Hadoop上的分布式並行計算模型。基於Map/Reduce 和 Bulk Synchronous的實現框架。運行環境需要關聯Zookeeper、Hbase、HDFS組件。集群環境中的系統架構由BSPMaster/GroomServer(Computation Engine)、Zookeeper(Distributed Locking)、HDFS/Hbase(Storage Systems)這3大塊組成。Hama中有2個主要的模型: 矩陣計算(Matrix package)和 面向圖計算(Graph package)。

　　Hama的主要應用領域是：矩陣計算、面向圖計算、PageRank、排序計算、BFS。

• Hama Architecture

Hama系統架構

　　Apache的Hama主要由三個部分組成：BSPMaster，GroomServers和Zookeeper，下面這張圖主要概述了Hama的整體系統架構,並且描述了系統模塊之間的通訊與交互。Hama的集群中需要有HDFS的運行環境負責持久化存儲數據(例如:job.jar),BSPMaster負責進行對Groom Server 進行任務調配，groom Server 負責進行對BSPPeers進行調用程序進行具體的調用，Zookeeper負責對Groom Server 進行失效轉發。

BSPMaster（划分計算到Groom，管理Groom，類似MapReduce的JobTracker）

　　在Apache Hama中BSPMaster模塊是系統中的一個主要角色，他主要負責的是協同各個計算節點之間的工作，每一個計算節點在其注冊到master上來的時候會分配到一個唯一的ID。Master內部維護着一個計算節點列表，表明當前哪些計算節點出於alive狀態，該列表中就包括每個計算節點的ID和地址信息，以及哪些計算節點上被分配到了整個計算任務的哪一部分。Master中這些信息的數據結構大小取決於整個計算任務被分成多少個partition。因此，一台普通配置的BSPMaster足夠用來協調對一個大型計算。
下面我們來看看BSPMaster做了哪些工作：

1. 1. 維護着Groom服務器的狀態。
   2. 控制在集群環境中的superstep。
   3. 維護在groom中job的工作狀態信息。
   4. 分配任務、調度任務到所有的groom服務器節點。
   5. 廣播所有的groom服務器執行。
   6. 管理系統節點中的失效轉發。
   7. 提供用戶對集群環境的管理界面。

　　一個BSPMaster或者多個grooms服務器是通過腳本啟動的，在Groom服務器中還包含了BSPeer的實例，在啟動GroomServer的時候就會啟動了BSPPeer，BSPPeer是整合在GrommServer中的，GrommServer通過PRC代理與BSPmaster連接。當BSPmaster、GroomServer啟動完畢以后，每個GroomServer的生命周期通過發送"心跳"信息給BSPmaster服務器，在這個"心跳"信息中包含了GrommServer服務器的狀態，這些狀態包含了能夠處理任務的最大容量，和可用的系統內存狀態，等等。

　　BSPMaster的絕大部分工作，如input ，output，computation，saving以及resuming from checkpoint，都將會在一個叫做barrier的地方終止。Master會在每一次操作都會發送相同的指令到所有的計算節點，然后等待從每個計算節點的回應(response)。每一次的BSP主機接收心跳消息以后，這個信息會帶來了最新的groom服務器狀態，BSPMaster服務器對給出一個回應的信息，BSPMaster服務器將會與groom 服務器進行確定活動的groom server空閑狀態，也就是groom 服務器可資源並且對其進行任務調度和任務分配。BSPMaster與Groom Server兩者之間通訊使用非常簡單的FIFO(先進先出)原則對計算的任務進行分配、調度。

GroomServer

　　一個Groom服務器對應一個處理BSPMaster分配的任務，每個groom都需要與BSPMaster進行通訊，處理任務並且想BSPMaster處理報告狀態，集群狀態下的Groom Server需要運行在HDFS分布式存儲環境中，而且對於Groom Server來說一個groom 服務器對應一個BSPPeer節點，需要運行在同一個物理節點上。

Zookeeper

　　在Apache HaMa項目中zookeeper是用來有效的管理BSPPeer節點之間的同步間隔(barrier synchronization),同時在系統失效轉發的功能上發揮了重要的作用。

1. 1. Apache Hama作業流程

1. 一個新的job被提交后，BSPJobClient先做一些初始化Job的工作：准備好作業的輸入資源、代碼等。
2. BSPMaster將Job划分為一個個的task，將task分配給GroomServer去執行，執行過程中維護GroomServer的進度與狀態。GroomServer發送心跳給BSPMaster來保持通信。超級步的控制是由BSPMaster完成的。
3. GroomServer啟動BSPPeer，由BSPPeer來具體執行task。GroomServer主要任務是BSPPeer的啟動和停止，維護任務的執行狀態，向BSPMaster報告狀態。一個GroomServer可運行多個task。類似於MapReduce的tasktracker的任務槽。所有的task有一個masterTask，masterTask在整個計算開始和結束時分別調用setup()和cleanup()。如果該GroomServer下的一個task失敗，GroomServer會重新啟動這個task，如果3次重啟task都失敗，則GroomServer向BSPMaster匯報該任務失敗。
4. BSPeer在計算期間間的通信是P2P方式進行的，由zookeeper負責調度。在一個超步中BSPeer只能發消息或者處理上一個超步中接收到的消息。例：A發送消息給B—>柵欄—>本次超級步結束 下一個超級步開始—>B接收到A發送的消息—>……

   另外，默認配置下Hama是將要發送的和接收到的消息都緩存在內存中，所以hama本身的同步通信功能不適合做大量數據傳遞，它只適合在同步計算過程中發送少量的消息。

5. 在整個計算過程中，zookeeper負責柵欄同步，將來會用於容錯機制。

 

• Apache Hama與Google Pregel

　　Hama類似Google發明的Pregel，如果你聽過Google Pregel這個利器的話，那么就對BSP計算模型不會陌生，Google的Pregel也是基於BSP模型，在Google的整個計算體系中有20%的計算是依賴於Pregel的計算模型，Google利用Pregel實現了圖遍歷(BFS)、最短路徑(SSSP)、PageRank計算,我猜想 Google的Google Me 產品很有可能會大量采用Pregel的計算方式，用Pregel來繪制Google Me產品中SNS的關系圖。

　　Google的Pregel是采用GFS或BigTable進行持久存儲，Google的Pregel是一個Master-slave主從結構，有一個節點扮演master角色，其它節點通過name service定位該頂點並在第一次時進行注冊，master負責對計算任務進行切分到各節點(也可以自己指定，考慮load balance等因素)，根據頂ID哈希分配頂點到機器(一個機器可以有多個節點，通過name service進行邏輯區分)，每個節點間異步傳輸消息，通過checkpoint機制實行容錯(更高級的容錯通過confined recovery實現)，並且每個節點向master匯報心跳(ping)維持狀態。

　　Hama是Apache中Hadoop的子項，所以Hama可以與Apache的HDFS進行完美的整合，利用HDFS對需要運行的任務和數據進行持久化存儲，也可以在任何文件系統和數據庫中。當然我們可以相信BSP模型的處理計算能力是相對沒有極限的特別對於圖計算來說，換句話說BSP模型就像MapReduce一樣可以廣泛的使用在任何一個分布式系統中，我們可以嘗試的對實現使用Hama框架在分布式計算中得到更多的實踐，比如：矩陣計算、排序計算、pagerank、BFS 等等。

• Hama與MapReduce對比

MapReduce的不足:

1. MapReduce 主要針對松耦合型的數據處理應用, 對於不容易分解成眾多相互獨立子任務的緊耦合型計算任務, 處理效率很低。

2. MapReduce 不能顯式的支持迭代計算。

3. MapReduce 是一種離線計算框架, 不適合進行流式計算和實時分析。

Hama的優勢：

1. 在科學計算領域的適用性：Hama提供的基礎組件能夠適應多種需要矩陣和圖形計算的應用。MapReduce在單純的大規模科學計算方面存在不足。比如求一個大型矩陣的逆矩陣，需要進行大量的迭代計算，而讀寫文件的次數並不多。此時Hama的迭代速度快的優勢便體現出來。

2. 兼容性：Hama能利用Hadoop和它相關的所有功能，因為Hama很好的兼容了現有Hadoop接口;

3. 可擴展性：得益於Hama的兼容性，Hama能夠充分利用大規模分布式接口的基礎功能和服務，比如亞馬遜EC2可以無需任何修正就可以使用Hama；

4. 編程方式的靈活性：為了保證靈活性來支持不同的計算模式，Hama提供了簡單計算引擎接口；任何遵循此接口的計算引擎都能自由接入和退出；

 

• Hama亟待解決的問題

 

1. 完善容錯能力。
2. NoSQL的輸入輸出格式
3. 無視同步（消除柵欄）
4. 使用異步消息：現在消息是在超級步的后期進行傳遞，在超級步里消息異步發送會帶來更多的並發設計。

• Hama容錯機制

BSPMaster出錯：

　　【未解決】https://issues.apache.org/jira/browse/HAMA-509

GroomServer出錯：

　　恢復GroomServer上的task。【未解決】https://issues.apache.org/jira/browse/HAMA-618

task出錯：

　　當BSPMaster發現任務出錯時，控制GroomServer恢復task。【已解決】https://issues.apache.org/jira/browse/HAMA-534

　　task會周期pingGroomServer，如果不能ping通則殺死自己，如果GroomServer長時間收不到某task的ping信息，則檢查task是否正常運行。【已解決】https://issues.apache.org/jira/browse/HAMA-498

 

summarizes：

https://issues.apache.org/jira/browse/HAMA-505

 

• Hama API

BSP

1.編寫自己的BSP類需要繼承org.apache.hama.bsp.BSP ，並且需要重寫bsp()方法，bsp()方法的聲明如下：

public abstract void bsp(BSPPeer<K1, V1, K2, V2, M extends Writable> peer) throws IOException, SyncException, InterruptedException;

2.按照我們自己的業務編寫bsp()方法，該方法內包含一個或多個超步，柵欄同步接口是peer.sync();

3.進程間通信接口如下：

　　　　下面是一個發送接收消息的例子：

4.在我們自己的BSP類中還有setup()和cleanup()兩個方法，分別在bsp()方法之前和之后執行，可以對這兩個方法重寫，完成一些需求。BSP類概要如下圖：

Graph

1. hama提供了Graph包，支持頂點為中心的圖計算，使用較少的代碼就可以實現google Pregel風格的應用。

實現一個Hama Graph應用包括對預定義的Vertex類進行子類化，模板參數涉及3種類型，頂點、邊和消息（ vertices, edges, and messages ）：

用戶重寫compute()方法，該方法將在每個超步的活躍頂點中執行。Compute()方法可以查詢當前頂點及其邊的信息，並向其他頂點發送消息。

2.通過繼承 org.apache.hama.graph. VertexInputReader 類，根據自己的文件格式創建自己的 VertexReader，示例如下：

1. 1. 通過繼承org.apache.hama.graph.AbstractAggregator類，可以編寫自己的聚合器。聚合器用來做全局的通信、監控等。超步內所有的頂點都可以給聚合器一個值，聚合器整合所有點提供的值，在下一個超步每個頂點都可以使用聚合器整合后的值。在一個job里可以使用多個聚合器，只需要在創建job時注冊一下即可，注冊如下：

      

頂點使用聚合器是按聚合器注冊時的順序（0,1,2,3...）向聚合器發送數據，以及使用聚合器內的數據的api如下：

頂點提供值給聚合器：

 

頂點使用聚合器：

 

八、安裝Hama

　　見文章：http://www.cnblogs.com/BYRans/p/4588276.html

 

九、編寫Hama job

　　在eclipse下新建Java Project，將hama安裝時需要的jar包全部導入工程。

官網中計算PI的例子：

（代碼見官網文檔）

　　將工程Export成Jar文件，發到集群上運行。運行命令:

　　$HAMA_HOME/bin/hama jar jarName.jar

　　輸出：

 

 

Current supersteps number: 0（）

Current supersteps number: 4（）

The total number of supersteps: 4（總超級步數目）

Counters: 8（一共8個計數器）

SUPERSTEPS=4（BSPMaster超級步數目）

LAUNCHED_TASKS=3（共多少個task）

org.apache.hama.bsp.BSPPeerImpl$PeerCounter

SUPERSTEP_SUM=12（總共的超級步數目，task數目*BSPMaster超級步數目）

MESSAGE_BYTES_TRANSFERED=48（傳輸信息字節數）

TIME_IN_SYNC_MS=657（同步消耗時間）

TOTAL_MESSAGES_SENT=6（發送信息條數）

TOTAL_MESSAGES_RECEIVED=6（接收信息條數）

TASK_OUTPUT_RECORDS=2（任務輸出記錄數）

  

PageRank例子：

（代碼見附件）

輸出：

 

十、相關知識介紹

• PRAM模型

　　PRAM（Parallel Random Access Machine，隨機存取並行機器）模型，也稱為共享存儲的SIMD模型，是一種抽象的並行計算模型，它是從串行的RAM模型直接發展起來的。在這種模型中，假定存在一個容量無限大的共享存儲器，有有限個或無限個功能相同的處理器，且他們都具有簡單的算術運算和邏輯判斷功能，在任何時刻個處理器都可以通過共享存儲單元相互交互數據。

 

PRAM模型的優點：

　　PRAM模型特別適合於並行算法的表達、分析和比較，使用簡單，很多關於並行計算機的底層細節，比如處理器間通信、存儲系統管理和進程同步都被隱含在模型中；易於設計算法和稍加修改便可以運行在不同的並行計算機系統上；根據需要，可以在PRAM模型中加入一些諸如同步和通信等需要考慮的內容。

 

PRAM模型的缺點：

1. 模型中使用了一個全局共享存儲器，且局存容量較小，不足以描述分布主存多處理機的性能瓶頸，而且共享單一存儲器的假定，顯然不適合於分布存儲結構的MIMD機器；

2. PRAM模型是同步的，這就意味着所有的指令都按照鎖步的方式操作，用戶雖然感覺不到同步的存在，但同步的存在的確很耗費時間，而且不能反映現實中很多系統的異步性；

3. PRAM模型假設了每個處理器可在單位時間訪問共享存儲器的任一單元，因此要求處理機間通信無延遲、無限帶寬和無開銷，假定每個處理器均可以在單位時間內訪問任何存儲單元而略去了實際存在的，合理的細節，比如資源競爭和有限帶寬，這是不現實的；

4. 未能描述多線程技術和流水線預取技術，而這兩種技術又是當今並行體系結構用的最普遍的技術。

 

• LogP模型

由Culler(1993)年提出的，是一種分布存儲的、點到點通訊的多處理機模型，其中通訊由一組參數描述，實行隱式同步。

 

LogP模型是一種分布存儲的、點到點通信的多處理機模型，其中通信網絡由4個主要參數來描述：

1. L(Latency) 表示源處理機與目的處理機進行消息（一個或幾個字）通信所需要的等待或延遲時間的上限，表示網絡中消息的延遲。

2. o(overhead)表示處理機准備發送或接收每個消息的時間開銷（包括操作系統核心開銷和網絡軟件開銷），在這段時間里處理不能執行其它操作。

3. g(gap)表示一台處理機連續兩次發送或接收消息時的最小時間間隔，其倒數即微處理機的通信帶寬。

4. P(Processor)處理機/存儲器模塊個數。

 

LogP模型的特點：

1. 抓住了網絡與處理機之間的性能瓶頸。g反映了通信帶寬，單位時間內最多有L/g個消息能進行處理機間傳送。

2. 處理機之間異步工作，並通過處理機間的消息傳送來完成同步。

3. 對多線程技術有一定反映。每個物理處理機可以模擬多個虛擬處理機(VP)，當某個VP有訪問請求時，計算不會終止，但VP的個數受限於通信帶寬和上下文交換的開銷。VP受限於網絡容量，至多有L/g個VP。

4. 消息延遲不確定，但延遲不大於L。消息經歷的等待時間是不可預測的，但在沒有阻塞的情況下，最大不超過L。

5. LogP模型鼓勵編程人員采用一些好的策略，如作業分配，計算與通信重疊以及平衡的通信模式等。

6. 可以預估算法的實際運行時間。

 

LogP模型的不足之處：

1. 對網絡中的通信模式描述的不夠深入。如重發消息可能占滿帶寬、中間路由器緩存飽和等未加描述。

2. LogP模型主要適用於消息傳遞算法設計，對於共享存儲模式，則簡單地認為遠地讀操作相當於兩次消息傳遞，未考慮流水線預取技術、Cache引起的數據不一致性以及Cache命中率對計算的影響。

3. 未考慮多線程技術的上下文開銷。

4. LogP模型假設用點對點消息路由器進行通信，這增加了編程者考慮路由器上相關通信操作的負擔。

 

• C3模型

　　C3模型假定處理機不能同時發送和接收消息，它對超步的性能分析分為兩部分：計算單元CU，依賴於本地計算量；通信單元COU，依賴與處理機發送和接收數據的多少、消息的延遲及通信引起的擁擠量。該模型考慮了兩種路由（存儲轉發路由和蟲蝕尋徑路由）和兩種發送/接收原語（阻塞和無阻塞）對COU的影響。

 

C3 模型的特點：

1. 用Cl和Cp來度量網絡的擁擠對算法性能的影響；
2. 考慮了不同路由和不同發送或接收原語對通信的影響；
3. 不需要用戶指定調度細節，就可以評估超步的時間復雜性；
4. 類似於H-PRAM模型的層次結構，C3模型給編程者提供了K級路由算法的思路，即系統被分為K級子系統，各級子系統的操作相互獨立，用超步代替了H-PRAM中的Sub PRAM進行分割。

 

C3 模型的不足之處：

1. 1. Cl度量的前題假設為同一通信對中的2個處理機要分別位於網絡對分后的不同子網絡內；
   2. 模型假設了網絡帶寬等於處理機帶寬，這影響了正確描述可擴展系統；
   3. 在K級算法中，處理機間順序可以由多種排列，但C3模型不能區分不同排列的難易程度。

 

• BDM模型

1996年J.F.JaJa等人提出了一種塊分布存儲模型(BDM, Block Distributed Model)。它是共享存儲編程模式與基於消息傳遞的分布存儲系統之間的橋梁模型。主要有4個參數：

1. P處理器個數。

2.τ處理機從發出訪問請求到得到遠程數據的最大延遲時間(包括准備請求時間、請求包在網絡中路由的時間、目的處理機接收請求的時間以及將包中M個連續字返回給原處理機的時間)。

3. M局部存儲器中連續的M個字。

4.σ處理機發送數據到網絡或從網絡接收數據的時間。

BDM模型的特點：

1. 用M反映出空間局部性特點，提供了一種評價共享主存算法的性能方法，度量了因遠程訪問引起的處理間的通信；
2. BDM認可流水線技術。某個處理機的K次預取所需的時間為τ+KMσ (否則為K(τ+Mσ))
3. 可編程性好；
4. 考慮了共享主存中的存儲競爭問題；
5. 可以用來分析網絡路由情況。

 

BDM模型的不足：

1. 認為初始數據置於局存中，對於共享主存程序的編程者來說，需要額外增加數據移動操作；
2. 未考慮網絡中影響延遲的因素(如處理機的本地性、網絡重擁擠等)；
3. 未考慮系統開銷。