在Python涵蓋的許多用例中，資料分析可能已經成為最大和最重要的用例。Python生態系統中充滿了庫、工具和應用程式，這些使科學計算和資料分析工作變得快速和方便。

但是對於Julia語言背後的開發者來說，python還不夠快，也不夠方便。Julia語言的目標是“科學計算、機器學習、資料探勘、大規模線性代數、分散式和平行計算”。Julia的目標不僅是給科學家和資料分析師提供快速便捷的發展，同時也提供驚人的執行速度。

具體請看可以從二者各自的優勢簡單瞭解一下：

Julia語言的優勢

對應Julia 和Python，Julia從一開始就是為科學和數值計算而設計的。因此，對於這樣的用例場景，Julia有許多優勢的特性也就不足為奇了，諸如:

Julia執行速度快。Julia的JIT編譯和型別宣告意味著它通常可以在數量級上擊敗“純的”、未最佳化的Python。可以透過外部庫、第三方JIT編譯器(PyPy)以及Cython等工具的最佳化來加快Python的速度，但是Julia被設計為一開始就實現加速執行。Julia有一個數學友好的語法。Julia的主要目標受眾是科學計算語言和環境(如Matlab、R、Mathematica和Octave)的使用者。Julia的數學運算語法看起來更像是在計算世界之外而編寫數學公式的方式，讓非程式設計師更容易上手。Julia有自動的記憶體管理功能。與Python一樣，Julia不會讓使用者負擔分配和釋放記憶體的細節，而且它提供了一些對垃圾收集的手動控制措施。其思想是，如果您切換到Julia，您不會失去Python的一個常見便利。Julia提供了優越的並行性。當您可以利用給定機器(特別是多核)上的全部可用資源時，數學和科學計算將更能蓬勃發展。Python和Julia都可以並行執行操作。然而，Python用於並行化操作的方法通常需要線上程或節點之間序列化和反序列化資料（甚至常要藉助第三方庫），而Julia的並行化更加精細。此外，Julia的並行化語法沒有Python的那麼頭重腳輕，降低了使用它的門檻。Julia正在開發自己的原生機器學習庫。Flux是一個面向Julia的機器學習庫，它有許多針對常見用例的現有模型模式。因為它完全是用Julia編寫的，所以使用者可以根據需要修改它，並且它使用Julia的原生即時編譯來從內到外最佳化專案。Python的優勢

儘管Julia是專門為資料科學而構建的，而Python或多或少地充當了這個角色，但Python為資料科學家提供了一些引人注目的優勢。由於一些“通用目的”原因,Python可能是資料科學工作的更好的選擇:

Python使用從零開始的陣列索引。在大多數語言中，包括Python和C語言，陣列的第一個元素是用0 訪問的- 例如在Python中，string[0]表示字串中的第一個字元。Julia對陣列中的第一個元素使用1。這不是一個武斷的決定，而許多其他的數學和科學應用程式，比如Mathematica，也從1開始索引，而Julia就是為了吸引這些使用者。在Julia中可以透過一個實驗性的特性來支援0索引，但是預設情況下從1開始的索引可能會阻礙那些具有根深蒂固程式設計習慣的更通用的使用者的採用。Python的啟動開銷更少。Python程式可能比Julia程式慢，但是Python執行時本身更輕量，通常Python程式啟動和交付第一個結果所需的時間更短。而且，雖然JIT編譯加快了Julia程式的執行時間，但它的代價是較慢的啟動速度。為了加快Julia的啟動速度，我們做了很多工作，但是Python在這方面仍然有優勢。Python是很成熟。Julia語言還很年輕的。Julia從2009年開始才處於開發階段，並且在開發過程中經歷了相當多的功能變動。相比之下，Python已經存在了近30年。Python有更多的第三方包。Python的第三方包文化的廣度和實用性仍然是該語言最大的吸引力之一。同樣，Julia相對較新，意味著圍繞著它的軟體文化還很小。雖然可以使用現有的C和Python庫來彌補這一點，但是Julia需要自己的庫來發展。像Flux和Knet這樣的庫讓Julia對機器學習和深度學習很有用，但是這種型別的大部分工作仍然是透過TensorFlow或PyTorch完成的。Python有數百萬使用者。沒有一個龐大的、投入的、活躍的社群，一門語言就什麼也不是。圍繞著Julia的社群熱情高漲，而且還在不斷增長，但它仍然只是Python社群規模的一小部分。Python龐大的社群是一個巨大的優勢。Python越來越快了。除了獲得Python直譯器的改進(包括對多核和並行處理的改進)之外，Python變得更容易加速。mypyc專案將帶型別註釋的Python轉換為本地C語言，遠沒有Cython那麼笨重。它通常會產生四倍的效能改進，對於純粹的數學運算，效能改進通常會更多。

是否能超越Python不好說，不過Julia 語言發展確實非常迅速，它可以視為同時具備了 Python 的靈活性與 C 的速度，但目前 TensorFlow 和 PyTorch 等框架官方都不支援 Julia 語言。因此近日有研究者藉助 XLA 底層編譯器為 Julia 構建 TPU 支援，他們表示該方法能夠將 Julia 程式編寫的 VGG19 模型融合到 TPU 可執行檔案中，並呼叫 TPU 實現高效計算。而 Google.ai 的負責人 Jeff Dean 在推特上也表示「Julia + TPUs = fast and easily expressible ML computations!」

1. 引言

過去的幾年裡推動機器學習技術穩步發展的根本性改變之一是訓練和最佳化機器學習模型的巨大計算力。許多技術都是很年前就已經提出，唯有近幾年提升的計算力可以為現實世界的問題提供足夠優質的解決方案。這些計算能力的很大一部分是透過 GPU 獲取的，其針對向量的計算能力最初是為圖形而設計的，但機器學習模型通常需要執行復雜的矩陣運算，因此 GPU 同樣表現出了非常好的效能。

這些方法及 GPU 在現實世界，尤其是在機器學習領域的成功引發了硬體設計者的一系列創新，他們致力於為機器學習工作負載研發新的加速器。然而，儘管 GPU 很長一段時間都在 CUDA 等軟體系統發力，但這些庫通常不會擴充套件到新的非 GPU 加速器，為這些加速器開發軟體仍然是一大挑戰。

2017 年，谷歌宣佈他們將透過雲服務向大眾提供他們專有的 TPU 機器學習加速器。最初，TPU 的使用侷限於根據谷歌 TensorFlow 機器學習框架編寫的應用。幸運的是，2018 年 9 月，谷歌透過底層 XLA（Accelerated Linear Algebra）編譯器的 IR 開放了 TPU 的訪問許可權。這個 IR 是一個通用的最佳化編譯器，用於表達線性代數基元的任意計算，因此為使用 TPU 的非 TensorFlow 使用者以及非機器學習工作負載提供了良好的基礎。

在本文中，我們介紹了使用這個介面編譯通用 Julia 程式碼的初步工作，它們可以進一步訪問谷歌雲的 TPU。這一方法與 TensorFlow（Abadi et al., 2016）採用的方法形成對比，後者沒有編譯 python 程式碼，而是先用 Python 構建一個計算圖，然後再對這個計算圖進行編譯。它在美學上類似於 JAX（Frostig et al., 2018），JAX 的目標是透過跟蹤和 Offload 高階陣列運算來 Offload Python 本身編寫的計算。然而重要的是，我們不依賴於追蹤，而是利用 Julia 的靜態分析和編譯能力來編譯整個程式，包括傳遞到裝置端的所有控制流。

值得一提的是，我們的方法允許使用者在編寫模型時充分利用 Julia 語言的表現力。這些表現力主要體現在一些高階特徵上，如多重派發、高階函式和現有庫，如微分方程求解器（Rackauckas & Nie，2017）和通用線性代數例程等。由於只在純 Julia 程式碼上執行，所以它也與 Zygote.jl（Innes, 2018）自動微分工具相容，該工具能執行自動微分作為高階編譯過程。總的來說，我們能夠編譯使用 Flux 機器學習框架編寫的完整機器學習模型，將模型的前向、反向傳播及訓練迴路融合成一個可執行檔案，並 Offload 到 TPU 中。

論文：Automatic Full Compilation of Julia Programs and ML Models to Cloud TPUs

論文連結：https://arxiv.org/abs/1810.09868

摘要：谷歌的雲 TPU 是一種前景廣闊的新型機器學習工作負載硬體架構，近年來已經成就了谷歌很多里程碑式的機器學習突破。如今，谷歌已經在其雲平臺上為大眾提供 TPU，最近又進一步開放，允許非 TensorFlow 前端使用。我們描述了一種透過這一新 API 及谷歌 XLA 編譯器將 Julia 程式的適當部分 Offload 到 TPU 的方法和實現。我們的方法能夠將 Julia 程式編寫的 VGG19 模型及其正向傳播完全融合到單個 TPU 可執行檔案中，以便 Offload 到裝置上。我們的方法與 Julia 程式碼上現有的基於編譯器的自動微分技術很好地結合在一起，因此也能夠自動獲得 VGG19 反向傳播並採用類似的方法將其 Offload 到 TPU。使用我們的編譯器訪問 TPU，我們能夠在 0.23 秒內完成批次為 100 張影象的 VGG19 前向傳播，而 CPU 上的原始模型則需要 52.4s。我們的實現僅需不到 1000 行的 Julia 程式碼，無需根據 TPU 對核心 Julia 編譯器或任何其他 Julia 包進行特有的更改。

7 結果

7.4 在 TPU 上進行評估

圖 2：不同批大小對應的 VGG19 前向傳播時長。

圖 3：被編譯為 XLA 後，Metalhead.jl VGG19 前向傳播和反向傳播的指令數分解。