PLDI '21論文読み会: DNNFusion: Accelerating Deep Neural Networks Execution with Advanced Operator Fusion

Transcript

1. 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
   

   View Slide

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

   View Slide

3. 提案手法：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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

9. 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
   

   View Slide

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

    View Slide

11. 評価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
    

    View Slide

12. 評価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
    その他の結果は論文読んでね
    

    View Slide

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

    View Slide