The State of Machine Learning Frameworks in 2019

ML 再入門するにあたって TF2 やるか・・・しかしやりたくない・・・という気持ちを察したかのような記事で、やはり PyTorch の方が良さそうと背中を押された。

TF2 の PyTorch に対する敗北には色々感じ入るものがある。基本的には Facebook の中の人ががんばった、えらかった、でおしまいなのだけれども、負け方に既視感を感じる。

最初に思ったのは、これは MapReduce (Hadoop でもいいよ) の Spark に対する敗北に似ているな、ということ。MR は Mapper と Reducer (ついでに Partitioner と Combiner だっけ?) というわりかし剥き出しのプリミティブをプログラマに強いることで堅牢な並列計算を実現したが、より親しみ深い抽象と対話的実行を備えた Spark にやられた。その後 MapReduce には Flume (Beam)なり Hive なりといったマシな抽象が与えられはしたものの、安い計算資源をバッチで使う根本のところは変えられず対話性はないままだったし、どのみち遅きに失し今日に至っている。

TF1 はデータフローのグラフというわりかし剥き出しのプリミティブをプログラマに強いることで並列実行やら最適化やらのコンパイラテクノロジを ML フレームワークに持ち込むことができた。しかし Python の親しみ深さを活かしつつ tape-based すなわち operator overloading で計算トラックすればいいでしょと対話的実行を後押しする PyTorch にやられた。TF2 は対話的実行デフォルトに方針を切り替えたけれど、相変わらず複雑なデータフローのグラフすなわち SavedModel が canonical representation である重苦しさは拭えない。

難しい問題を解くため最低限の抽象を頼りに剥き出しの複雑さと向き合う Jeff Dean 的アプローチにはハイテク企業らしさがあって、自分はけっこう好きだ。けれどコミュニティとかエコシステムみたいなものを相手にする必要があると、そういう荒削りさが足を引っ張る。プログラマへの優しさが計算資源への優しさを打ち負かす。そして競争に勝ってマインドシェアを獲得すると、計算機への優しさは事後的に解決されたりする。

もうすこし自分に身近な例で考えると、これは Mozilla (Gecko) の WebKit に対する敗北とも似たところがある。Gecko は XPCOM や XUL などクロス環境かつクロス言語でアプリケーションを作れる仕組みを目指したが、MacOS べったりで C++/Objective-C から HTML をかけるだけの WebKit に敗北した。

これらを「古くて巨大で複雑なテクノロジが新しくて小さく気の利いたテクノロジに負けた」ストーリーとして解釈するのは近似としてはあっている。でもそういう雑でメタな話は Malcolm Gladwell と Clayton Christensen にまかせ、ソフトウェア開発の文脈で考えてみたい。

自分は MapReduce や TF の複雑さが不必要なものだったとは思わない。最終的にはいらないものになったかもしれないけれど、登場した時点で目の前の難しい問題と戦うためには必要だったと思うし、そこにある種のかっこよさがある。Gecko の複雑さが必要なものだった、という主張は生理的に受け入れがたいし実際ゴミも混じっていると思うが、とはいえ 「Windows をやっつけたい」という当時の時代背景を考えると同情はできる。実際、なんらかの価値があったからこそ一度は勝利を収めたわけじゃん。

自分は複雑なテクノロジでフロンティアを切り開く Jeff Dean 的世界観が好きだしすべてのソフトウェアはリファクタリング可能と信じたい宗派なのでどうすればこれらのレガシー巨人が小粋な後発と戦えただろうと考えがち。でもそれよりは、後発はどうすればレガシー巨人の弱みに付け込めるかを考える方が健全に思える。それは結局 Christensen なのではと言われるとそうなのだけれど。

・・・などと与太話を続けようかと思ったが、せめてもうちょっと TF2 なり PyTorch なりに詳しくなってから書くべき話に思えてきた。終了。