[[333937]]

Python 的語法很靈活，融合了很多其他語言中令人覺得方便的特點。然而 Python 的優(yōu)勢同時也隱含了其劣勢。螞蟻研究員王益在工業(yè)系統(tǒng)中對 Python 的親身體會，更加深刻地了解到了 Python 的局限，而 Go+ 是彌補方案里最靠譜的。那么 Python 有哪些不足?Go+ 又是如何能彌補的?本文分享王益對 Go+ 補全 Python 的局限上的相關看法和嘗試。

不久前許式偉(江湖人稱老許)的 Go+ 項目在 Hacker News 上掀起了一陣風潮[1]。我一見傾心，參與貢獻。最近老許和社區(qū)組織了一個視頻交流，拉我跟大家說說為啥關注 Go+ 以及圖個啥。在直播交流后，根據(jù)彈幕反饋，以及兩位好友 ——洪明勝(TenosrFlow Runtime 負責人)以及王玉(沈雕墨)的建議，做了修改。

我做分布式深度學習系統(tǒng)十三年了，尤其是 2016 年徐偉老師讓我接替他作為他原創(chuàng)的PaddlePaddle 項目的負責人之后，在工業(yè)系統(tǒng)中對 Python 的親身體會讓我對其局限了解愈深。而 Go+ 是我見過的彌補方案里最靠譜的。

我期待 Go+ 對標 Python，補全 Python 的不足，并且在此基礎上有一個類似 numpy 的項目(姑且稱之為 numgo+ 吧)用來支持張量(tensor)運算，滿足數(shù)據(jù)科學的需求;在 numgo+ 之上再構建一個類似 PyTorch 的深度學習基礎庫(姑且稱之為 GoTorch 吧)。如果可以，進一步成為深度學習編譯器生態(tài)的一種前端語言。

我現(xiàn)在在螞蟻集團工作，負責一個開源 SQL 編譯器 SQLFlow —— 把擴展語法以支持 AI 的 SQL 程序翻譯成 Python 程序。同事們說，如果 Go+ 這套生態(tài)能成熟起來，很樂意讓 SQLFlow 輸出 Go+ 程序。

很多讀者估計覺得我瞎說八道 —— Python 如此如日中天一般火熱的語言，何須“補足”?

Python 的優(yōu)勢

Python 的語法很靈活，融合了其他很多語言令人覺得方便的特點。比如，和 C++ 一樣， Python 允許重載操作符，numpy 的作者于是重載了算數(shù)操作符來做張量運算。和 Lisp 一樣，Python 的 eval 函數(shù)遞歸地實現(xiàn)了 Python 解釋器，可以解釋執(zhí)行 Python 表達式，所以 Python 程序可以生成自己。

這樣的靈活性允許程序員隨心所欲，因此特別適合探索性工作。比如研究生們用 Python 做科研;數(shù)據(jù)科學家們用來替代之前各種昂貴的商業(yè)化系統(tǒng);在隨后誕生的深度學習領域，Python 也迅速蓬勃發(fā)展起來。

Python 的局限

Python 的優(yōu)勢同時也隱含了其劣勢。 我親身感受的痛點有二。

難以保證代碼質(zhì)量

語法靈活的另一種說法是：一個程序有多重寫法。現(xiàn)代軟件工程里沒有孤膽英雄，全靠大家合作。多種可能的寫法往往意味著團隊容易在 code review 時吵架 —— 而且難以平息，因為不一定有客觀選擇標準。很多其他語言也有類似問題，比如 Java。解法是，社區(qū)里定一些設計模式(design patterns)，程序員寫程序前先看看有沒有可以套用的設計模式，如果有，則遵循之。所以 Java 程序員除了學習 Java 語法，還要學習設計模式。C++ 也有類似的問題。解法之一是 Google 定了一套 code style —— 哪些語法可以用，哪些不許用 —— 按照 Rob Pike 的解釋，允許用的部分語法挑出來，就是 Go 的設計初衷。Python 太靈活，以至于 code style 都沒法定義得和 C++ 的一樣細致 —— PEP8 幾乎只是說說排版要求，對語法的選用幾乎沒有限制。Python 也沒法定義模式 —— 太多了，寫不完。

Python 為了靈活采用動態(tài)類型，所以我們看一個 Python 函數(shù)，必須得細讀其代碼，否則都不知道它有沒有返回值，以及返回值是啥。Python 也有語法擴展，要求編程者指明輸入輸出的數(shù)據(jù)類型，不過用的人不多 —— 畢竟大家都是沖著“靈活”來的;要是限制靈活性，那就真不如用靜態(tài)類型語言了。這個結果是，每個 Python 函數(shù)都不能太長，否則看不明白了。可是 Python 程序員就是沖著靈活性來的，要的就是信馬由韁的感覺，管你懂不懂呢，我自己明白就行，反正發(fā)完論文就畢業(yè)了。拆分函數(shù)細化粒度?不可能的，這輩子都不可能的。

有沒有寫的很好的 Python 代碼呢?有的。比如 Google Tangent。這是一個很小眾的項目。作者也只有兩個。其代碼結構清晰 —— 每個函數(shù)基本都在十行代碼之內(nèi)，代碼和注釋一樣長，所以很好懂。不過這也和 Python 用戶眾多的印象相悖了。我在負責 PaddlePaddle 項目的時候，除了自己努力學習和總結 Python 的模式，也配置 CI 調(diào)用各種工具做源碼檢查，然并卵，這些工具沒有智能化到可以自動注釋代碼，也不會自動拆分太長的函數(shù)定義。

難以優(yōu)化計算效率

Python 的語法豐富、靈活性強，所以解釋器寫起來很復雜，要優(yōu)化性能也很難。相比之下，Go 語言語法簡潔，表達能力遠勝于 C 但是 keyword 總數(shù)少于 C，這種簡潔使得 Go 程序的性能優(yōu)化比較容易。在 Go 誕生后幾年，Go 編譯器對代碼的性能優(yōu)化水平就快速接近 GCC 對 C++ 程序的優(yōu)化水平了，而 C++ 和 Python 一樣，語法豐富，所以編譯器里的代碼性能優(yōu)化功能很不容易開發(fā)。

有人嘗試寫 Python 的編譯器來代替解釋器，從而在程序執(zhí)行之前先做性能優(yōu)化。但是 Python 語法比 C++ 更靈活，以至于幾乎沒法寫一個完全支持 Python 標準語法的編譯器出來。幾個嘗試因此作罷。目前的普遍的做法是解釋器來做執(zhí)行時優(yōu)化(JIT compilation)，因為有 runtime 信息，所以相對編譯器更容易一些。

在 AI 領域，深度學習訓練非常消耗計算資源。TensorFlow 的圖模式的解法是：用戶寫的 Python 程序在執(zhí)行時并不真的做訓練，而是把訓練過程輸出成一個被稱為”計算圖“的數(shù)據(jù)結構，交給 TenosrFlow runtime 這個“解釋器”來執(zhí)行。只要保證 TensorFlow runtime 的執(zhí)行效率，即可不受 Python 解釋器效率的限制。

TensorFlow 圖模式用心良苦，也畫蛇添足 —— 源程序、各層 IR、以及 binary code 是一直以來人們用來描述計算過程的表達方式，TensorFlow 項目早年間發(fā)明的計算圖重復造了個輪子，而且造得不專業(yè) —— 圖難以表達 if-else、循環(huán)、函數(shù)定義和調(diào)用，更別提 closure、coroutine 和 threading 這樣的高級控制流結構了。人工智能工程師的非專業(yè)編譯器設計讓 LLVM 的作者 Chris Lattener 掩面而笑，于是他嘗試用 Swift for TensorFlow 替換 Python 作為前端語言，用 MLIR 代替 TensorFlow 中的“計算圖” [2]。

補全局限的嘗試

我在負責 PaddlePaddle 期間為了驗證 Paddle Fluid 的能力，和我的同事陳曦一起做了一個無人駕駛船，嘗試用 Fluid 寫 immitation learning 方法，讓船能學習人類駕駛員的駕駛技術，詳情請見系列博客[3]。可是如果我們把跑 Python 程序的 MacBook Pro 帶上船則太費電，而嵌入式的設備上又不適合跑 Python 寫的訓練程序。如果每次停船后上傳數(shù)據(jù)到服務器訓練，那么船向人學習迭代的進度就太慢了。

為此，當時另一位同事楊楊寫了 Paddle Tape，用 C++ 實現(xiàn)了 PyTorch 的自動求導能力，結合 Paddle Fluid 積累的眾多用 C++ 寫的基本計算單元(operators)，Tape 完全是一個 C++ 實現(xiàn)的深度學習系統(tǒng)系統(tǒng)，和 Python 沒啥關系了。

2019 年初，我的朋友洪明勝在 Google 負責 Swift for TensorFlow 項目，這也是一個 AI 基礎架構去 Python 化的嘗試。他當時拉我給 Chris Lattener 的團隊分享了 Paddle Tape 和無人船的故事，并修改了幻燈片[4]。

我在螞蟻集團負責的一個開源分布式深度學習訓練系統(tǒng) ElasticDL，嘗試過調(diào)用 TensorFlow graph mode、eager execution mode、PyTorch、和 Swift for TensorFlow，很受 Swift for TensorFlow 的設計理念以及和 Python 生態(tài)共榮的策略的啟發(fā)。

Go+ 和數(shù)據(jù)科學

以上嘗試提醒我，語言的選擇標準必須包括：語法清晰簡練和語法穩(wěn)定容易學習。也希望語言的使用者是比較有探索精神的一個群體。Go+ 及其基于 Go 社區(qū)的用戶群體剛好符合這些條件。

在 Go+ 出現(xiàn)之前，也有把 Go 用于數(shù)據(jù)科學的嘗試，也有用 Go 實現(xiàn)的張量運算庫(比如 gonum)，但是用起來都不如用 numpy 的 Python 程序簡練，很直接的一個原因是 Go 的常量需要指定數(shù)據(jù)類型，而 Python 的則不用。我寫了幾個對比[5]。

用 Go 定義一個 ndarray 類型的常量，用戶需要寫：

x :=numgo.NdArray(       
    [][]float64{       
      {1.0, 2.0, 3.0},       
      {1.0, 2.0, 3.0}}) 

而用 Python 是：

x = numpy.ndarray(     
    [[1.0,2.0, 3.0],      
    [1.0,2.0, 3.0]]) 

有了 Go+ 來自動推導數(shù)據(jù)類型，寫法就和 Python 幾乎一樣了：

x :=numgo.NdArray( 
    [[1.0, 2.0, 3.0],      
    [1.0,2.0, 3.0]]) 

更進一步，老許加的一個 comment 解釋 Go+ 準備支持 MATLAB 的張量定義語法。這樣一來，這個程序就更簡單了：

x :=numgo.NdArray( 
     [1.0, 2.0, 3.0; 
      1.0, 2.0, 3.0]) 

類似的便捷的語法改進在 Go+ 已經(jīng)積累了不少，例子在[6]。這些語法擴展足以極大簡化數(shù)據(jù)科學編程。

而 Go+ compiler 負責把利用這些語法糖寫作的 Go+ 程序翻譯成 Go 程序。這樣可以和其他 Go 語言寫的庫一起編譯，從而復用 Go 生態(tài)里的代碼。

復用 Go 生態(tài)是 Go+ 語言的一個長項。在 Go 的發(fā)展過程中，已經(jīng)積累了不少科學計算的基礎技術，比如實現(xiàn)張量的 Go 數(shù)據(jù)類型的封裝。這些數(shù)據(jù)類型的計算也有高效的 Go 實現(xiàn)，部分緣于 Go 程序可以方便地調(diào)用 C/C++ 程序，包括科學計算領域里久經(jīng)考驗的基礎庫如 LAPACK，甚至 NVIDIA GPU 的接口庫 CUDA。值得注意的是，這些基于 C/C++ 的基礎庫也是 Python 的數(shù)據(jù)科學生態(tài)的基礎，所以本文的標題是 Go+ 補全 Python 生態(tài)。

Go+ 和深度學習編譯器

上文提到了深度學習技術。這是 Python 被廣泛使用的另一個領域，和數(shù)據(jù)科學有自然的聯(lián)系，比如 PyTorch 和 TensorFlow 的 tensor 數(shù)據(jù)結構和 numpy 的 ndarray 一樣。而在深度學習領域，編譯器是最新的主流研究方向。

Go 社區(qū)里目前后臺系統(tǒng)開發(fā)者居多;視頻直播時，有聽眾在彈幕里說自己不是 AI 工程師，不關注 AI。如果真的這么想，恐怕不只是技術理想問題，而且是對飯碗不負責任了。

后臺系統(tǒng)和 AI 系統(tǒng)之間的界限越來越模糊，因為后臺系統(tǒng)指的是互聯(lián)網(wǎng)服務的后臺系統(tǒng);而整個互聯(lián)網(wǎng)經(jīng)濟建立在用不眠不休的服務器取代人來服務大眾，而 AI 是這個邏輯成立的基礎，詳見我的一篇老文[7]，例數(shù)了最近二十年被 AI 技術淘汰的人類職業(yè)。

而且這個界限在不久的將來會徹底消失，因為隨著 online learning、reinforcement learning、 imitation learning、federated learning 技術取代 sueprvised learning 成為互聯(lián)網(wǎng)智能(包括傳統(tǒng)的搜索、廣告、推薦，也包括新興的無人駕駛和金融智能)的主流技術，AI 系統(tǒng)將不再能被分為訓練和預測兩部分，也不再由 AI 工程師負責前者，而后臺工程師負責后者了。

在 AI 領域里，深度學習超越傳統(tǒng)機器學習的一個重要原因是：傳統(tǒng)機器的每一個模型(可以理解為對知識結構的描述)往往對應一種甚至多種訓練算法;而深度學習里，幾乎所有模型都用一種算法 stochastic gradient descend(SGD)或者其大同小異的變種來訓練。這樣，基礎架構工程師負責訓練系統(tǒng)的開發(fā);模型研究人員復用之，大大減小了科研的工程負擔，提升了模型研發(fā)的效率。

深度學習系統(tǒng)的核心問題在于 autodiff，這是 SGD 算法的數(shù)學特點決定的。SGD 算法通過交替執(zhí)行前向計算過程(forward pass)和反向計算過程(backward pass)，即可從訓練數(shù)據(jù)歸納出模型的參數(shù)。模型加參數(shù)就是知識。這里的工程挑戰(zhàn)在于模型研究者在定義模型的時候，就附帶描述了前向計算過程，但是反向計算過程很難由人來描述，最好有一個程序自動從前向計算過程推導出反向計算過程。這個自動推導被稱為 autodiff。

目前有兩種 autodiff 的策略。第一種在運行時推導，也被稱為 dynamic net 和 tape-based approach。基本思路是不管前向計算過程有多復雜，哪怕包括 if-else、循環(huán)、函數(shù)定義和調(diào)用、甚至 coroutine 和 multithreading，只要把依次執(zhí)行的基本操作(operator)記錄下來，到一個 tape 里，那么反向計算過程就是回溯這個 tape 里的記錄，并且依次調(diào)用每個 operator 對應的求導數(shù) operator(gradient operator)。這是 PyTorch、TensorFlow eager execution、以及 Paddle Tape 采用的策略。這種策略和編譯器關系不大，和 JIT compilation 有點關系。

另一種策略是運行之前推導反向計算過程，為此需要引入一個專門做 autodiff 的編譯器。TensorFlow graph mode、Caffe/Caffe2、Paddle Fluid、Google Tangent、Julia、Swift for TensorFlow 用的是這個策略。編譯器一般來說是把源語言描述的源程序翻譯成目標語言描述的目標程序。但是前三種技術偷懶了，沒有引入源語言，而是讓用戶通過調(diào)用 Python library 來描述前向計算過程。Google Tangent、Julia、Swift for TensorFlow 分別讓用戶用 Python 語言、Julia 語言、Swift 語言來定義函數(shù)，從而描述前向計算過程，并且能把前向計算函數(shù)翻譯成反向計算函數(shù)。

嚴格地說，Julia 的作者實現(xiàn)了多種 autodiff 方案：有運行時的、也有編譯時的、也有二者混合的。明勝在幫我修改此文時提醒：

For a different vision,where the same language is used to both implement kernels and construct+executeprograms/graphs based on the kernels, see [8].

這里的 kernel 指的是深度學習基本操作單元 operator 的實現(xiàn)。

編譯時和運行時 autodiff 這兩種策略，也都適用于 Go+，而且并不妨礙 Go+ 復用現(xiàn)有技術。就像數(shù)據(jù)科學領域應該復用 LAPACK 這些基礎庫，深度學習領域也應該復用基礎的 operators 和 gradient operators。

運行時用 tape 實現(xiàn) autodiff 的策略的實現(xiàn)更簡單。我記得楊揚用一個星期時間就開發(fā)了 Paddle Tape。而編譯的策略復雜很多。Paddle Fluid 二十多人在 TensorFlow 團隊 Yuan Yu 老師的工作[9]的基礎上，用了好幾個月的時間，才搞定 if-else、循環(huán)、函數(shù)定義和調(diào)用的 autodiff。

這些嘗試提醒我們復用社區(qū)核心技術的重要性。比如，用 MLIR 代替計算圖從而能描述更復雜的控制流 —— 計算圖肯定沒法描述 goroutine 和 select。用 TVM 作為編譯器后段(backend)，用深度學習技術學習如何優(yōu)化深度學習程序。所有這些技術的輸出，都是對基本 operaotor 的調(diào)用。從這個角度看，之前深度學習技術生態(tài)積累的 operators 類似 built-in functions。這也是洪明勝在修改此文時反復提醒的。

希望不久的將來，Go+ 可以作為一種新的深度學習前端語言，與 Python、Julia、Swift 并列，共同復用更底層的 IR、編譯器后段、以及基本 operators。

小結

我理解未來 Go+ 項目的核心戰(zhàn)術工作是：在維持 Go 的語法簡潔性的本色之上，合理準入簡化語法 —— 不要像 Python 和 C++ 那樣融入太多靈活性，同時在 Go 的極簡語法規(guī)范之上，適當?shù)馗屿`活。

此外，通過社區(qū)合作開發(fā) numgo+ 和 GoTorch 這樣的探索性項目，豐富技術生態(tài)是社區(qū)的戰(zhàn)略方向。甚至更進一步，成為一種深度學習編譯器的前端語言，以復用多年來社區(qū)沉淀的深度學習底層計算技術。

最后，感謝老許和 Go+ 的核心貢獻者柴樹杉和陳東坡、Go 社區(qū)的杰出貢獻者 Asta Xie、以及我的同事 ONNX 社區(qū)核心貢獻者張科校閱。

相關鏈接

[1]https://news.ycombinator.com/item?id=23550042

[2]https://www.tensorflow.org/mlir/dialects

[3]https://zhuanlan.zhihu.com/p/38395601

[4]https://github.com/wangkuiyi/notes/tree/master/s4tf

[5]https://github.com/qiniu/goplus/issues/307

[6]https://github.com/qiniu/goplus/tree/master/tutorial

[7]https://zhuanlan.zhihu.com/p/19901967

[8]https://julialang.org/blog/2018/12/ml-language-compiler/

[9]https://arxiv.org/pdf/1805.01772.pdf