Gemini论文笔记
論文地址:osdi16/osdi16-zhu.pdf
介紹
(1)Gemini采用稀疏-稠密、信號-槽抽象,將push-pull混合模型從共享內(nèi)存擴(kuò)展到分布式場景。
(2)基于塊劃分模式,是一種低開銷的擴(kuò)展設(shè)計(jì)同時保持了頂點(diǎn)的局部訪問。
(3)采用壓縮頂點(diǎn)索引的雙模式
(4)基于NUMA感知的子分區(qū)使節(jié)點(diǎn)內(nèi)的訪問更加高效
(5)位置感知的塊劃分和細(xì)粒度的work-stealing同時提高了節(jié)點(diǎn)內(nèi)和節(jié)點(diǎn)間的負(fù)載平衡。
圖處理抽象
頂點(diǎn)保存信息,邊是不可修改的對象。
支持雙向邊和單向邊,雙向邊轉(zhuǎn)化為一對有向邊。
圖處理的執(zhí)行時通過頂點(diǎn)沿邊的更新,知道圖狀態(tài)收斂或者達(dá)到指定的迭代次數(shù)。
活躍頂點(diǎn)是將要更新的頂點(diǎn),活躍邊是活躍頂點(diǎn)的出邊。
雙更新傳播模型
在圖處理過程中,活躍邊可能是dense或sparse。
例如CC在開始的時候是dense,經(jīng)過幾次迭代之后大部分的點(diǎn)接受到他們最終的label就會變?yōu)閟parse的狀態(tài);SSSP開始的時候是sparse,活躍頂點(diǎn)增多就會變成dense,當(dāng)算法接近收斂再次變?yōu)閟parse狀態(tài)。
sparse更適合用push模式(更新沿著活躍點(diǎn)的出邊傳遞),dense更適合pull模式(頂點(diǎn)的更新通過搜集入邊頂點(diǎn)的狀態(tài))。
Gemini采用Ligra提出的一種在push和pull自適應(yīng)切換的方法,閾值為∣E∣20\frac{|E|}{20}20∣E∣?,區(qū)別在于Gemini將進(jìn)行分區(qū)并分布到多個節(jié)點(diǎn)上,通過顯式的消息傳遞進(jìn)行通信和更新。
基于塊的分區(qū)
上圖的例子是將圖上6個點(diǎn),平均分為3個部分(白色為master,黑色為mirror),在dense模式下每個分區(qū)的mirror節(jié)點(diǎn)是分區(qū)中節(jié)點(diǎn)的出邊鄰居節(jié)點(diǎn),這些mirror節(jié)點(diǎn)采用pull聚集當(dāng)前分區(qū)節(jié)點(diǎn)的狀態(tài),然后更新遠(yuǎn)端的節(jié)點(diǎn)。
采用塊劃分可以很容易的通過邊界判斷節(jié)點(diǎn)的隸屬關(guān)系,同時也簡化了頂點(diǎn)數(shù)據(jù)表示,每個節(jié)點(diǎn)只負(fù)責(zé)實(shí)頂點(diǎn)數(shù)組的擁有部分并將其分配在連續(xù)的內(nèi)存頁中,不需要壓縮頂點(diǎn)狀態(tài)的空間消耗。
雙模式的邊表示
Gemini使用CSR和CSC表示圖的狀態(tài),每個分區(qū)對邊進(jìn)行編號,sparse是指向分區(qū)的邊,dense是當(dāng)前分區(qū)指出的邊。
通過Bitmap輔助sparse模式下的CSR的表示,標(biāo)記指向當(dāng)前分區(qū)的點(diǎn),方便后續(xù)的判斷。
采用雙壓縮輔助dense模式下的CSC的表示,保存當(dāng)前分區(qū)指出的點(diǎn)vtx和對應(yīng)邊的偏移量。
位置感知的分區(qū)
Gemini的圖分區(qū)同時考慮了頂點(diǎn)的局部性和邊的密集型,根據(jù)α∣Vi∣+∣EiD∣\alpha|V_i| + |E_i^D|α∣Vi?∣+∣EiD?∣來進(jìn)行劃分,α=8×(p?1)\alpha = 8 \times (p-1)α=8×(p?1)。
NUMA感知的子分區(qū)
利用NUMA的內(nèi)存訪問特性,在每個節(jié)點(diǎn)繼續(xù)對圖進(jìn)行劃分,來減少遠(yuǎn)程CPU內(nèi)存的訪問。
協(xié)同調(diào)度
Gemini將集群中的節(jié)點(diǎn)通過MPI組成一個環(huán),使計(jì)算和通信重疊。
對于第一個分區(qū)來說的調(diào)度來說,共分為三個階段,Batch沿著分區(qū)編號遞增的方向發(fā)送,沿著分區(qū)編號遞減的方向接受。
細(xì)粒度的Working-Stealing
雖然節(jié)點(diǎn)間的負(fù)載均衡通過Gemini的局部塊劃分來保證,但是當(dāng)分區(qū)變小就不能很好的保證分區(qū)的平衡。
基于塊分區(qū)方案可以對連續(xù)的頂點(diǎn)進(jìn)行處理,提高了緩存利用率和消息批處理,結(jié)合OpenMP,Gemini的每個線程首先完成自己core的分區(qū)任務(wù),然后通過原子操作獲取其他分區(qū)的任務(wù)進(jìn)行處理,這樣雖然帶來了一些開銷,但是提高了節(jié)點(diǎn)內(nèi)部的負(fù)載平衡。
作者的實(shí)驗(yàn)環(huán)境是 8 nodes, 2 sockets per node, 12 cores per socket, and 64 vertices per mini-chunk。
實(shí)驗(yàn)
作者使用了5種算法進(jìn)行測試: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進(jìn)行對比。
使用的數(shù)據(jù)集為:
在單個節(jié)點(diǎn)上Ligra、Galois、Gemini的對比:
Gemini在PR和BC上比其他系統(tǒng)性能好,在CC、SSSP、BFS上處在第二。
因?yàn)镚emini消息抽象(signal-slot)帶來了額外的開銷,尤其是計(jì)算任務(wù)少的算法(BFS),而其他系統(tǒng)訪問活躍頂點(diǎn)的所有邊,創(chuàng)建和活躍邊成正比的成本,有效地掩蓋了消息生成的開銷。
另外其他的系統(tǒng)采用共享內(nèi)存,可以很快的獲取頂點(diǎn)最后的狀態(tài),而基于BSP通信機(jī)制的Gemini則需要經(jīng)過多個迭代,存在滯后性。
在8個節(jié)點(diǎn)上的運(yùn)行對比:
可以看出Gemini在不同算法和數(shù)據(jù)集上的運(yùn)行速度遠(yuǎn)高于其他系統(tǒng),最高有39.8x的提升。
在8個節(jié)點(diǎn)運(yùn)行的內(nèi)存消耗:
雖然Gemini需要存儲兩份邊的信息供spare和dense模式使用,但是實(shí)際的內(nèi)存得到很好的控制。
節(jié)點(diǎn)內(nèi)的擴(kuò)展性對比:
使用COST metrix得到Gemini需要3 cores才能超過優(yōu)化過單線程的性能。
Gemini可以在2、4、8 cores下實(shí)現(xiàn)1.9、3.7、6.8倍的速度提升。
隨著core的增加,core之間的負(fù)載均衡成為性能提升的挑戰(zhàn),Gemini仍然可以在12、24cores下帶來9.4、15.5倍的提升。
節(jié)點(diǎn)間的擴(kuò)展性對比:
上圖是Gemini與擴(kuò)展性表現(xiàn)最好的開源系統(tǒng)PowerLyra的對比。
在weibo-2013上Gemini和PowerLyra的擴(kuò)展性相當(dāng),都是接近線性的增長。在小圖wnwiki-2013兩個系統(tǒng)表現(xiàn)的都不好。
在twitter-2010上Gemini在4個節(jié)點(diǎn)后擴(kuò)展性很差,主要和頂點(diǎn)的索引訪問和消息的產(chǎn)生/消費(fèi)的瓶頸。隨著節(jié)點(diǎn)的增加,每個分區(qū)的頂點(diǎn)數(shù)和邊數(shù)都能顯著減少,但是分區(qū)的mirror節(jié)點(diǎn)不能很快的減少,這就增加的處理的成本。
設(shè)計(jì)選擇
對于Gemini的幾個主要的設(shè)計(jì),很難比較其中個別設(shè)計(jì)的貢獻(xiàn),而且當(dāng)逐個添加這些優(yōu)化到基準(zhǔn)系統(tǒng)時,測試的表現(xiàn)收益取決于使用的順序。
自適應(yīng)的sparse/dense雙模式
從圖中可以看出,sparse和dense的性能差距十分顯著,PR適合dense模式,CC開始適合dense模式當(dāng)大多數(shù)節(jié)點(diǎn)保持活躍時適合sparse模式,對于SSSP,sparse在大多數(shù)迭代中更優(yōu)于dense模式,除了許多頂點(diǎn)被更新的迭代。
Gemini可以采用更優(yōu)的模式,在76次迭代的CC種有2次的誤選,在172次迭代的SSSP有5次誤選。這些誤選都是發(fā)生在兩種模式中間。
基于塊的分區(qū)
chunking和hash(x % p)的性能對比:
多種分區(qū)方法的預(yù)處理和執(zhí)行的時間對比:
有無NUMA的對比:
在不使用socket-level子分區(qū)的情況下,交錯的內(nèi)存分配保留對圖拓?fù)?#xff0c;頂點(diǎn)的所有訪問狀態(tài),以及跨兩個套接字分配的消息緩沖區(qū)。 相反,應(yīng)用套接字級別的子分區(qū),遠(yuǎn)程內(nèi)存訪問已顯著減少,因?yàn)?br /> 它們僅在working-stealing或訪問其他套接字產(chǎn)生的消息時發(fā)生。
增強(qiáng)的頂點(diǎn)索引表示
相比于使用傳統(tǒng)的CSR/CSC,使用Bitmap和雙壓縮的稀疏列可以減少19.4%-24.3%的內(nèi)存。
負(fù)載均衡
Gemini的分區(qū)策略比只按照頂點(diǎn)或邊的劃分性能更高。
三種節(jié)點(diǎn)內(nèi)負(fù)載均衡策略的性能對比:
靜態(tài)的多核工作分區(qū)不能確保多核性能的有效利用,每個core預(yù)先計(jì)算和working-stealing的結(jié)合更完美。
總結(jié)
以上是生活随笔為你收集整理的Gemini论文笔记的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 滑动窗口/二分 - 尽可能使字符串相等
- 下一篇: pybind11简单使用