友達のやっている Misreading Chat というポッドキャストで、From Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of Transient Functional Containers について話してきました。録音された自分の声を聞くのは慣れないけれど、好きなポッドキャストなので出れてよかった!
以下、収録中にうまく説明できなかったり、調べたりなかった部分の補足です。
全体の流れ
GitHub の README.md にも貼られている、ffmpeg をコンパイルするスクリーンキャスト がわかりやすい。
gg init
で.gg/
ディレクトリを作る。gg infer make
とすると、gcc
などを、環境変数 PATH を書き換えることで gg のものに置き換えた環境で、make
を実行する。gg infer
が対応していれば1、任意のコマンドが実行できます。
- この時点でローカルに make を実行したときとおなじように
ffmpeg
という実行ファイルができる。- でも、これらは
#!/usr/bin/env gg-force-run
というのがついたシェルスクリプトで、本当の実行結果ではない。 - この時点で gg IR で出来た “thunk” と呼ばれるファイルも、ローカルに作られます。
- でも、これらは
- ここで
gg force ffmpeg --jobs 2000 --engine lambda
などとすると- まずは thunk をクラウドにアップロードして
- force サブコマンドの引数になっている
ffmpeg
の thunk をクラウド上で評価して - それに必要な thunk も再起的に評価されていって
- 最終的に本物の
ffmpeg
がクラウド上で作られて
- それがクラウドからダウンロードされて、ローカルの
ffmpeg
が本物に入れ替わる
という動作をしています。UI がちょっと凝っていて、実行中に、計算にかかる金銭的なコストが下に出る2のがかわいいですね。
並列数は?
これは 5. Evaluation のところに記載があって、
- コンパイル: Chromium の場合 8,000 (5.2.3)
- ユニットテスト: 8,000 (5.3)
- 動画エンコーディング: 記載なし
- 物体認識: 記載なし
となっています。ちなみに、Lambda 自体の並列数は、デフォルトで 1,000 だけど、申請すれば “hundreds of thousands” まであげられます。
自分のプログラムを gg で動かすのって大変なの?
gg のレポジトリの中に、フィボナッチ数を計算する例があるけれど、これを見ると大体雰囲気がわかると思う。
ここでは、add
と fib
という二つの実行ファイルを作って、それを gg で実行している。
add
のほうはファイルから数字を二つ読み込んで、それを足すだけのプログラムで、特に面白いところはない。
fib
のほうは gg の SDK を使っていて、fib(n-1)
を計算する thunk と、fib(n-2)
を計算する thunk を作って、それを前述の add
に渡す、という動作をしている。ここで、個々の thunk から再起的にまた thunk が作られていくんだけど、その再帰的に thunk を作る部分がクラウドで実行されていて、ローカルで計算に必要なグラフを作りきらなくてもいいのが、gg の見所のひとつだと思う。
この実行ファイルの切れ目が、そのまま分散して実行されるときの単位になる、というパラダイムにのれれば、自分のプログラムを gg で動かすことはできると思う。
- 論文では、これを “model substitution” と呼んでいます。src/models/wrappers の下に、例えば gcc という名前だけど model-gcc を呼ぶだけのシェルスクリプトが、その上のディレクトリに実際の model-gcc の実装があります。 ↩︎
- engine_gcloud.cc のほうはゼロで決め打ちになっているけど。 ↩︎