最近読んだもの 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)
小川一水さんのSF小説。
SF小説というのは誤解を恐れずざっくり分けると、①現代社会と地続きの近未来、②現代社会と切り離された遠い未来、があると思いますが、この小説は前者。極地建設を得意とする民間企業が、資産家の企業オーナーから月面施設の建設を依頼されるという話。
地続き近未来系のSF小説は、「技術的なディテールが正確であること」と、「そこに少しだけ飛躍した画期的な技術／発見がある」ことが大事なところです。そして、その「キモ」が、いかに「ありそうだけど無い」という絶妙のラインであり、そして実際の技術的ディテールと融合するか、というのが小説の見どころですね。
UCXを試す日記(10)：バグ報告をした
自分でプログラムを書いていてハマったのでTwitterに（日本語で）グチグチ書いていたところ、中の人（たぶんORNL）の人から「バグ報告しなよ」と背中を押してもらいました。
UCXで簡単なsend/recvができるコード書いていろいろ試しているけど、ib/rc はちゃんと通信成立する一方で ib/ud は受信できない。ちょっと下の仕組みをわかってないのでつらい。
— Keisuke FUKUDA (@keisukefukuda) 2018年8月23日
It is best to ask it on our github :) but most likely you are trying to post some op and the network does not have enough resources
— Pasha (@pasha_sh) 2018年8月23日
ということで、Issueを作成。
中の人が修正するPRを作ってくれたのだが…いまいち会話が噛み合っていないので、自分で直したほうが良さげな感じもしつつ…
引き続きコードを読んでいきます
続報：直してもらいました
UCXを試す日記(9)：allreduceを実装する上での予備調査
とりあえず、UCXで実用（？）コードを書いてみようということで、Allreduceを書いてみようと思っています。Allreduceは、ディープラーニングにおいては重要な通信パターンで、業務においても研究したことがあるので経験があります（これについては、近々会社のブログの方で発表できると思います）。
Allreduceを実装するにはいくつかのポイントがあることがわかっていますので、これを先に調査しておきます。
send/recv通信として, bcopy と zcopy のどちらを使うか
いわゆる普通のsend/recvを実現する手段としては、bcopyとzcopyがあります。bcopyとzcopyの違いはわかりにくいですが、このページによると、
bcopy：転送を直ちに開始するか、失敗かの２通りの結果しかない。失敗とは、sendするローカル側のリソースが不足している場合で、UCS_ERR_WOULD_BLOCKが返される。この場合、Endpointの作成時にUCT_FLAG_PENDINGとコールバックを設定しておくと、リソースが利用可能になった時点でこのコールバックが呼ばれるzcopy：bcopyの動作に加えて、UCS_INPROGRESSを返すことがある。この場合、通信は非同期に行われ、完了時にuct_ep_am_zcopyの引数に指定したコールバックが呼ばれる。
ということで、非同期通信モデルである zcopy が良さそうです。気になるのは、bcopyのメモリコピーに関する動作がはっきり書いていないところです（bが何を意味するのかよくわからない）。zcopyのzはZeroだろうと思われるので、逆に考えるとbcopyはゼロコピー性は保証されていないのかな…？ソースを読む必要がありそう
通信の順序が保証されるか？
MPIおよびInfinibandでは、通信の到着順は保証されています。これが入れ替わってしまうと、Ring-Allreduceが成り立たないので注意が必要です。下のレイヤがInfinibandであれば自動的に（事実上）保証されることになるでしょうが、APIとしての保証がない場合、例えば下のレイヤをTCPに変えたら動作が変わって動かなくなる、みたいなことになりそうなので注意が必要ですね。
UCTとUCPのどちらを使うか？
UCXには、通信を実現するAPIのレイヤとして UCPとUCTがあります。UCTは、固有のAPIに近い、薄いレイヤを提供するので、特定の機能がサポートされているかどうか、などのフラグによる分岐をユーザーが書く必要があります。一方でUCPは上位の機能を実現するレイヤでタグマッチングなどが実装されています。インターフェースがサポートしない機能はエミュレーションするように実装されているようなので、便利そうではあります。
その場合、 * UCPのオーバーヘッドはどれくらいか？ * UCPのエミュレーション機能は、現段階でどれくらい実装されているのか * UCPのみで実現されている機能が必要か？
ということだけど…
以上の点を調査する必要がありそうですが、とりあえずInfinibandを前提にした高速な実装を目指そうと思うので、これらの調査は先送りしようと思います。
