本当は怖いHPC

HPC屋の趣味＆実益ブログ

AWSのElastic Fabric Adapter

AWS re:Invent 2018において、Amazonが開発する新しいネットワークアダプタ Elastic Fabric Adapter (EFA) が発表されたようです。

HPC的なまともなアプリをスケールさせようと思うと、どうしてもネットワークがネックになります。普通のスパコンでは、Infiniband等のハイスピードインターコネクトが実装されているので、速度的には100G〜200Gくらいでるのですが、普通のクラウド環境だと一桁遅いので、通信が重すぎてちっとも計算が進まないということになります。近年、AWSを始めとしたクラウド環境はどんどんHPC分野をターゲットにしているので、スパコンなみのハイスピードインターコネクトが求められていました。

www.slideshare.net

とうとうインターコネクトもAmazonが自前開発しちゃうんですね・・・。正確には、以前に買収した企業の製品（の後継）らしいです。確かに、Infinibandをそのまま使うのは仮想化とかResource Isolation的につらいし、かといってEthernetでRoCEか？というとそれも違うよねーということで独自開発という感じでしょうか。実績と柔軟性だけみれば100G Ethernetですが、対応スイッチは高いし（IPのパケット処理は重いので）、RDMAとかを考え出すとつらい（RoCEはRoutingのデッドロック等の問題があり運用がつらいらしい）とか…。いろいろありそうです。

EFAの特徴としては

  • インターフェースはlibfabric
  • MPIからの利用を想定
  • c5nインスタンスの中からENA（Elastic Network Adapter??）が見えて、それが実際にホスト上に存在するアダプタにマッピングされる（という図に見える）
  • （HPC network performance with EFAというページでは、MPI multistreamの性能評価の結果らしきものが掲載されているが、軸の説明がなにもないのでよくわりません。横軸は並列数かな？）

というあたりでしょうか。また、通信の種類としては、

  • RDM: Reliable unordered datagrams, タグマッチング無し
  • DGRAM: Unreliable unordered datagrams with flow limit
  • RxR: libfabric interface over RDM, 完了順序保証, タグマッチングあり、Max MessageSizeが大きい（メインメモリより大きい）
  • SRD: Scalable Reliable Datagram、順序保証なし、到着保証あり、レイテンシが桁で少ない

などがあるようです。InfinibandだとReliable datagramはあまり使うことが少ないので面白いな〜と思います。AWSのデータセンター向けに設計されたプロトコルだということで、そのあたりが関係してそう。

2019年上半期にGAということで、現在Preview申し込み受付中とのこと。

感想

インターフェースに使われているライブラリが今どきlibfabricかーと思わないことはないのですが、通信をDatagramベースにすることによって既存インターコネクトの問題点を回避してAWSに適した設計になっていると思うので、その点は興味深いです。

なお、NCCLにも対応しているとのこと。NCCLはVerbsだったはずだけどどうやってんだろ…と思ったら、普通に気合で書き直しているっぽい・・・？これから読んでみます。

GitHub - aws/aws-ofi-nccl: This is a plugin which lets EC2 developers use libfabric as network provider while running NCCL applications.

まあ、インターフェースとして提供するライブラリをどうするかというのは難しい問題ですね。今から開発するならUCXベースにするのが普通だと思いますが、数年前からずっと開発していたとなると、Verbsにするよりはlibfabricのほうが100倍マシということは同意します。

最近読んだもの 2019/01/30

不定期に、最近読んだ論文、本、Webページをメモしていきます。

論文：Taxonomist: Application Detection through Rich Monitoring Data

スパコン上で流れいてるジョブを（管理者側）から判別できると良いことがある。次世代スパコンの設計に役立つ、不正なアプリ（マイナーとかパスワードクラッキングとか）を検出して禁止できるなど。しかし、判別は難しい。なぜなら、バイナリは名前が変更されている、ユーザーが書いた複雑なシェルスクリプトから実行される、同じプログラムでもコンパイルオプションによっても挙動は変わる、から。

そこで、既存のシステムMetricsから、機械学習を用いてアプリを特定する手法を提案した。アプリケーションが実行されるときに、実行性能に影響を与えない時系列メトリクスを取得し、max, min, mean, stddev, skew, kurtosis, 5th, 25th, 50th, 75th, 95th percentile などの特徴量に加工してrandom forestで学習させた。F-score95％。

論文：GPipe: Efficient Training of Giant Neural Networks using Pipeline Parallelism

モデル並列の実装例。ミニバッチをマイクロバッチに分割して処理をパイプライン化することにより、1つのネットワークを複数のアクセラレーター上で分散実行。必要に応じてRecomputeテクニックを用いて通信量を削減。データ並列とも共存可能。パラメーター数を5.5億まで増やしたAmoebaNetを実行してImageNetでTop-1 accuracy 84.3%。４倍の数のGPUを用いて3.5倍の高速化。

  • レイヤーごとにGPUの台数を変えることができると、なお良さそう（できるのかな？）
  • この研究の評価だと8GPUだけど、もっと台数増やしてGlobal Minibatch size増やしたほうが、もっと効率良さそう。

関連：

論文：Software Engineering at Google

GoogleでのSoftware Engineeringのまとめ。 シングルリポジトリ、コード20億行、3500万コミット、毎日4万コミットを格納というGoogle社のソフトウェアがどのように開発されているかというまとめ。

コード管理、テスト、レビュー、プログラミング言語、コード品質、デバッグ、プロファイリングなどについて概要が書かれています。他にも、20%ルール（現在は廃止されているという情報もある）、OKR、人事、設備、トレーニングなどについても言及。

本：シリコンバレー式 自分を変える最強の食事

シリコンバレー式 自分を変える最強の食事

読み方が難しい本だと思いました。

本書は、いわゆるバターコーヒーの発祥の本。

この本で受け取るべきメッセージは、

  • 自分が何を食べているのかを把握し、それをコントロールし、固定し、記録し、そして自分の体調を観察しよう
  • 新しいこと（食べ物）を試すときは、食生活と体調が安定しているときに一つずつ変えてみて観察しよう
  • 常識にとらわれずに、自分の体で実験しよう（そして、この本も真に受けずに自分の体で試してみよう）

ということだと思います。本文には、この食品は良い／この食品は悪い、ということがずっと書かれていますが、それらは枝葉末節です。国が違えば食品規制も違うし、人が違えば体質も体調も違います。枝葉末節／個別の項目を真に受けるのではなく、「常識を疑い、自分自身の体と向き合い、測定と観察をもとにバイオハックをおこなおう」という本でした。これをよんで、TV番組で紹介された食品を翌日スーパーで買い漁るタイプの人は読んではいけない本。

本：第六大陸〈1〉 (ハヤカワ文庫JA)

第六大陸〈1〉 (ハヤカワ文庫JA)

小川一水さんのSF小説。

SF小説というのは誤解を恐れずざっくり分けると、①現代社会と地続きの近未来、②現代社会と切り離された遠い未来、があると思いますが、この小説は前者。極地建設を得意とする民間企業が、資産家の企業オーナーから月面施設の建設を依頼されるという話。

地続き近未来系のSF小説は、「技術的なディテールが正確であること」と、「そこに少しだけ飛躍した画期的な技術／発見がある」ことが大事なところです。そして、その「キモ」が、いかに「ありそうだけど無い」という絶妙のラインであり、そして実際の技術的ディテールと融合するか、というのが小説の見どころですね。

UCXを試す日記(10)：バグ報告をした

UCX Infiniband

自分でプログラムを書いていてハマったのでTwitterに（日本語で）グチグチ書いていたところ、中の人（たぶんORNL）の人から「バグ報告しなよ」と背中を押してもらいました。

ということで、Issueを作成。

github.com

中の人が修正するPRを作ってくれたのだが…いまいち会話が噛み合っていないので、自分で直したほうが良さげな感じもしつつ…

github.com

引き続きコードを読んでいきます

続報：直してもらいました

【広告】