投稿者: Hajime Morrita

Episode 13 の雑談で “PyTorch は Chainer のフォークである” というニュース記事の主張について議論しましたが、その後調べ直したところいくつか森田の勘違いがあったので現状の理解を改めて書いておきます。

まず PyTorch のソースコードや Git レポジトリの log を見るかぎり, ライセンスやコメント、コミットログや明らかなコードの重複など、はっきりとしたフォークの証拠はありません。(API の模倣については当事者による論文のドラフトなど何箇所かで言及されています。)

ウェブを検索してみると、以下のツイートが証言としてリンクされていました。

• James Bradbury on Twitter: “Yep, the PyTorch autograd codebase started with a fork from Chainer — but then rewrote it in highly optimized pure C… “

他の関係者の発言は見つかりませんでした。唯一の証言であるこの J 氏のツイートを信じるなら、フォークされたのはどうも autograd だけのようです。一方で、そもそもフォークではないと主張する証言もみつかります。

• PyTorch was never a Chainer fork. The whole codebase are C libs from Lua Torch, … | Hacker News

どちらの主張が正しいのでしょうか。

フォークを主張する J 氏は PyTorch への数個のコミット履歴をもつ、コードレベルでは比較的カジュアルなコントリビュータです。一方フォークでないと主張する A 氏は継続的なコミットを続ける top contributor。件の autograd コードを最初にコミットとしたのもこの A 氏です。発言者の credibility という点では、フォークでないと主張する A 氏に軍配があがるのではないでしょうか。

はっきりとしたコードの類似性がないと書きましたが、実物を比べてみましょう。PyTorch での最初の Autodiff 実装はこのコミットです。一方、同時期の Chainer (1.13.0) の実装はこれ。グラフのトラバース先をキューにつめながら反復的に gradient を解決していく基本のアプローチは同じですが、表層的なコードの様子は随分違うのがわかると思います。

これは無理もない話です。Autograd のコードはどうしてもベースとなる Tensor 計算用の API に引きずられます。Chainer はその計算に CuPy というライブラリを使っています。(先に登場したバージョン 1.13.0 の時点ではまだ Chainer の一部でした。) 一方の PyTorch は Lua Torch 由来の C ライブラリをラップして使っています。

どちらも NumPy を模している点では似ていますが、drop in の互換性があるとは思えません。特に初期の PyTorch に含まれる Tensor 実装は極めて制限されたものでした。PyTorch にチェックインされた時点の autograd はごく短い単純な実装でしたから、互換性の低い CuPy を Torch に入れ替えて使えるようにするよりは Torch 向けに自分で書いてしまった方が簡単に見えます。

フォークというのはソフトウェアとして切り出しやすい単位で行わないと有り難みがなく、Autograd はその単位としてやや筋悪なのです。そういう意味でも “Autograd のコードがフォークである” とする J 氏の証言は疑わしく思えます。なお J 氏は同じツイートで “のちにコードは pure C の高速バージョンに書き直された” と言っていますが、これも厳密には間違いです。現状の PyTorch の autograd は C++ で書かれており、かつ演算単位では Python にフォールバックする可能性もある “pure C” とは程遠いものだからです。

というわけで PyTorch の Chainer フォーク説はよく似せられた API とひとつのツイートが生み出した都市伝説であるというのが自分の結論です。

フォークかどうかはさておき、API のようなソフトウェアデザインの重要な部分で PyTorch が Chainer を真似しているのは事実です。これはサンプルで引き合いにだされる NN モジュールだけでなく、 Variable や Function といったクラス、forward, backward メソッドの在処など autograd のレイヤについても言えます。ただしこれらが純粋に Chainer 由来なのか、Harvard の NumPy Autograd のような他の実装にも共通するパターンなのかについては、もう少し調査しないとわからないですね。

---

追記

記事を書かれた中田さんからお返事をいただきました。論拠となったのは先のツイートではなく、Facebook AI の中の人の Reddit 上の発言とのことです。

Truffle の最適化が一般的なコンパイラの最適化と大きく異なるところは, Truffle では個々のオブジェクト (AST のノード) ごとにメソッドの実行時プロファイルを集計しているところです。大半のコンパイラは、関数などのコード単位でプロファイルをとり、オブジェクト (receiver やその他の引数) ごとにプロファイルを分類はしません。

なぜこの性質が重要なのでしょうか。論文中の例にならい “+” 演算子を実装した AST ノード AddNode の例で考えてみましょう。この AddNode は引数が数値型か文字列か、あるいは独自の “+” を定義したクラスのオブジェクトかで挙動が変わるとします。もしコンパイラがコード単位で、たとえば AddNode#execute() という単位で実行時情報・・・ここでは引数の型・・・を集めるなら、あるプログラムの中に数値のプラスと文字列のプラスが現れた時点で AddNode#execute() は多態的なコードを生成する必要が生まれます。

Ruby, JS など動的なゲスト言語の AST は、ホスト言語である Java から見るとどうしても多態的になってしまうです。

Truffle では、文字列を扱う関数 F と数値を扱う関数 G の中で登場するプラス演算子の AST ノードがそれぞれ独立して実行時の情報を集めます。おかげで F の中では文字列を連結するコードを、G の中では数値を加算するコードを、生成することができます。

一般的なプログラムではあまり重視されていないオブジェクト単位の実行時プロファイルが、どうして Truffle では重要なのでしょうか。それは Truffle の AST がゲスト言語にとっての「コード」だからです。AST インタプリタとして実装されたゲスト言語がふつうの最適化コンパイラがやるようなコード単位の実行時プロファイルを集めたいと思ったら、AST の上にそのデータを置くのは自然なことです。

Truffle はそうしたデザインを前提として、最適化のためのヒントである実行情報をAST のオブジェクトとの間でやりとりする API を提供しました。それらの API をある種の instrincis として特別に解釈し、ふつうのコンパイラにはできないような最適化が可能になるのです。