define-by-run
モデルを直接実行する
計算グラフの構築をデータを流しなら行う
実際に計算が行われたタイミングで計算グラフを作っていく
異なるデータを入れたときに、異なる計算グラフを作成することができる
データによって条件分岐ができたりするのも利点なのか? ref
制御フローを使用するモデルでは特に使い勝手が良い
インタプリタ的に実行やデバッグが可能
欠点
Pythonインタプリタのパフォーマンスの低さが影響する
ただし以下のようなアプローチにより最適化の余地がある
遅延評価
JIT tracingする
GILがあるのでマルチコアCPUを活用したい場合、複雑な回避策が必要になる
C++コードの混在など
インタプリタ的な実行なので、全体的な最適化がしづらい
モデルの並列処理など
自動微分の「ソースコード変換」技術を使用できない
演算子overloadのアプローチ
足し算の処理をすると、裏では足し算をしたことを記録していて、誤差逆伝播法の時に使うやつ、のことかな？
これは効果的だが、
>lose the ability to translate control flow constructs in the host language to the computation graph
なんで #??
微分が失敗した時に最適化出来ない、もしくはエラーがわかりにくくなる
Pythonなしでのデプロイが出来ない
ただし、ONNXなどを使ってエクスポートすれば可能
例
chainer.functions.add(A, B) を実行するこのタイミングで実際にA+Bを計算
同時に、誤差逆伝播法する時に必要なグラフも作成する
使われているフレームワーク
参考
===========
欠点
いくつか書いてるけど概念がわからなくて理解できない..
Tracing JITは計算を完全に展開するのでめっちゃでかいトレースになる可能性がある
参考