Episode 17 – Unikernels: Library Operating Systems for the Cloud

OCaml で書かれた LibraryOS Unikernels/MirageOS に関する論文 “Unikernels: Library Operating Systems for the Cloud” を森田が紹介します。

Follow up

Announcement

  • ちょっとおやすみして、次回は一ヶ月後くらいの予定です。

Episode 16 – A Deep Learning Approach for Generalized Speech Animation

Disney Research による口パクアニメーション生成論文 “A Deep Learning Approach for Generalized Speech Animation” を向井が紹介します。

Disney Research による口パクアニメーション生成論文 “A Deep Learning Approach for Generalized Speech Animation” を向井が紹介します。

Follow up

Episode 15 – Neural Machine Translation by Jointly Learning to Align and Translate

Neural Network における “Attention” の概念をうみだした機械翻訳の論文 “Neural Machine Translation by Jointly Learning to Align and Translate” を森田が紹介します。

今回は根性不足によりあまり編集しておりません。聞き苦しい部分はご容赦ください。

 

Episode 14 – LevelDB

Jeff Dean が Chrome のために書いたデータベースライブラリ LevelDB についてドキュメントやコードを見ながら向井が紹介します。

Follow-up

Episode 13 – HyperLogLog in Practice

確率的アルゴリズム HyperLogLog に関する論文 “HyperLogLog in Practice” を 森田が紹介します。感想などはハッシュタグ #misreadinghello@misreading.chat にお寄せください。

Follow up

Episode 12 – Semantics and Complexity of GraphQL

GraphQLを分析した論文 “Semantics and Complexity of GraphQL” を向井が紹介します。感想などはハッシュタグ #misreadinghello@misreading.chat にお寄せください。

Correction

  • エピソード内でクエリ結果のサイズ評価について議論していますが、論文をちらっと読んだかんじでは向井さんの主張が正しそうです。自分はなんとなくスキーマの ER 図みたいのを想像しながら話を聞いていましたが、この人のいうグラフはオブジェクトDBみたいなグラフで、何かを評価する際にスキーマなどはおまけみたいなものなんですね。思い込みで話がかみ合っていませんでした。(森田)

PyTorch, Chainer and Forking

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

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

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

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

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

フォークを主張する 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 上の発言とのことです。