[徵文] Halide

看板DataScience作者jimmycool (北七)時間6年前 (2018/08/20 02:44)推噓12(12推 0噓 8→)

留言20則, 11人參與討論串1/1

http://gradient.halide.ai Title: Differentiable Programming for Image Processing and Deep Learning in Ha lide Disclaimer: 這是我自己的paper Deep learning 的一個很重要的核心元素是計算gradients 板上的大家應該都對市面上常見的deep learning frameworks (TensorFlow, PyTorch) 很熟悉，這些框架通常會給你很多operators (TensorFlow 有14個不同的convolution op erators) 讓你去兜成自己想實作的演算法，這些operators的gradients都是一群google 和 Facebook 工程師辛苦手寫的。這種做法的問題在如果有天我們想寫個不太一樣的operator，很可能我們也要跟著手寫gr adients （但只領10%的薪水）。事實上我朋友Michael兩年就碰到這個問題：他想在TensorFlow 裡寫一個叫做bilateral grid的圖片filter，但兩年前TensorFlow還沒有general gather，所以他只好自己在cuda 實作bilateral grid跟gradients。糟糕的是，他後來發現他得要修改bilateral grid，所以gradients要重算，code要重寫，bug要重 de。現在TensorFlow （和PyTorch）有gather能用了，但你還是得丟給gather function 一堆numpy indices，所以這非常慢，而且當我們丟一張大圖給他memory就爆了（12GB的p ascal）。我們覺得解決這個問題的方法是寫個compiler可以算general code的gradient，但是又不用像CUDA那麼low level。所以我們盯上一個叫Halide的語言，他是我們另外三個co auth ors開發的高效能影像處理語言。因爲他們專注在影像處理上，所以能把high level algo rithm和low level optimization （parallelism, memory)乾淨的分開來，讓使用者可以專心寫high level code。我們替Halide加上了算gradients的功能，所以你可以寫high l evel code但維持高效能。上面的bilateral grid我們的code只有pytorch 60%長，但是有 20倍快而且不會吃光memory。算gradients的方法就是標準的automatic differentiation 和一些parallelism加速，有興趣可以看paper和slides。一個這篇paper想要討論的哲學問題是傳統影像處理和deep learning的界線。以前大家在開發影像處理演算法的時候其實也是有一堆參數（像SIFT）然後大家會準備幾張benchma rk images想辦法找到最好的參數。gradient descent其實就是在自動化這個過程，而且他讓你可以加很多參數也不用擔心。我們試著用這套方法改良幾個傳統image processing algorithms，結果都不錯，而且都沒花我們幾天工夫。我覺得大家應該多看看CNN和ReLU 以外的nonlinearities，不要把deep learning跟傳統方法劃清界線。 Gradients另外一個用處是拿來解inverse problems，這個情況就不需要training data。 Paper跟slides有更多details。我們已經把compiler open source (看上面的project page)，裡面也有個PyTorch inter face，所以當你碰到PyTorch寫不出來的code的時候可以試試Halide。我會慢慢放上更多t utorials，有問題也可以寫信給我或開個GitHub issue。邊吃早餐邊打的所以不知道有沒有一千字，沒有我晚上再補。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 107.77.205.122 ※ 文章網址: https://www.ptt.cc/bbs/DataScience/M.1534704270.A.BA1.html ※ 編輯: jimmycool (107.77.205.122), 08/20/2018 02:56:13

推

yoyololicon

08/20 07:52, 6年前 , 1^F

08/20 07:52, 1^F

推

yiefaung

08/20 10:21, 6年前 , 2^F

08/20 10:21, 2^F

推

tsoahans

08/20 10:41, 6年前 , 3^F

08/20 10:41, 3^F

推

kokolotl

08/20 10:56, 6年前 , 4^F

08/20 10:56, 4^F

推

MXNet

08/20 14:48, 6年前 , 5^F

08/20 14:48, 5^F

Julia是相對general purpose的語言，所以也比較難讓自動微分有效率自動微分有分在runtime微分和在compile-time微分兩種，在runtime微分比較好實作但是通常會有10x左右的overhead Julia現有的compile-time autodiff libraries都沒有支援整個語言，比如說寫個for loop就會造成很多問題 (要backprop for loop，要把loop倒過來跑，確認沒有goto跟break跟continue，然後記住中間所有的temp variables) 他們應該也沒有像我們一樣支援奇怪的array indexing 不過我同意在metaprogramming比較強的general purpose語言裡面支援autodiff 是個很有趣的方向最有名的就是Siskind和Pearlmutter的Stalingrad，他們可以微分一個類似Scheme的 functional language https://github.com/Functional-AutoDiff/STALINGRAD 不過Scheme對正常人類有點太hardcore了 (可以看看他們的source code，我是看不懂) 另外一個有關的paper https://arxiv.org/abs/1806.02136 我們也在想辦法讓Halide變得更general purpose，希望有天我們可以真的隨便微分所有code