Paper Introduction

1. 論文紹介
Latency‑TolerantSoftwareDistributed
SharedMemory
情報理工学系研究科電子情報学専攻M1福岡拓也
2019年7月22日
1

2. 紹介する論文について
著者:JacobNelson,BrandonHolt,BrandonMyers,PrestonBrigg,
LuisCeze,SimonKahan,andMarkOskin,UniversityofWashington
USENICATC’15で採択され、オープンアクセスである
インメモリのデータ集約型のアプリケーション向けのソフトウェア
分散共有メモリ(DSM)のGrappaを提唱
分散型のメモリを単一の大きな共有メモリとしてプログラムできる
レイテンシを犠牲にする代わりに,アプリケーションの並列性を利
用して高スループットを達成
ソースコードはGithub(uwsampa/grappa)で公開(コアとなる部分は
1.7万行)
2

3. 背景
データ集約型のアプリケーションが大規模計算で重要
広告表示、ソーシャルネットワーク分析、ページランク
マルチコアプロセッサで構成された複数のノードがネットワークで
繋がっているシステムで性能を出す必要
プログラマは明示的にデータ配置や並列性を記述する必要
多様なフレームワークの存在
既存のフレームワーク(MapReduce,Dryad,Spark)では、それぞれ
のモデルにうまく適応しないアプリでは性能が出ない
3

4. 分散共有メモリ(DSM)
分散共有メモリ(DSM)は分散しているメモリを、一つの大きな共有
メモリのようにプログラミングできるモデルのこと
プログラマの負担が小さい
ソフトウェアDSMは古くから研究がされているが、既存のものは性
能が悪い
ノード間通信のバンド幅、レイテンシの制限
特に、データに局所性が悪い場合、データの共有や粒度の粗い
同期が多い場合
既存のDSMは、現代の分析系のアプリケーションには向いて
いない
4

5. 提案システム:Grappa
データ集約型のアプリケーションに対象を絞ったソフトウェアDSM
であるGrappaを提唱
プロセッサをビジーにしてノード間通信の高いコストを隠蔽するた
めに、アプリの並列性を用いる
小さなメッセージを1つの大きなパケットにまとめることで、
バンド幅を有効に利用
その分だけレイテンシは犠牲
Grappaの特徴
グローバル空間、軽量ユーザーレベルタスク処理、集約通信レ
イヤーの、3つの主な要素から構成
分析系フレームワークをGrappa上で実装(60‑690行)して、そ
の上でアプリを動かす
ただし、そのアプリも多少の変更を加える必要がある
5

6. 6

7. Grappaのコード例
それぞれの文字数をカウントするコード例
インプットのcharの配列と、アウトプットのcellの配列は予めノー
ドをまたがっている
ただの共有メモリで実行する場合のコードとほぼ同じ書き方で実行
することができる
7

8. グローバル空間(1)ローカルメモリ,グローバ
ルメモリ
Grappaのメモリは、ローカルメモリ、グローバルメモリが存在
ローカルメモリは、システムの1つのコアのみからアクセス可
能
グローバルメモリは、特定のノードによって管理されている
ローカルデータをグローバル空間にエクスポートして、他のノード
やコアからアクセスできるようにすることが可能
8

9. グローバル空間(2)delegateoperation
リモートのノードにアクセスする際には、delegateoperationsを用
いる(システムに対して明示的に記述する)
別のノードにその部分のメモリについての操作を依頼する
9

10. 軽量ユーザーレベルタスク処理
Grappaはタスクという実行単位でコードを実行する
タスクはパラレルループ句(eachfor)で自動的に生成されて、実行す
るコードと初期状態を備えたクロージャーとして指定される(C++で
いうfunctor,functionobject)
それぞれのコアがタスクキューを持っていて、1つのタスクがユー
ザーレベルスレッドにマッピングされる
publicqueue:コアに割り当てられていないタスク用のキュー,
ワークスチーリングが可能
privatequeue:コアに割り当てられたタスク用のキュー
priorityqueue:優先度の高いタスク(通信のリクエストを定期
的に送り続けるなど)用のキュー
スレッドは長いレイテンシの操作が発行されると、自動でサスペン
ドして、その操作が終了したらシステムがそのスレッドを起こす 10

11. 集約通信レイヤー(1)
小さいメッセージを大きなパケットにまとめる
非同期のアクティブメッセージというプロトコルに基づいている
あるプロセスが別プロセスを指定してメッセージを送ると、そ
のメッセージに基づいて送信先プロセス上で処理が実行される
11

12. 集約通信レイヤー(2)
メッセージの集約
コアは発信されたメッセージのリストを管理
これらのリストはノード内部で共有されている
それぞれのコアが送信先のコアに応じてメッセージを管理
ノード内で、送信先のノード、コアについてメッセージをまと
める
メッセージの数が一定以上になるか、一定時間経過した場合、
実際にMPI/RDMAを通して送信 12

13. 実験環境
プロセッサAMDInterlagosprocessors128ノード,1ノードあたり
32コア2.1GHz
メモリ64G
インターコネクト40GbMellanoxConnectX‑2InfiniBandnetwork
cards
アドミニ権限が不要
13

14. Vertex‑centricframework(1)
Grappaのグラフ構造のライブラリを用いることで、GraphLabとほ
ぼ同じ機能を実装
Pagerank,CC(ConnectedComponents),SSSP(SingleSource
ShortestPath),BFSの4つのアプリを実装
Twitter,Friendsterの2つのグラフデータセットを対称
比較対象として、GraphLab(pds)とGraphLab(random).前者はグラ
フの配置を工夫したもの
14

15. Vertex‑centricframework(2)
平均して、GrappaがGraphLab(random)と比較して2.57倍、
GraphLab(pdf)と比較して1.33倍の高速化
rankvalueをアップデートする通信において、GraphLabは性能が悪
いことが主な原因 15

16. Vertex‑centricframework(3)
PageRankonTwitterのメッセージレートを測定してみると、
GrappaがGraphLabと比較してほぼ4倍出ている
GUPSベンチマークでMessageRateを測定したところ、Grappaが
TCPではなくてRDMAを用いているところで差が出ていると判明
16

17. Vertex‑centricframework(4)
PageRankベンチマークでスケーラビリティを比較
32ノードを超えるとスケールしないが、これはグラフのサイズが小
さすぎることに起因 17

18. Relationalqueriesframework(1)
Relationalqueriesに関して、GrappaとShark(Hiveのfast実装)を比
較
Grappaでは、全てのテーブルを分散アレイに格納し終えてから、ク
エリの実行時間を比較
Hiveでも、全てのテーブルがメモリにあることを保証
ベンチマークとしてSP2Benchを使用複数のテーブルのjoinが含ま
れている
18

19. Relationalqueriesframework(2)
Grappaがおよそ12.5倍の高速化を達成
著者曰く、2つのシステムがどこで差がついたのかを明確に理解す
ることは難しいが、Q2での要素ごとの時間の比較をみるとネットワ
ークの部分で差がついている
Grappaのデータの集約の部分が効いてきたのではないか 19

20. IterativeMapReduce(1)
k‑meansクラスタリングで比較
比較対称のシステムはSpark
データセットとして、8.9GBのSeaflowを使用
20

21. IterativeMapReduce(2)
K=10の場合は7倍ほど、K=10000の時には10倍ほどの高速化を達
成
ネットワークレイヤーから差分が生じていると予想
Kを増やすと計算律速になるため差は縮むと思われたが、実際はそ
うはなっていない
Grappaのデータの縮約と、通信と計算のオーバーラップが効
いてきたのではないかと思われる 21

22. 結論
データ集約型のアプリケーションを記述するのは、カスタマイズし
たフレームワークを作るよりも、共有メモリ環境上で行う方がシン
プルであるという発想の元、Grappaを開発
並列性が確保されてレイテンシに寛容なアプリケーションにおいて
は、Grappaは既存のフレームワークよりも柔軟でかつ性能が高い
22