SC19に参加しました

これは、eeic(東京大学工学部電気電子・電子情報工学科)Advent Calendar 2019の10日目の記事です。

こんにちは、τ研M1のtkygtr6です。
 SC19という国際会議に先日参加してきたので、その紹介と感想を書こうと思います。

SCとは

SC (Supercomputing Conference) とは、文字通りスーパーコンピューティングの一流国際会議です。 高性能計算 (HPC) に関わるシステム、計算手法、ネットワーク、ストレージなどをスコープにしています。 スパコンの耐障害性や、スパコン運用データの分析のようなものも含まれます。 世界のHPCの研究者が集結して交流を行う最大の会議といわれます。

SCの査読プロセスは最大で2回のリバッタルを含み、採択された後に提出するカメラレディではリファレンス抜きで最大12ページの論文となります。例年の採択率は20%前後で、今年の採択は87/339 (25%) と採択率だけみるとやや高めでした。 ちなみに、第一著者で日本人と思われる名前の人はざっと見た感じだと3人だけでした。

SCは会議だけではなくて、後述するエキシビジョンを始めとしたお祭り要素も大きく来場者は一万人を超えます。


会場はアメリカで発表されることが恒例になっていて、今年は デンバーが開催地に選ばれました。 デンバーは内陸で乾燥していて、年間300日が晴れという気候です。 僕はじめじめしているのが無理なので、喉がちょっと痛くなったことを除けば、毎日最高な気分で過ごせました。

今年のスケジュールは11月17日から22日までの6日間で、コロラド会議場で開催でした。 会期中はデンバーのメインストリートのいたる所にSCの旗が立っていて、SCが巨大な会議であることが感じられてワクワクしました。

f:id:tkygtr6:20191215005329j:plain

f:id:tkygtr6:20191215005340j:plain

6日間のうちの最初の2日間はチュートリアルで、HPCに関係する有名な言語、システム、ツールなどについてのハンズオン付きの講義を、開発者直々に受けることができます。 チュートリアルの種類は30種類くらいあって選ぶのになかなか苦労しましたが、聞けなかったものについてもスライドが配布されるのがうれしいです。

僕は迷った末、OpenMPのタスク並列HPC向け性能分析ツールの二つのトピックを選択しました。 どちらもなんとなく知ってはいたものの腰を据えて勉強したことはないトピックだったのですが、スライドが丁寧で基本的なところから説明してくれるので理解がはかどりました。 具体的にはOpenMPのtask dependency, tasklopp construct、性能分析ツールの方はTAU, Scalasca, Score-Pなどの使い方を学べました。

f:id:tkygtr6:20191215015934j:plain
発表する研究室同期

次の3日間はメインのテクニカルペーパーの発表で、今年は(ほぼ)3トラックで開催でした。 トラックと論文一覧はおなじみのdblpをみるとわかりやすいと思います。 SCには専用のアプリがあるのですが、どのトラックに出席するか決める際に非常に有用でした。
発表者の中には超高速で話す話者がいたのですが、たどたどしく話すノンネイティブと思われる質問者に対してもそのスピードを緩めることをしなかったので恐ろしいなあと思ったのを覚えています。面白かった論文紹介は記事の後半に書きます。

最後の残りの1日は午前中のみのワークショップ、というスケジュールです。 他に、BoF(Bird of a Feather)というあるトピックについて専門家が語りあうコーナーもあり、白熱した議論が繰り広げられます。 ユーザーレベルスレッドと、MPIライブラリの一つであるmpichなどのBoFに参加したのですが、研究者が未来を語る能力はすごいなあという気持ちになりました。

SCの楽しいイベント

SCはメインのテクニカルペーパーの発表が素晴らしいのはいうまでもないですが、その裏側でエキシビジョン展示が派手に行われることで有名です。 エキシビジョンでは企業や大学がブースを設置して、新製品の展示や研究成果の発表を行っています。

f:id:tkygtr6:20191215010838j:plain

f:id:tkygtr6:20191215005400j:plain

でかいコンピュータやその部品の展示に囲まれてぶらぶらしているだけでテンションが上がって楽しいです。 手品をやっていたり、インタラクティブな催しものをやっているブースもあり、活気にあふれています。 ランチの時間帯に行くと、色々食べながら話を聞けるらしいと聞きました。

せっかく海外に来たからにはと思って色々と話しかけては見ましたが、やはり商談がメインであり、学生はメインターゲットではないなあという印象でした。 「大学で買うことがあったら連絡してくれ」みたいなことを言われてしまい、冷やかしですまんな、という気持ちになりました。

f:id:tkygtr6:20191215005351j:plainf:id:tkygtr6:20191215005421j:plain

SCの公式イベントが終わった後には、毎日どこかしらの企業が無料で参加できるパーティを開いていて、またこれも楽しいです。 僕はスパコンCray, インターコネクトのMellanoxのパーティに参戦しました。 Microsoft, Intel, Nvidia, AMDなどのお偉いさんの挨拶を聞いて、スケールのでかさにぶち上がったりしていました。

余興として現地のコメディアンが出てきて、小道具無しトークオンリーのコメディを一時間弱ほどやってましたが、一ミクロンもわからなかったです。 国際会議という世界各地から人が集まるイベントではあるのですが、こういうのをチョイスするあたり、HPCがアメリカが中心ってことなんでしょうね。

TOP500

SCは世界の高性能なスパコンランキングのTOP500が発表されることも大きな特徴です。 発表される指標は、HPL, HPGC, Green500の三種類です。

まず、HPLは古くからスパコンランキングの測定に使われている指標であり、連立一次方程式のベンチマークを実行した時のFlops(浮動小数点演算数/sec)を測定するものです。狭義のTOP500といえばこれのことを言います。 ただし、HPLは密行列を使って計算を行うので計算律速になり、最近のアプリケーションの傾向にあっていないとの指摘もあるようです*1

それに対してHPCGはやや新しい指標となります。 HPLと同じく連立一次方程式を解くのですが、使われる行列が疎行列でメモリ律速となってそれほど性能が出ないようになっています。 実際、今年のランキングの理論性能比を見てみると、 HPLは70%以上出ているものがあるのと比較して、HPCGは1%前後のものが多い印象です*2

今年の結果のリンクを貼っておきます。

November 2019 | TOP500 Supercomputer Sites

HPCG - November 2019 | TOP500 Supercomputer Sites

今年のHPLとHPCGのランキングの結果は、トップの3つが去年と変わらない、IBM Summit(アメリカ), Sierraアメリカ), Sunway TaihuLight(中国)という結果になりました。 デナードスケーリングが終わりスパコンの進歩がゆっくりになっていて、スパコンそのものの寿命が延びている、といった話をされていた気がします。 日本からは、産総研のABCIが8位、東大のOakforest-PACSが15位にランクインしています。

残る指標はGreen500ですが、電力効率 (GFlops/watts) でランクづけします。 今年は富士通の富岳がトップになったことがニュースになりました。

f:id:tkygtr6:20191215011747j:plain

正確にいうと富岳はまだ稼働していないので、そのプロトタイプであるA64FXでランクインしているという形になります。めでたいですね!

SC19論文紹介

ここからはSC19の論文紹介のコーナーです。二本の論文を専門外の人にも理解できるようにじっくり解説します。

Compiler Assisted Hybrid Implicit and Explicit GPU Memory Management under Unified Address Space*3

一つ目の論文は、GPUのユニファイドアドレス空間の管理についてのコンパイラ支援についての論文です。

ディープラーニングの流行によって読者の皆さんの中にもGPUを使ったことのある人も多いとは思いますが、 具体的にどのようにメモリを管理しているかはご存知でしょうか? 一般的に、DLフレームワークでは隠されている部分なのですが、GPUで計算をするには明示的にCPUとのデータのやり取りをする必要があります。 つまり、まずCPUからGPUに必要なデータを送り、GPUで計算を行い、CPUに計算結果を送り返すという手続きを踏まなくてはならないわけです。

ただし、それはなかなかにGPUプログラミングコストが大きいので、最近のGPUアーキテクチャではCPUとGPUでメモリ空間を共有するユニファイドメモリ (unified memory) という種類のメモリが導入されています。ユニファイドメモリを用いると、プログラマはCPUとGPUの間でのデータの通信を明示的に記述する必要がなくなり、単一のデバイスを使用している感覚でプログラミングを行うことができます。ただし、ユニファイドメモリを使用したとしても通信自体はどこかでやらなくてはならないわけで、それはシステムが暗黙のうちに担うことになります。CPUからGPUへの通信を例に説明すると、GPUで計算を行っている時に必要なデータがないとわかるとその都度エラーを発生してやって、必要なデータを送るようにCPUに依頼するというようになるのですが、そのエラーをページフォルト (page fault) と呼び、MMUと呼ばれるハードウェアの機構で検出します。

このように有用なユニファイドメモリなのですが、主に二つの性能劣化の原因が存在します。一つ目は、先ほど説明したページフォルトのオーバーヘッドによるものです。二つ目は、GPUのメモリ量には限りがあって、それを上回る量のデータのやり取りを行う時に生じるスラッシングという現象によるものです。GPUのメモリをフルに使用している時に、ユニファイドメモリを通してさらにGPUへのメモリ転送が要求された時には、何かしらのデータをCPUに送り戻してあげなくてはなりません。通常はそのデータは最後に使用された時刻が最も遅いものが選ばれるのですが (LRUアルゴリズム) 、その選択と実際のワークロードがマッチしなかった場合にはある種のデータがCPUとGPUの間を頻繁に行き来することになります。これをスラッシングと呼び、そのデータに関する処理が極端に遅くなることになります。

この二つの性能劣化の原因を解消するために、コンパイラの手助けを借りて、ユニファイドメモリを使用して書かれたステートメントをいい感じの明示的な通信に変換して性能を向上させよう、というのがこの論文の提案です。ただ闇雲に変換しただけでは元のLRUにも勝てないので工夫する必要があるのですが、ここでは変数のアクセス密度 (access density) 再使用距離 (reuse distance) を考慮します。アクセス密度とは配列に対して定義されて、配列全体のうち実際にアクセスされる割合として計算されます。また、再使用距離とは、同じ変数が一度アクセスされて再びアクセスされるまでの距離のことで、通信の単位をまたいだ個数のようなものとして計算されます。コンパイラはこれらの情報をユニファイドメモリの使われているソースコードから抽出することで、使用される頻度の高いデータを積極的にGPUに残し、そうでないデータはCPUにすぐ書き戻すような明示的な通信に変換します。通信を明示的に発行するということはページフォルトの機構を使用しなくてよいことを意味し、また先ほど説明した情報を利用した効率的な通信の変換によってスラッシングを減らすことができるため、性能劣化を抑えることができるわけです。

最後に評価結果(の一つ)を載せておきます。miniViteというアプリを実行した時の実行時間を比較しているのですが、ユニファイドメモリをナイーブに使った場合(赤)と比較して、提案手法(紫)は性能が向上しています。

f:id:tkygtr6:20191215012709p:plain

ComDetective: A Lightweight Communication Detection Tool for Threads*4

二つ目は、共有メモリ上のスレッド間通信を検知して可視化するツールであるComDetectiveについての論文です。

現代の計算機で性能を出すためには並列計算が必須であり、今どきのCPUはコアと呼ばれる演算ユニットを複数持ってることが普通です。 並列計算の際には、CPUの各コアにそれぞれ計算を割り当てることになりますが、その計算のひとまとまりのことをスレッド (thread) と呼びます。 CPUの各コア間ではメモリは共有されているので、スレッド同士がお互いの計算結果にメモリを通してアクセスしながら計算を進めていきます。

ただし、並列プログラムは予想したほど性能が出ないということは往々にしてありがちであり、そのために性能を分析するための専用のツールが不可欠です。 この論文は、スレッド間の通信に関する情報を通信行列 (communication matrix) の形で提供するツール、ComDetectiveを提案しています。 通信行列とは、それぞれのスレッドのペアが行なった通信の回数をカウントしたものであり、LULESHというアプリを四つの別々の条件で測定してヒートマップとして可視化したものが下の図です。濃くなっている部分に対応するスレッドのペアが通信を多く行なっているということを意味しています。

f:id:tkygtr6:20191215012657p:plain

さて、共有メモリによるスレッド間通信は暗黙のうちに行われるため、検出することが簡単ではありません。似たようなことをやっている既存のツールは、シミュレーションや計測のためのコードを埋め込むといった手法を用いていますが、オーバーヘッドが大きかったり、正確さに欠けているという点で実用的とはいえません。 ComDetectiveは、ハードウェアに備わっているPMU (Performance Monitoring Unit) という計測用のユニットと、x86プロセッサに付随しているデバッグレジスタ (debug register) と呼ばれる特殊なレジスタを用いて、軽量に通信行列を生成する手法を導入し、軽量かつ正確にスレッド間通信を検出します。

f:id:tkygtr6:20191215012704p:plain

まず、PMUは、ハードウェアのイベントをカウントするユニットであり、ロードストアといったメモリアクセスやCPUサイクルなどをカウントすることができます。 PMUのカウントがある一定の回数を越えると割り込みが生じて、コールバック関数を通してその瞬間の情報を記録することができます。

ComDetectiveでは、PMUで割り込みが生じた時に(スレッドID、メモリアドレス、メモリアクセス時刻)についての情報を記録しておき、測定が終了したあとに一つのアドレスに注目してアクセス時刻で並び替えることで、スレッド間の通信を検出します。 しかしそれだけでは検知できる通信が限られてしまうことになり、ツールとしては不十分なものになります。 というのも、PMUでの割り込みはあくまでメモリアクセスの回数がある閾値を上回った時にのみ生じるので、全てのロードストアについての情報が記録されるのではないためです。 したがって、PMUを通して測定されるサンプリングされた情報だけからでは、 スレッドをまたいで複数回検出されるような、頻繁にアクセスされるアドレスに関する通信のみしか検出できないことになります。

そこで、サンプリングされる頻度の少ないメモリアドレスに関する通信を検出するのに用いるのが、デバッグレジスタです。 デバッグレジスタは格納された特定のアドレスを監視して、そのアドレスにプログラムカウンタが到達したりメモリアクセスが生じた時に、同様に割り込みを生じさせることができます。

ComDetectiveでは、PMUで割り込みが生じた時には集計用のログを残すだけではなく、そのアドレスをデバッグレジスタにも格納します。 そのアドレスに対して再びメモリアクセスが生じた時には、デバッグレジスタが割り込みを発生させるので、そのタイミングで通信を検出します。 PMU単体だと、二回目のアクセスの瞬間に、再びPMUの割り込みが偶然に生じていないと通信を検出できないのですが、デバッグレジスタを用いることで確実に二回目にアクセスする瞬間を捉えることができます。 このようにPMUとデバッグレジスタを組み合わせることで、ComDetectiveは軽量にスレッド間通信を検出します。

少し話がずれますが、システムがメモリ管理をキャッシュライン (cache line) と呼ばれる単位で行なっている都合上、各スレッドがキャッシュラインに含まれている別々のメモリにアクセスする際にも、キャッシュライン単位で通信が行われてしまうことがあります。 これをFalse Sharingと呼び、共有メモリでプログラミングをする際に注意を払わなくてはならない性能劣化の原因です。 ComDetectiveはスレッド間のそれぞれの通信が、False Sharingであるかどうかを区別して検出するということができるので、よりユーザーに対して有益な知見を提供することができます。

デンバー散策

f:id:tkygtr6:20191215005433j:plain

最終日の午後の余った時間で、Red Rocksという野外劇場に行ってきました。車で30分ほどだったのですが、Uberがとても安くて便利だったので感動しました。

f:id:tkygtr6:20191215005442j:plain

あとは夜に食べたバカでかい肉を載せておきます。

おわりに

トップカンファレンスに参戦するのは初めてだったので、毎日が刺激的であっという間でした。

それから、やはり自分の英語力はまだまだであることが身に沁みました。 早口ネイティブイングリッシュ、もごもごイングリッシュはほぼ何もわからなかったです。 まあ訛りによって英語の聞き取りやすさが全然違うというのがわかったのは実に面白かったのですが、地道に精進するしかないなあという気持ちです。

SCは日本人が多い、それも発表しない日本人が多いという話を聞いていましたが、実際その通りでした。 僕もその一員なのですが、行くことを許可していただいた指導教官に感謝です。

いつか何かしら発表するものを持ってSCに行きたいですね(メインペーパーで発表した同期をみながら)。

長くなってしまいましたが、読んでいただきありがとうございました。

*1:https://www.top500.org/news/top500-meanderings-hpcg-gains-steam-as-alternative-benchmark-for-supercomputers/

*2:https://www.hpcg-benchmark.org/custom/index.html?lid=155&slid=302

*3:Li, L., & Chapman, B. (2019). Compiler assisted hybrid implicit and explicit GPU memory management under unified address space. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis on - SC ’19 (pp. 1–16). New York, New York, USA: ACM Press. https://doi.org/10.1145/3295500.3356141

*4:Sasongko, M. A., Chabbi, M., Akhtar, P., & Unat, D. (2019). ComDetective: A Lightweight Communication Detection Tool for Threads. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis on - SC ’19 (pp. 1–21). New York, New York, USA: ACM Press. https://doi.org/10.1145/3295500.3356214