論文地址：osdi16/osdi16-zhu.pdf

介紹

（1）Gemini采用稀疏-稠密、信號-槽抽象，將push-pull混合模型從共享內(nèi)存擴展到分布式場景。

（2）基于塊劃分模式，是一種低開銷的擴展設計同時保持了頂點的局部訪問。

（3）采用壓縮頂點索引的雙模式

（4）基于NUMA感知的子分區(qū)使節(jié)點內(nèi)的訪問更加高效

（5）位置感知的塊劃分和細粒度的work-stealing同時提高了節(jié)點內(nèi)和節(jié)點間的負載平衡。

圖處理抽象

頂點保存信息，邊是不可修改的對象。

支持雙向邊和單向邊，雙向邊轉(zhuǎn)化為一對有向邊。

圖處理的執(zhí)行時通過頂點沿邊的更新，知道圖狀態(tài)收斂或者達到指定的迭代次數(shù)。

活躍頂點是將要更新的頂點，活躍邊是活躍頂點的出邊。

雙更新傳播模型

在圖處理過程中，活躍邊可能是dense或sparse。

例如CC在開始的時候是dense，經(jīng)過幾次迭代之后大部分的點接受到他們最終的label就會變?yōu)閟parse的狀態(tài)；SSSP開始的時候是sparse，活躍頂點增多就會變成dense，當算法接近收斂再次變?yōu)閟parse狀態(tài)。

sparse更適合用push模式（更新沿著活躍點的出邊傳遞），dense更適合pull模式（頂點的更新通過搜集入邊頂點的狀態(tài)）。

Gemini采用Ligra提出的一種在push和pull自適應切換的方法，閾值為$\frac{|E|}{20}$，區(qū)別在于Gemini將進行分區(qū)并分布到多個節(jié)點上，通過顯式的消息傳遞進行通信和更新。

基于塊的分區(qū)

上圖的例子是將圖上6個點，平均分為3個部分（白色為master，黑色為mirror），在dense模式下每個分區(qū)的mirror節(jié)點是分區(qū)中節(jié)點的出邊鄰居節(jié)點，這些mirror節(jié)點采用pull聚集當前分區(qū)節(jié)點的狀態(tài)，然后更新遠端的節(jié)點。

采用塊劃分可以很容易的通過邊界判斷節(jié)點的隸屬關系，同時也簡化了頂點數(shù)據(jù)表示，每個節(jié)點只負責實頂點數(shù)組的擁有部分并將其分配在連續(xù)的內(nèi)存頁中，不需要壓縮頂點狀態(tài)的空間消耗。

雙模式的邊表示

Gemini使用CSR和CSC表示圖的狀態(tài)，每個分區(qū)對邊進行編號，sparse是指向分區(qū)的邊，dense是當前分區(qū)指出的邊。

通過Bitmap輔助sparse模式下的CSR的表示，標記指向當前分區(qū)的點，方便后續(xù)的判斷。

采用雙壓縮輔助dense模式下的CSC的表示，保存當前分區(qū)指出的點vtx和對應邊的偏移量。

位置感知的分區(qū)

Gemini的圖分區(qū)同時考慮了頂點的局部性和邊的密集型，根據(jù)$\alpha |V_i|+|E_i^D|$來進行劃分，$\alpha =8\times (p?1)$。

NUMA感知的子分區(qū)

利用NUMA的內(nèi)存訪問特性，在每個節(jié)點繼續(xù)對圖進行劃分，來減少遠程CPU內(nèi)存的訪問。

協(xié)同調(diào)度

Gemini將集群中的節(jié)點通過MPI組成一個環(huán)，使計算和通信重疊。

對于第一個分區(qū)來說的調(diào)度來說，共分為三個階段，Batch沿著分區(qū)編號遞增的方向發(fā)送，沿著分區(qū)編號遞減的方向接受。

細粒度的Working-Stealing

雖然節(jié)點間的負載均衡通過Gemini的局部塊劃分來保證，但是當分區(qū)變小就不能很好的保證分區(qū)的平衡。

基于塊分區(qū)方案可以對連續(xù)的頂點進行處理，提高了緩存利用率和消息批處理，結(jié)合OpenMP，Gemini的每個線程首先完成自己core的分區(qū)任務，然后通過原子操作獲取其他分區(qū)的任務進行處理，這樣雖然帶來了一些開銷，但是提高了節(jié)點內(nèi)部的負載平衡。

作者的實驗環(huán)境是 8 nodes, 2 sockets per node, 12 cores per socket, and 64 vertices per mini-chunk。

實驗

作者使用了5種算法進行測試：PageRank（PR）、connected components（CC）、single source shortest path（SSSP）、breadth first search（BFS）、betweenness centrality（BC），PR執(zhí)行20次迭代，其余的執(zhí)行到算法收斂。

同時于Power Graph、GraphX、PowerLyra、Ligra、Galois進行對比。

使用的數(shù)據(jù)集為：

在單個節(jié)點上Ligra、Galois、Gemini的對比：

Gemini在PR和BC上比其他系統(tǒng)性能好，在CC、SSSP、BFS上處在第二。

因為Gemini消息抽象（signal-slot）帶來了額外的開銷，尤其是計算任務少的算法（BFS），而其他系統(tǒng)訪問活躍頂點的所有邊，創(chuàng)建和活躍邊成正比的成本，有效地掩蓋了消息生成的開銷。

另外其他的系統(tǒng)采用共享內(nèi)存，可以很快的獲取頂點最后的狀態(tài)，而基于BSP通信機制的Gemini則需要經(jīng)過多個迭代，存在滯后性。

在8個節(jié)點上的運行對比：

可以看出Gemini在不同算法和數(shù)據(jù)集上的運行速度遠高于其他系統(tǒng)，最高有39.8x的提升。

在8個節(jié)點運行的內(nèi)存消耗：

雖然Gemini需要存儲兩份邊的信息供spare和dense模式使用，但是實際的內(nèi)存得到很好的控制。

節(jié)點內(nèi)的擴展性對比：

使用COST metrix得到Gemini需要3 cores才能超過優(yōu)化過單線程的性能。

Gemini可以在2、4、8 cores下實現(xiàn)1.9、3.7、6.8倍的速度提升。

隨著core的增加，core之間的負載均衡成為性能提升的挑戰(zhàn)，Gemini仍然可以在12、24cores下帶來9.4、15.5倍的提升。

節(jié)點間的擴展性對比：

上圖是Gemini與擴展性表現(xiàn)最好的開源系統(tǒng)PowerLyra的對比。

在weibo-2013上Gemini和PowerLyra的擴展性相當，都是接近線性的增長。在小圖wnwiki-2013兩個系統(tǒng)表現(xiàn)的都不好。

在twitter-2010上Gemini在4個節(jié)點后擴展性很差，主要和頂點的索引訪問和消息的產(chǎn)生/消費的瓶頸。隨著節(jié)點的增加，每個分區(qū)的頂點數(shù)和邊數(shù)都能顯著減少，但是分區(qū)的mirror節(jié)點不能很快的減少，這就增加的處理的成本。

設計選擇

對于Gemini的幾個主要的設計，很難比較其中個別設計的貢獻，而且當逐個添加這些優(yōu)化到基準系統(tǒng)時，測試的表現(xiàn)收益取決于使用的順序。

自適應的sparse/dense雙模式

從圖中可以看出，sparse和dense的性能差距十分顯著，PR適合dense模式，CC開始適合dense模式當大多數(shù)節(jié)點保持活躍時適合sparse模式，對于SSSP，sparse在大多數(shù)迭代中更優(yōu)于dense模式，除了許多頂點被更新的迭代。

Gemini可以采用更優(yōu)的模式，在76次迭代的CC種有2次的誤選，在172次迭代的SSSP有5次誤選。這些誤選都是發(fā)生在兩種模式中間。

基于塊的分區(qū)

chunking和hash（x % p）的性能對比：

多種分區(qū)方法的預處理和執(zhí)行的時間對比：

有無NUMA的對比：

在不使用socket-level子分區(qū)的情況下，交錯的內(nèi)存分配保留對圖拓撲，頂點的所有訪問狀態(tài)，以及跨兩個套接字分配的消息緩沖區(qū)。 相反，應用套接字級別的子分區(qū)，遠程內(nèi)存訪問已顯著減少，因為
它們僅在working-stealing或訪問其他套接字產(chǎn)生的消息時發(fā)生。

增強的頂點索引表示

相比于使用傳統(tǒng)的CSR/CSC，使用Bitmap和雙壓縮的稀疏列可以減少19.4%-24.3%的內(nèi)存。

負載均衡

Gemini的分區(qū)策略比只按照頂點或邊的劃分性能更高。

三種節(jié)點內(nèi)負載均衡策略的性能對比：

靜態(tài)的多核工作分區(qū)不能確保多核性能的有效利用，每個core預先計算和working-stealing的結(jié)合更完美。

總結(jié)

以上是生活随笔為你收集整理的Gemini论文笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。