blog.8-p.info

友達のやっている 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 が対応していれば¹、任意のコマンドが実行できます。
• この時点でローカルに 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 がちょっと凝っていて、実行中に、計算にかかる金銭的なコストが下に出る²のがかわいいですね。

並列数は?

これは 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 で動かすことはできると思う。