舎路(シアトル)日記

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

またしばらく、Twitter を英語しばりにすることにした。

はるか昔に読んだ、Eric S. Raymond のハッカーになろうで、

ハンドル名にまつわる問題については、もうちょっと詳しく書いておきましょうか。ハンドルの陰にアイデンティティを隠すのは、クラッカーや、warez d00dz や、他の下等な生の形態に特徴的な、子どもじみた愚かな行動です。ハッカーはこんなことはしません。かれらは自分たちがやることに誇りを持っていて、それに本名で関わろうとします。だからもしあなたがハンドルを持っているのなら、それをお捨てなさい。ハッカー文化において、それは敗者の印にしかならないでしょう。

なんて書いてあったのと、あと憧れていた PC Unix 界隈の人々に、実名でインターネット活動している人が多かったので、インターネットではここ10年以上実名で暮らしている。いまのところすごく困ったことはない。女性とかだとまた違うだろうから、特に他人におすすめはしないけれど。

働くようになってからは、職場の人などが自分のブログを読んでしまう可能性というのが、なにをどう書くかについての、良いブレーキになっていた。一方で、ここ数年は、仕事でつきあう人々には日本語ができない人が多く、そのブレーキがあんまり働いていない。いまのところ大事には至っていないし、もちろん NDA などは守っているけれど、なにを書いても職場の人には読まれないだろうという気持ちが、細かい表現とか、自分のインターネットでの立ち振る舞いみたいなものに、変なバイアスをかけてしまっているのではないか、という不安は少しある。

というわけで、しばらく Twitter は英語しばりにすることにした。いままでも自分の中で英語しばりにしていた時期はあったんだけど、今回はもうちょっと長期間やるつもり。ゆくゆくは個人の英語圏でのブランディングをがんばりたいというのも少しあるけれど、まずは、どちらかというと、自分にとって陰口が叩きやすくなってしまったシステムを是正する気持ちです。

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 です。