如何評價陳天奇團隊新開源的TVM？

01-04

陳天奇團隊發布TVM：把深度學習部署到手機、樹莓派等更多硬體
自動生成硬體優化內核：陳天奇等人發布深度學習編譯器TVM

從去年nnvm推出之後，非常感謝在zhihu和 @王健飛上有一些討論如何評價陳天奇的模塊化深度學習系統NNVM？，關於nnvm剩下的瓶頸。這個討論本身加上早期的nnvm編譯嘗試，讓我意識到了可以支持快速調優底層op的重要性。在接下來的八個多月裡面我們不斷迭代完成了TVM。

TVM嘗試從更高的抽象層次上總結深度學習op的手工優化經驗，用來使得用戶可以快速地以自動或者半自動的方法探索高效的op實現空間。

TVM和已有的解決方案不同，以XLA作為例子，TVM走了和目前的XLA比更加激進的技術路線，tvm可以用來使得實現XLA需要的功能更加容易 ：已有的解決方案本身基於高級圖表示的規則變換，可以產生一些圖級別的組合op優化，如conv-bn fusion，但是依然要依賴於手寫規則來達到從圖的表示到代碼這一步。圖的op表示到代碼本身可以選擇的東西太多，如何做線程，如何利用shared memory，而大部分沒有在圖語言裡面得到刻畫，導致難以自動化。這樣下去深度學習系統的瓶頸必然從op實現的複雜度變成了實現graph compiler中模式生成規則的複雜度。走這個方向需要非常大的工程團隊的支持，而我們希望採用更少的人力達到同樣甚至更好的效果。

我們採取了風險更大但是回報也更大的長遠技術路線。簡單地說，TVM通過把圖到op生成規則這一步進一步抽象化，把生成規則本身分成各個操作原語，在需要的時候加以組合。基於tvm我們可以快速地組合出不同的schedule方案。

這個想法並不新穎，正如其它回答中提到的Halide，或者polyhedra method都是嘗試去做這件事情。想法雖然美好，但是自動代碼生成這條路線必須要生成代碼效率到達手寫的80%-90%效率以上，才會有實際使用的價值。一旦到達了80%到90%的效率以上，通過fusion，layout的一些高級聯合優化就可以彌補這一個gap來得到比直接組合手寫代碼更好的效果。

但是這也正是這個問題最困難的地方，我們需要能使得自動或者半自動生成的代碼達到手寫代碼的效果。在TVM之前，已有的解決方案都還沒有解決這個問題。我知道的最好的GPU自動生成代碼大概可以到Cublas的50%的運行效率，而大部分的已有方案只是針對單線程cpu有比較好的效果。

當然已有的解決方案有不少值得參考的地方。比如polyhedra method本身非常精闢地把程序優化的大部分問題總結為針對整數集的分析。Halide裡面的schedule和declaration分離的思想等。這些思想都非常強地影響了TVM的設計

這本身是一個很有趣的科研問題，dmlc的的初衷就是去解決這樣新的問題，發布新的解決方案。TVM在很大程度上解決了這個問題。要解決它，需要做到兩點：設計足夠大的schedule空間，使得它可以囊括包括cpu和gpu在內可以做到的手寫優化，設計足夠強大的搜索演算法。之前的方法之所以沒有圖片，難點在於需要足夠大的空間。

所有的抽象總是有缺陷的，所以死抱一個固定的抽象肯定不能解決所有的問題。但是可以被寫出來的手工優化基本上也是可以被抽象的。過去的幾個月我們就是沿著這樣的思路，不斷地去總結手工優化的經驗加以抽象到TVM中。雖然我們不敢保證TVM包含所有可能的手工優化，但是我基本上cover了我知識範圍裡面可以涉及到的東西（使得TVM至少比我知道的多）。隨著TVM的演化，會有更多的這樣的手工優化經驗可以被加入進來。這也真是需要HPC機器學習和編譯等各方面人才一起合力的結果。

到目前為止，我們基本可以確定TVM目前提供的schedule空間在cpu上可以做到90%，相似或者超過一些手寫優化庫效果的方案，在gpu上幾本可以做到達到或者超過手寫cuda的方案，但是和手寫assembly在一些情況還有80%的差距（主要來源於gpu的寄存器分配比較困難）。TVM本身也意識到的手寫優化的重要性，會在允許在各個級別混用手寫優化的代碼，來彌補剩下這一平衡。

這是一個非常激動的前沿課題，基於這個項目本身還會有不少有趣的研究方向，我們在很多地方已經可以看到非常好的效果。所以我們非常希望對於機器學習，hpc，編譯原理，硬體加速有興趣的同學一起加入進來，一起來推動這個項目。而因為我們目前到達的效果本身，TVM已經可以被使用於實際的應用場景中了。

最後有一些細節上面的東西，TVM本身的設計中是非常注重開發效率和可擴展性。TVM直接提供了非常好用的python和真機調試框架，可以不依賴於上層框架直接基於python開發調試。這一點使得tvm在調試開發和效率迭代上面比起已有的方案有比較大的優勢。未來我們也會放出一些樣例教程，讓大家都可以開發高效的代碼

目前 TVM 放出的資料還較少，周日學習了下代碼，和大家交流分享，有疏漏煩請回復指出。

TVM 的應用場景，是跟 TensorFlow XLA 對標，提供將模型輸出到不同設備 native code 的能力。這裡面有幾個可以對標的組件：

TOPI (TVM Operator Inventory) 大約對應 XLA HLO, 描述在 DL 領域會用到的高層次 Operator 如 matmul, conv2d 等。這一層次可以做 CSE、Fusion 等優化。
Schedule + HalideIR + TVM IR 無對應
代碼輸出 TVM 使用 LLVM IR 和 Source Code, 對應 XLA 使用 LLVM IR.

這裡面，TVM 的切入點是在 High Level 到 Low Level 中間，插入了 Schedule 層，大概流程是 NNVM -&> TVM/TOPI -&> TVM/Schedule -&> TVM/HalideIR -&> TVM IR -&> LLVM IR 或 Source Code。中間 TVM Schedule 的主要思想來自於 Halide. 這裡要簡單介紹一下 Halide 這個為圖像處理設計的語言。Halide 其特點是計算描述（algorithm）和計算過程（schedule）分離（http://people.csail.mit.edu/jrk/jrkthesis.pdf）。這麼做是因為計算機體系結構的設計（緩存，SIMD 等），直接裸寫演算法不能獲得最高性能（一個例子是三重循環裸寫矩陣乘會很慢）。因此不同的體系結構，對一個演算法的計算過程也就不同。分離演算法定義和計算過程，則方便為不同的體系結構制定不同的 schedule, 進一步可以探索 schedule 的自動生成（Automatically Scheduling Halide Image Processing Pipelines）。更詳細的介紹建議去 Halide 官網 Halide 學習。

當初看到 Halide 的時候，就在想這個想法在 DL 領域一定會有用，如今終於被 DMLC 推動進入了人們的視線。我對這個事情的看法是：

Halide 可以比較快的實現一個性能還不錯的 kernel，開發效率很高，換不同 schedule 測試方便。對比傳統 kernel 實現一般是手寫 C/C++ 或者彙編代碼，開發效率較低。但任何抽象都不是完美的，有足夠人力的情況下，傳統寫法一定可以獲得不低於 Halide 的效率。
Halide 提供了 auto-tune 的可能，但目前也只是在學術界研究，離工業級生產還遠。因此可預見的未來，我們還是要為不同的 target 手寫 schedule 的。

根據 @crowowrk 介紹，TVM 相對 Halide 做的比較多的工作，主要的是去解決 schedule 空間包含手寫優化的問題。具體內容移步 crowowrk 的回答。

TVM 的另一個目的是，希望通過 TOPI 這個 Operator 庫，為所有兼容 dlpack 的深度學習框架提供 kernel 庫，這個目標是十分歡迎的，具體效果還有待觀察。

反過來看 TensorFlow 的 XLA，目前 XLA 還在快速開發中，有幾點可以注意：

XLA 並不反對獨立出來給其他框架用 XLA standalone
XLA 歡迎嘗試各種 idea，目前有人在 Incorporate Polyhedral Compilation
XLA 目前很多 kernel 實現是基於 Eigen 的。某種程度上，Eigen 這種數學庫也是 TOPI 的對標。

總的來說，TVM 目標是很好的，非常支持。Soumith (PyTorch 主要作者）也在積极參与 TVM 項目並表示在接下來的幾個月內會有更多關於 TVM/PyTorch 的消息 Twitter 。

edit: 跟作者交流更新了若干技術細節。

估計Google最近應該也會發一個東西，MXNet和TensorFlow競爭好激烈。。。

最近在考慮將深度學習移植到移動端, 面對很多問題:

ios 11有coreml, ios10用metal, 更低版本需要手寫低版本metal代碼
neon指令集優化
安卓gpu
caffe,tensorflow,darknet等一堆框架,移植不便,而且無法一一優化.

瞌睡送枕頭, 感覺tvm就是答案.

github上關注了tianqi, 一直納悶最近半年為啥沒有提交代碼, 難道上課太忙?

直到昨天...

突然都亮起來了.

吐槽一句, mxnet號稱是輕量級框架, 各種宏,lambda看的懷疑人生,nnvm居然還能把torch弄過來用Orz. 後來看了caffe, 很多功能都用第三方庫, 主體代碼很清晰簡單啊, 這才是輕量啊...

利益相關: dmlc腦殘粉, tianqi腦殘粉

TVM，按照正式說法：就是一種將深度學習工作負載部署到硬體的端到端IR（中間表示）堆棧。換一種說法，可以表述為一種把深度學習模型分發到各種硬體設備上的、端到端的解決方案。

DMLC項目發起人陳天奇在微博上表示，TVM和之前發布的模塊化深度學習系統NNVM一起，「組成深度學習到各種硬體的完整優化工具鏈」。

同在DMLC小組的劉洪亮（phunter_lau）進一步在微博上解釋了這個工作的意義：「TVM可以把模型部署到不同硬體，比如群眾常問的能不能用AMD的GPU，用FPGA怎麼搞，TVM提供這個中間層有效解決這個問題」。

隨後陳天奇也補充說：

除了比較明顯的多硬體支持，更重要的是支持比較方便的自動調優和輕量級部署。比如我們有同學可以在一些workload可以達到和cudnn差不多的效果，而且同樣的東西可以遷移到其它非cuda設備。

google的哲學

開源是傻蛋乾的受累沒錢

android是google苦逼微軟收錢

大家還記得找不到工作的bhuztez么

他在去年在一位七歲小朋友的指導下預言，2017年出現的下一代深度學習框架後端會利用Polyhedral model做fusion，減少GPU內存帶寬壓力，提升運行速度。被某人下結論說「真心不會.. 合併帶來的內存節省只是一次elementwise op的代價，比起卷積開銷真是一個毛毛」

https://www.zhihu.com/question/48615510/answer/115592046

而現在的廣告

「現在我們看到了 TVM 構建了由循環轉換工具比如 loopy、多面體分析啟發的圖優化」

「我們通過自動融合運算符並使 TVM 生成融合的內核，在圖形節點之間和之中應用優化」

bhuztez不如趕緊改行，事實證明他那點破爛水平，連名校博士頭銜都沒有，真心不適合寫程序，我建議他還是去賣煎餅果子吧：）

很牛逼，很早就聽到風說tianqi chen在做一個大的改進，沒想到是這個。

不管怎麼樣，mxnetk將成為與tensorflow並駕齊驅的DL Framework。

現在開源框架很多，認定以前有開源項目的公司會讓你以後少添一些坑。

男神長殘了還是男神。跪著讀代碼的。。。。。。。

部署到手機沒有價值？部署到樹莓派沒有價值？我聽了太多沒分量的人說了這種沒分量的話。就這些喜歡踩別人的人真是用生命證明了，小學教育普及啥啊？就他們這點智商能有什麼價值。

我非常期待的就是有一天tvm能憑藉chisel讓現有的演算法遷移到FPGA上，希望tvm早日支持scala！

問下和Nervana Graph的區別有哪些?