在利用 Python 與 R 的數據科學堆棧工作了幾個禮拜之后，我開始問自己：有沒有可能存在一種通用的中間表示形式（類似于 CUDA），能夠在多種語言之間同時起效？現在我必須得在不同語言中重新實現并優化已經存在的方法，難道就不能更高效一點？除此之外，我希望通過通用的運行對程序進行整體優化，而不是像現在這樣只能針對函數進行優化。經過幾天的研究和測試，我發現了 Weld。令我意外的是，Weld 的締造者之一正是 Matei Zaharia，也就是 Spark 的發明者。

正因為如此，我聯系并采訪了 Weld 項目的主要貢獻者 Shoumik Palkar。Shoumik 目前是斯坦福大學計算機科學系的博士生，在 Matei Zaharia 的推薦下加入了 Weld 項目。

Weld 還遠沒有達到生產就緒級別，但其發展愿景卻是一片光明。如果大家對數據科學的未來以及 Rust 抱有興趣，相信這次訪談會給你帶來不少啟示。 

開發 Weld 項目的動機是什么，它又能夠解決哪些問題？

項目的開發動機，在于為依賴現有高級 API（例如 NumPy 與 Pandas）的應用程序提供裸機級別的性能表現。其解決的主要問題，是實現跨函數與跨庫層面的優化，而這正是目前其他庫所無法實現的。具體來講，當下有不少常用庫以各個函數為基礎提供算法的最新實現（例如以 C 語言在 Pandas 中實現的快速連接算法，或者以 NumPy 語言實現的快速矩陣乘法），但市面上卻還不存在能夠跨越這些函數實現優化的可用工具（例如在執行矩陣乘法后進行聚合時，防止不必要的內存掃描）。Weld 希望提供一個可通用的運行時，使各個庫能夠在通用 IR 當中進行計算表達；接下來，開發人員還可以利用編譯器優化程序對 IR 進行優化，而后通過循環融合、矢量化等優化手段將 JIT 與并行本機代碼加以對接。Weld 的 IR 具備本機并行特性，因此開發人員可以隨時對其中表示的程序進行常規并行化處理。

我們還建立了一個名為拆分注釋（split annotations）的新項目，該項目將與 Weld 相集成，旨在降低對現有庫進行優化的實施門檻。

對 Numpy、Pandas 以及 Scikit 進行優化困難嗎？速度方面能有多大提升？

Weld 跨越各個函數對這些庫進行優化，而對庫的整體優化也能讓單一函數的調用速度更快。實際上，不少此類數據庫都已經立足函數層面進行了高度優化，只是由于其沒有充分利用并行性或者內存結構，所以性能表現仍然低于現代硬件的極限水平。舉例來說，目前已經有不少 Numpy ndarray 函數可以在 C 語言中實現，但調用每一項函數都需要對每一條輸入進行完整掃描。如果這些數組不適用于 CPU 緩存，那么大多數執行時間就都被耗費在了從主內存中加載數據上，計算的執行反而成了次要耗時因素。Weld 能夠查看各個函數調用并執行優化，例如循環融合，從而將數據保留在 CPU 緩存或者寄存器當中。憑借著更好的擴展能力，這些類型的優化能夠在多核心系統上將性能提升一個數量級甚至更高。

與 Weld 原型方案進行集成之后，Spark（左上）、NumPy（右上）以及 TensorFlow（左下）的性能相較于原始框架提高了 30 倍，且無需對用戶的應用程序代碼做出任何調整。此外，Pandas 與 NumPy 之間的跨庫優化（右下）則可將性能提升達兩個數量級。

Baloo 是什么？

Baloo 是一個庫，負責利用 Weld 實現 Pandas API 中的一個子集。Baloo 由阿姆斯特丹 CWI 研究所碩士生 Radu Jica 開發完成，其目標是在 Pandas 當中完成之前提到的各項優化，從而提高其單線程性能、減少內存占用量并引入并行性。

Weld/Baloo 是否支持利用核外計算（例如 Dask）處理不適合駐留在內存中的數據？

Weld 與 Baloo 目前都還不支持核外計算，但我們歡迎更多開源貢獻者能夠實現這一功能！

你們為什么選擇利用 Rust 與 LLVM 來實現 Weld？Rust 一直是你們的第一選擇嗎？

我們之所以選擇 Rust，是因為：

• Rust 的運行時很小（基本上只負責對數組進行邊界檢查），而且易于嵌入到其他語言（例如 Java 與 Python）當中。
• Rust 包含函數式編程范式，例如模式匹配，能夠使代碼編寫（例如模式匹配編譯器優化）更輕松。
• Rust 擁有強大的技術社區與高質量的工具包（在 Rust 中被稱為“crates”），這使我們能夠更容易地進行系統開發。

在另一方面，之所以選擇 LLVM，是因為它擁有一套用途廣泛且廣受支持的開源編譯器框架。我們能夠直接生成 LLVM 以替代 C/C++，因此不必依賴于 C 編譯器，從而縮短編譯時間（過程中不需要解析 C/C++ 代碼）。

Rust 并不是 Weld 采用的第一款實現語言；最初，我們選擇的是 Scala，當時主要考慮到它擁有代數數據類型以及強大的模式匹配機制。這能夠極大簡化編譯器核心部分優化器的編寫過程。我們最初的優化器基于 Catalyst 設計，該設計器屬于 Spark SQL 的可擴展優化器。但最終之所以放棄了 Scala，是因為我們發現很難將基于 JVM 的語言嵌入至其他運行時與語言當中。

如果 Weld 主要針對 CPU 與 GPU，那么它與 RAPIDS 這類專門面向 GPU 的 Python 數據科學實現庫有什么不同？

Weld 項目與 RAPIDS 等其它系統的最大區別，在于它專注于跨越多種由 JIT 編譯代碼編寫的內核實現應用程序優化，而非針對每一項獨立函數提供優化效果。舉例來說，Weld 的 GPU 后端能夠為端到端應用程序 JIT 編譯出經過優化的單一 CUDA 內核，而不像其它系統那樣直接調用現有獨立內核。此外，Weld 的 IR 意欲設計為硬件無關的，使其既能夠面向 GPU，也可以面向 CPU 或者矢量加速器等其它定制化硬件。當然，Weld 也與其它系統有著不少交集，同時也受到了 RAPIDS 等其他同類項目的影響與啟發。Bohrium（一種懶惰評估式的 NumPy）以及 Numba（一套可實現數字代碼 JIT 編譯的 Python 庫）就與 Weld 有著相同的高級目標，而 Spark SQL 等優化器系統則直接影響著 Weld 的優化器設計思路。

除了數據科學庫優化之外，Weld 項目是否還有其他應用？

Weld 的 IR 最令人興奮的優勢之一，在于其自身就支持數據并行性。這意味著在 Weld IR 當中表達的循環將始終可以安全實現并行化。這使 Weld 成為一種對新型硬件極具吸引力的 IR 解決方案。舉例來說，NEC 公司的合作者們演示了如何利用 Weld 在自定義高內存帶寬矢量加速器上運行 Python 工作負載——過程非常簡單，只需要向現有 Weld IR 添加新的后端即可。此外，IR 還可用于在數據庫內實現物理執行層，我們也在計劃添加一系列新的功能，使開發人員能夠將 Python 的部分子集編譯為 Weld 代碼。

這些庫是否已經準備好應用于實際項目？如果還沒有，你認為大概什么時候能夠做好準備？

我們測試過的大部分庫示例與基準都提取自真實工作負載。因此，如果用戶愿意在自己的應用程序當中試用我們發布的當前版本，提供反饋甚至編寫開源補丁，我們將不勝感激。換句話說，我們并不指望所有功能都能在現實應用程序當中立即使用。在接下來的幾個月內，我們將發布一系列發行版，專門關注 Python 庫的可用性與健壯性。我們的目標是努力提升這些庫的質量，將其逐步引入現實項目當中，并在無法支持的情況下允許用戶順利回退至非 Weld 庫版本。

正如我在回答第一個問題時所提到，簡化整個流程的途徑之一，在于拆分注釋這個重要的相關項目。拆分注釋是一套系統，允許用戶對現有代碼進行注釋以定義其具體拆分、傳遞與并行化方法。根據我們的觀察，該系統能夠發現 Weld 有望帶來最佳效果的優化方向（例如在函數調用之間將大量數據保留在 CPU 緩存中，而非掃描完整數據集）；更重要的是，由于其重用現有庫代碼，而非依賴于編譯器 IR，因此其集成難度要比 Weld 低得多。正因為如此，拆分注釋能夠使作為優化目標的庫更易于維護與調試，從而提高健壯性水平。當無法支持 Weld 時，這些庫也可退回至拆分注釋，讓我們根據用戶提出的反饋以增量方式添加 Weld 支持，同時繼續采取可行的優化操作。