舎路(シアトル)日記

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

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 なラップトップで開発したりするとき困らないのかなあ。

「アメリカの働き方は最高! それに比べて日本は……」本当かどうか聞いてみた というのが面白かった一方、自分の実感とは違う部分もあったので書いてみる。

国単位で働き方を語る難しさについて

国、という大きな単位で働き方を語るのは難しい。会社の規模や業種によっても違いがあるし、その当時の景気や、その人の立場、住んでいる場所によっても見てきた景色は違うだろうと思う。

元の記事の最後に

※今回の記事はあくまでお二人が経験した範囲内のお話です

とあるのと同様に、これも自分が経験・見聞きした範囲の話です。

解雇

いまのところ、同僚が突然消えたりといった憂き目にあっているのをみたことはない。一方で、これは会社の景気の良い時期を体験しているだけ、という自覚はある。テック業界だと、例えば Twitter の2015年のレイオフはよく知られている。

Twitterでレイオフも体験したNY在住エンジニアが語る「波瀾万丈な人生」を楽しむ方法

2015年10月、全従業員の8%にあたる336人がレイオフされました。さまざまなチームが対象となり、僕のいたチームは数人を除いて全員がレイオフの対象となったのです。

ただ、日本でも労働組合のないような会社で、景気があんまりよくないと、配置転換による指名解雇もどきをするという話を見聞きしたことはある。

いきなり研修部屋へ ミクシィ不可解人事

それまで取り組んでいた業務を強制的に中断させられ、いきなりカスタマーサポートのトレーニングを強いられる──。これは、退職勧奨のための、いわゆる「追い出し部屋」ではないのか。

ドワンゴは大量退職に関する印象操作をやめろ

最後は総務部を追い出し部屋にしたことです。やめさせたい人間をグループウェアから登録解除し、総務部という名前を持った統合思念体に統一し、PCも共有で1台しか与えない。昨日までエンジニアをしていた人間がスーツを着て社内を歩いて備品の補充をする。そんなことが許されていました。

なので「日本の雇用が守られている」といっても、この程度のことは雇用者側から見るとアリなんだよ、というのは書いておきたい。

残業

日本でも少し前にホワイトカラーエクザンプションに関する議論があったけれど、アメリカでは Fair Labor Standards Act に Computer Employee Exemption というのがあって、一定以上の給与をもらっているプログラマは、すでに残業代規制の対象外になっている。残念。

定時という概念が希薄で、タイムカードとか押さなくて良いのは気楽ではある。

教えて育てる

これが、個人的に一番ギャップを感じたところだった。私の周りの人々は mentorship というのが好きだし、求人サイトを “mentor” で検索すれば

Ability to mentor team members as well as build relationships with business and technical leadership

みたいなことが募集要項に入っていることも多々ある。ただこれも、企業の文化であるとか、インターンを雇うくらいの余裕がある規模とか、そういったものに左右されるのかもしれない。

フェアネスと合理性

フェア、というのはアメリカの人々には大事な概念らしいのだけど、日本人の私にはその重さが今ひとつわからなくて、あんまり日常では使わないようにしている。”it is an unfair comparison” というより、”it is not apples-to-apples” くらいにしておいた方が波風が立たなそうな気がする、けど思い込みかもしれない。

セーフティーネットがないのを「合理的」と呼んでいいのか、というのは議論があるところで、例えば、最近人気のある Alexandria Ocasio-Cortez 下院議員は、深夜番組のインタビューで「最低賃金を引き上げるのは経済的にもプラスの効果がある」という話をしていた。彼女はそもそも、社会として医療保険を提供することや、労働組合の重要性を訴える Democratic Socialists of America に所属していて、民主社会主義派を名乗るくらいなので、政策も左側に傾いている。

そういう主張がそれなりの支持を集めているのは、私は良いことだと思っているけれど、もしかすると政治の二極化が進んでいるだけと見る人もいるかもしれない。

Code Ownership and Software Quality: A Replication Study を読んだ。マイクロソフトのコードベースを対象に、オーナーシップと品質との相関を調べた論文。先行する研究として

の二つがあり、この論文はそれらをうけて、1) マイクロソフトのコードベースを対象に 2) バイナリよりも小さい粒度 (ファイルやディレクトリ) で、その相関を調べている。結論からいうと、オーナーシップと品質にはやっぱり負の相関があったらしい。

ソフトウェアないしコンポーネントのオーナーシップというのは、ひとえには決めづらい。論文では

  • ownership: もっともコミットした数が多い人が、全コミットのうちに占める割合
  • minors: コミット数が50%未満の人の数
  • minimals: コミット数が20%未満の人の数
  • contributors: コミットした人の数
  • avgownership: ownership のディレクトリごとの平均
  • manager3: コミットした人々のユニークな Level 3 マネージャーの数

などなど色々なメトリクスでもって、なんとかオーナーシップの強さ、というのを求めて、それとファイルやディレクトリごとのバグの数とを比較するべく、ランク相関 (Spearman 相関) を求めている。ちなみに Level 3 というのは

For Microsoft, we can infer that managers represent at level 3 company divisions, at level 4 broader product teams, and at level 5 smaller sub teams within product teams.

部長、くらいのところなんでしょうか。

企業からの論文で、かつバグについての話だというのに、Office, Office 365, Exchange, Windows なんてフラッグシップな製品について実名をあげて論じて、さらに

With Office, we could see that there are two types of weak ownerships: intentional weak ownership, which was due to the aforementioned reasons, and unintentional ownership.

こういう不都合なこともちゃんと書くのは、なかなかえらいなあと思う。