舎路(シアトル)日記

シアトルで働く日本人プログラマの日記です。

Keeping Master Green at Scale (2019)

Cindy Sridharan さんが Twitter で紹介していた、Uber の分散ビルドシステムに関する論文を読んだ。

Giant monolithic source-code repositories are one of the fundamental pillars of the back end infrastructure in large and fast-paced software companies.

という力強い宣言からはじまっていて身構えるけど、ほとんどは iOS と Android むけのビルドの話です。

コミットされてからテストを走らせるんじゃなくて、テストが通ったものだけコミットする、というのはそこまで新規性のある話ではないけれど、Uber のシステム — SubmitQueue の新しいところは、あるコミットが全てのテストを通るかどうかを機械学習でもって予測して、成功しそうなコミットの組み合わせを並列にビルドしてしまう、というところにある。

機械学習といっている部分は素朴で、過去のビルド結果を使った教師つきの logistic regression (ロジスティック回帰) に、変更されたファイル数であるとか、事前に走る (明言されてないだろうけど速い) テストの結果やらを突っ込んでいる。恐ろしいことに、開発者というのも言及されているけど

Developers also play a major role in determining whether a change may succeed or not.

これはそのあとに

We also note that while developer features such as the developer name had high predictive power, the correlation varied based on different developers.

とされている。

古の昔に、人々は Commit-and-Run Is a Crime なんていったものだけど、こういう最近の成果をみると、Commit-and-Run を許すシステム自体が過去のものになるのかなあと思う。

Q1 は毎週コンピュータサイエンスがらみの論文を読んで、それを月曜日にブログに書く、というのを挑戦していた。まだ 3/25 が残っているけれど、とりあえずここまでのまとめを書いてみる。

なにを読んだか

基本的には分野を問わずバラバラに読んだけれど、全体を通してみると Empirical Software Engineering (実証的ソフトウェア工学) がらみのものが多い。これは仕事に活かせそうな部分がありつつも、それなりに距離があり、かつ Web 2.0 時代から私がひきづっている、人間のコミュニケーションに対する関心とリンクする部分があって、なかなか面白かった。

一方で、この分野の論文を色々読んでいると「みんなが薄々気づいていたことが、データでもって裏付けできました」という類の論文もたまにある。こういう論文は、学問としての価値は理解できるけれど、外野としてはあんまり見所がなく、紹介も書かないことが多かった。

もうちょっと仕事に関係のあるやつを読んでもいいのだけど、例えば職場で見かけた arXiv.org のリンクとかを個人のブログにパッと転載するのは、ちょっと憚られるものがある。「Alexa は要するに Q&A システムである」ということにして、SQuAD の leaderboard から読むものを探していったりする分には、そこまで怒られは発生しなさそう。ただ、読んで理解できるのか、という別の問題はある。

どう探すか

深掘りをするのであれば、ある論文から参照されている他の論文を読んだり、著者をたどって読んでいくのが王道だと思う。

一方で、興味を引くものを探すだけなら、USENIX の論文集 なんかは

USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins.

というのを掲げていて、PDF が簡単に読めるのが外野フレンドリーで良い。あとは大企業の論文一覧をながめるのも

結構よくて、例えば Facebook が Social Networks and Housing Markets なんて論文を出しているのは感心するものがあった。論文そのものは結構分量があって読んでいない。

一時期は Researcher なんてアプリを携帯電話に入れたりもしていたけど、これはやりすぎかなと思ってアンインストールした。

どう書くか

The Morning PaperMisreading Chat が人々の期待値をだいぶあげている2019年だけど、そういうのはあまり気にせずに、ブログに雑に書くだけにした。

日本語で書くのは、書きやすさはあるけれど、職場の人やらに「毎週論文を読んでいるんですよ」と自慢できる機会は、ことアメリカに住んでいると逃しがちで、そこは微妙だった。

いつ読むか

会社のプリンターで印刷して、通勤のバスの中で読んでいた。

Q2 も継続するのか

論文読み自体はささやかな趣味として継続してもいい。記録をつけるのも良い。日本語で書くのと、毎週のノルマに関しては、再考してもいいかなと思う。

論文を毎週読むこと自体が、全体的に、自分でも何を期待しているのかよくわからない行為であった、という反省はある。

枯れ木も山の賑わいでブログを更新したいのか、個人的なブランディングなのか、転職に役立てたいのか、もうちょっと目的意識をもってやることを決めるべきだ、という気もするし、そういう色々を考慮することで、中年はインターネットから消えていくのだ、という気もする。

Machine Learning at Facebook: Understanding Inference at the Edge (2019)

機械学習というとサーバー側でやるイメージが (少なくとも私には) あったけれど、Facebook は推論なら端末側でもやるんですよ、という話。分量としては Android が辛い話が7割、Oculus のような自分たちで制御できる環境が2割、iOS が1割くらいの感じです。

However while most Android devices ship with OpenCL drivers, OpenCL is not officially a part of the Android system, and they do not go through the same conformance tests as OpenGL ES and Vulkan. As shown in Figure 5(a), a notable portion of Android devices ship with a broken OpenCL driver. In the worst case, 1% of the devices crash when the app tries to load the OpenCL library. The instability of OpenCL’s library and driver makes it unreliable to use at scale.

つらみ… そもそもモバイルの GPU はそこまで速くないのもあって、推論は CPU で走らせがちらしいです。

In a median device, the GPU provides only as much theoretical GFLOPS as its CPU. 23% of the SoCs have a GPU at least twice as performant as their CPU, and only 11% have a GPU that is 3 times as powerful than its CPU.

The benefits and costs of writing a POSIX kernel in a high-level language

Go で POSIX なカーネルを書いてみたよ、という論文。研究目的で開発されて、高級言語で書かれたカーネルというのは色々あるけれど、それらには研究として新しいアイデアが盛り込まれていたりして、例えば性能の評価をするにしても、言語よりはアイデアの評価という側面が強い。対して、著者らが実装したカーネル Biscuit は伝統的なモノリシックの POSIX/Unix カーネルで、ベンチマークでも Nginx や Redis なんて見知ったプログラムが使われている。

GC があるのは当然なんだけど

Goroutine scheduling decisions and the context switch implementation live in the runtime, not in Biscuit. One consequence is that Biscuit does not control scheduling policy; it inherits the runtime’s policy.

Goroutine のスケジューリングが、そのままカーネルのスケジューリングになっているあたりは、Go らしさがあって面白い。

ちなみに、著者のうち2人は Russ Cox と共に xv6 の開発にも関わっていて、そのうちの1人 Robert Morris は、あの Morris ワームの Robert Morris です。

Discovering API Usability Problems at Scale (2018)

編集中のソースコードのスナップショットを定期的に取ることで API のユーザービリティの問題を見つけられるんじゃないか、という Google の人々の論文。著者らは Java のソースコードにおけるメソッド呼び出しの推移、例えば obj.a(…) を obj.b(…) に変更した、という情報を集めることで

  • コレクション (例えば ImmutableList) の of/copyOf や、add/addAll のとりちがい
  • Protocol Buffers における ByteString に copyFrom ではじまるメソッド多すぎ問題
  • Google Guava の Optional vs. Java 8 の Optional
  • Android の Logging API 自体は使いづらくないけど、ログレベルを決めるのは難しい

みたいな問題をデータでもって示している。Optional のメソッド群については論文中に推移の有効グラフがあるけれど、これは「fromNullabe あるよね… え? この Optional は Java 8 のほうだから ofNullable なの?」みたいな Java の人々のつらみが出ていて良いです。

Google 社員じゃない身としては、冒頭でふれられる

For most software development at Google, file versions are recorded automatically by a FUSE-based file system, such that every save from the developer’s editor will be recorded as a separate version. Furthermore, some editors at Google save automatically at regular intervals, such as every 30 seconds.

こういう部分も興味深い。でも FUSE でがんばるのは Mac なラップトップで開発したりするとき困らないのかなあ。