[[333937]]

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

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

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

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

我現(xiàn)在在螞蟻集團工作，負(fù)責(zé)一個開源 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ù)科學(xué)家們用來替代之前各種昂貴的商業(yè)化系統(tǒng);在隨后誕生的深度學(xué)習(xí)領(lǐng)域，Python 也迅速蓬勃發(fā)展起來。

Python 的局限

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

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

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

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

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

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

Python 的語法豐富、靈活性強，所以解釋器寫起來很復(fù)雜，要優(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 標(biāo)準(zhǔn)語法的編譯器出來。幾個嘗試因此作罷。目前的普遍的做法是解釋器來做執(zhí)行時優(yōu)化(JIT compilation)，因為有 runtime 信息，所以相對編譯器更容易一些。

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

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

補全局限的嘗試

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

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

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

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

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

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

在 Go+ 出現(xiàn)之前，也有把 Go 用于數(shù)據(jù)科學(xué)的嘗試，也有用 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+ 來自動推導(dǎo)數(shù)據(jù)類型，寫法就和 Python 幾乎一樣了：

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

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

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

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

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

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

Go+ 和深度學(xué)習(xí)編譯器

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

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

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

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

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

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

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

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

嚴(yán)格地說，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 指的是深度學(xué)習(xí)基本操作單元 operator 的實現(xiàn)。

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

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

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

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

小結(jié)

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

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

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

相關(guān)鏈接

[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