DNNFusion: Accelerating Deep Neural Networks Execution with Advanced Operator Fusion Wei Niu1, Jiexiong Guan1, Yanzhi Wang2, Gagan Agrawal1, and Bin Ren1 1: William & Mary 2: Northeastern University 一言でまとめると： Operator Fusionのパターンを一般化すること で 汎用性と最適化性能を上げた 担当：bonotake 2021/9/17, PLDI2021読み会＠Idein 2022/06/08 PLDI2021読み会＠Idein 1

背景：Operator Fusion • DNNコンパイルでは一般的な最適化パスの1つ • 著者らの経験から、DNN実行時間にはレイヤー数が 極めてクリティカルに効く → operator fusion は効果的 しかし、従来手法は汎用性の低さに問題があった • Polyhedral analysis → 抽象度が低い • 特定のパターンによるパターンマッチ（TVMなど） → パターンが極めて限定的 2022/06/08 PLDI2021読み会＠Idein 2

提案手法：DNNFusion 1. GenericなパターンでFusionするかを判断 • 各オペレータにmapping typeという型を導入 • 組み合わせの “収益性” (profitability) を導入 • 型の組み合わせ＋収益性のあるなしでfusionするかを判断 2. Extended Computational Graph (ECG) の導入 • 普通のCG ＋ mapping type 3. 代数的な性質に基づいたグラフ書き換え 4. Mapping type に基づいた fusion plan generation 実験の結果 • モバイル端末（Galaxy S20）上でTVMの1.5～3.5倍、TFLiteの1.4～3.3倍高速化 • 従来のコンパイラでは非対応だったネットワーク（Faster R-CNNなど）も モバイル端末で動かせるように 2022/06/08 PLDI2021読み会＠Idein 3

Mapping type とは • 入力／出力の組が1対1か、1対多か、多対多かで分類したもの • 多対1（convなど）は多対多に分類 • 他に Reorganlize, Shuffle が存在 2022/06/08 PLDI2021読み会＠Idein 4

Mapping type analysis • 接続されている2オペレータの組み合わせをmapping type を基に解析 • 緑：無条件にfusion • 赤：fusionしない • オレンジ：収益性があればfusion Table 3 より 2022/06/08 PLDI2021読み会＠Idein 5

収益性 • Mapping typeの組み合わせによっては、fusionするとレイテ ンシが落ちるものがある • そういう場合、fusionすると収益性がある（profitable）かど うかで実際にfusionするかを判断する • 収益性はコストを実測してのプロファイルベースに判断 • Profiling database をあらかじめ持っておくことで効率化可能 • 例：多対多オペレータの後ろにConv（多対1）がある場合 • Expandの場合、1次元の拡張だけなので恐らく悪い影響はない • Resizeの場合、入力を違う次元にコピーするので悪影響があり得る 2022/06/08 PLDI2021読み会＠Idein 6

DNNFusionの処理 1. ECGを作成 2. グラフ書き換え 3. Fusion plan の探索・生成 4. ブロック内最適化 5. コード生成 6. ブロック間最適化 2022/06/08 PLDI2021読み会＠Idein 7

グラフ書き 換え • 基本的な代数的性質（結合則、分配則、可換則）に 基づいたグラフの書き換え • strength reduction （のテンソル版）によって書 き換えを判断 2022/06/08 PLDI2021読み会＠Idein 8 Figure 2 より

Fusion Plan の探索 • アルゴリズム 1. ECG上で、起点となるオペレータ（seed）を1つ決める • one-to-one オペレータのうち、生成する中間結果のサイズが最小のものを選ぶ 2. 後続のオペレータ（successor）とfusionできるか考える 1. Mapping type で判断できるならそれで 2. 判断できないなら収益性で 3. Fusionできる場合、更に後続ともfusionできるか、再帰的に判定 4. 前につながるオペレータ（predecessor）ともfusion可能か再帰的 に判定 • ただし、successorとは違って複数の候補の1つとだけしかfusionしない 5. unfusedなオペレータがあったら、その中で1からまたやる 2022/06/08 PLDI2021読み会＠Idein 9

最適化とコード生成 1. ブロック内最適化 • Shuffle、Reorganizeは大抵 消せるし、それも後続のオペ レータ1つだけ見れば判断がつ く 2022/06/08 PLDI2021読み会＠Idein 10 2. コード生成 3. ブロック間最適化 • データレイアウトはここでやる • ブロック内は、その中で“支配的”なオペレータのレイアウトに合わせる

評価1: レイヤー数 • Sumsung Galaxy S20で、レイヤー数をどこまで削減できるかを他のコンパイラ／フ レームワークと比較 • 結果、 • TVMの1/1.3～1/8.1に削減 • TFLiteの1/1.3～1/8.8に削減 • PyTorch mobileの1/1.6～1/9.3に削減 2022/06/08 PLDI2021読み会＠Idein 11

評価2: レイテンシ • 速度が • TVMの1.5～2.5倍 • TFLiteの1.4～3.3倍 • PyTorch mobileの1.6～9.3倍 • TransformerベースはTVMと比較して特に効果大 • TVMのパターンがハマらないものが多い 2022/06/08 PLDI2021読み会＠Idein 12 その他の結果は論文読んでね

まとめ • Operator Fusionのパターンを一般化することで 汎用性と最適化性能を上げた • Mapping type の導入とパターンの整理 • 収益性の導入 • 代数的なグラフ書き換え規則 など 所感 • 特別凄いことはやってないが、みんな悩んでたところをちゃんと整理してまと めたのがエライ • 方向性は正しいように思える • 一部なんかようわからんところがあったけど • ちゃんと結果も出てるしすごい 2022/06/08 PLDI2021読み会＠Idein 13