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://webptt.com/m.aspx?n=bbs/DataScience/M.1534704270.A.BA1.html ※ 編輯: jimmycool (107.77.205.122), 08/20/2018 02:56:13 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 ※ 編輯: jimmycool (71.231.190.72), 08/21/2018 22:05:16