Unladen Swallow專案計劃：提高Python速度5倍

注: 根據已經release的兩個版本來看,效能提升只有大概10%左右, 跟目標差距太大了吧... -------------------------------------- Unladen Swallow專案計劃：提高Python速度5倍

來源: Linux論壇 　日期： 2009.03.29 10:05　(共有7條評論) 我要評論

Google的Python工程師發布了一個新項目，目的是讓Python的速度提高至少5倍。新項目名叫Unladen Swallow，意圖尋找新的Python解釋程式虛擬機器，新的JIT編譯引擎。第一季度的目標是實現25-35%的效能提升，目前已經完成，代碼發布在 Google Code 網站上。更多內容和介紹見內 目標 我們要讓Python變的更快，同時我們也希望讓大型的，完好的現存應用無痛苦的轉而使用Unladen Swallow項目。    1. 建立一個比CPython速度至少快5倍的新Python版本。    2. Python應用的表現應該非常穩定。    3. 維持與CPython應用程式在原始碼層級的相容。    4. 維持於CPython擴充模組在原始碼層級的相容。    5. 我們並不是要維護一個長期的Python實現；我們把這個項目當作一個開發分支(branch)，而不是一個版本分支(fork)。 項目概括 為了實現我們對於效能和相容性的目標，我們選擇對CPython進行修改，而不是從零開始開發這個實現。值得強調的是，我們選擇從 CPython 2.6.1著手：Python 2.6與2.4/2.5（當前為大多數有價值的應用使用）和Python 3.0(未來的終極版本)都有可以很好的共存。從一個CPython的版本著手可以是我們避免重新實現大量的內建函數，對象和標準庫的模組，同時讓我們重 用一些現存且常用的CPython的C語言擴充API。從一個2.x CPthon可以讓我們更輕鬆的遷移現存的應用程式；假設我們從3.x開始，並且要求大型應用程式的維護者們率先遷移他們的程式，那對我們項目的受眾來說 是不切實際的。 我們的主要工作是集中力量提高Python代碼的執行速度，而不會在Python的執行階段程式庫上過多的努力。我們的長期計劃是是使用一個建立在LLVM基礎 上的JIT來代替CPython傳統的虛擬機器，同時盡量少的影響Python的運行模式的其他部分。通過觀察，我們發現Python 的應用程式把大量的已耗用時間花費在了主eval迴圈。尤其是，即對例如作業碼調度(opcode dispatch)這樣虛擬機器組件的微小調整也能對Python的運行效能產生重大影響。我們相信通過LLVM的JIT引擎把Python代碼編譯為機器 碼將會帶來更多的益處。 一些顯著的好處：     * 轉向JIT能讓我們把Python從基於堆棧的機(stack-based machine)轉為一個基於寄存器的機(register machine)，實踐證明這種轉變提升了另一個類似語言的效能。     * 其他的先不提，單是消除對收發作業碼(opcodes)的需要本身已經是一項勝利。請參考http://bugs.python.org/issue4753上一個當前CPython對作業碼發送變化的敏感性的討論。     * 目前的CPython虛擬機器作業碼接受/發送限制使進進一步的效能最佳化變得幾乎不可能。舉例來說，我們想實現資料類型回饋(type feedback)和動態重新編譯(dynamic recompilation ala SELF-93)，但是我們認為用CPython編譯的二進位代碼來實現多態性內聯快取（polymorphic inline caches)將是無法接受的慢。     * LLVM尤為值得注意。那是因為它為多個平台產生代碼功能(codegen)的易用性，和它具有把C和C++編譯為同種中間代碼——這正是我們想要帶給 Python的。它能夠讓內聯和交錯解析(inlining and analysis)成為可能，消除這個當前Python和C之間的障礙。 有了產生機器碼的架構，我們就可以把Python編譯為更加高效的實現。以以下這段代碼為例：     for i in range(3):          foo(i) 目前它將被低效的翻譯成這樣     $x = range(3)     while True:          try:              i = $x.next()          except StopIteration:              break          foo(i) 一旦我們有了知道range()代表range()內建函數的辦法，我們可以把它變為類似這樣     for (i = 0; i < 3; i++)          foo(i) 在C語言裡，使用unboxed資料類型進行數學運算，可以把這個迴圈展開為     foo(0)     foo(1)     foo(2) 我們有意將Unladen Swallow的內部結構設計為支援多核心。伺服器將來只會有越來越多的核心，我們要發掘這一點，從而可以在並行結構中完成更多的工作。例如，我們可以用 一個核心作為並行最佳化器，它能在代碼啟動並執行時候進行日益昂貴（重要）的代碼最佳化，用另一個核心來執行代碼本身。我們也在考慮實現一個並行的GC，利用另一 個核心來釋放記憶體模組。由於大多數工業級的伺服器都具有4到32個核心，我們相信這項最佳化的收益是一筆潛在的財富。然而，我們還是要關注高度並行的應用程 序的需要，而不能盲目的消耗掉這些核心。 強調一下，這裡的很多領域已經被其他的一些動態語言考慮或者實現過了，例如jRuby，Rubinius和Parrot, 更包括像Jython，PyPy和IronPython這些其他的Python實現。我們正在從這些其他實現裡尋找有關調試資訊，正則效能以及其他提高動 態語言效能的點子。這是一條已經被很多人走過的路，我們需要盡量避免重新發明輪子的困境。計劃藍圖 Unladen Swallow 將會每3個月發行一個新版本，發行期間進行bug修複。 2009 第一階段 (Q1) Q1主要用來對顯存的CPython實現進行相對小的修改。我們的目標是在目前的基準上實現25-35%的效能提升。這個階段的目標是相對保守的，我們想儘可能快的給客戶應用程式一些看得見的效能最佳化，而不是要他們等到整個項目完成。 2009 第二階段 (Q2) Q2會集中力量來廢除Python的虛擬機器，並用一個具有相同功能的基於LLVM的實現將其代替。我們預期將會有一些效能提升，不過那不是2009Q2的主要任務。我們主要是要得到一個建立在LLVM之上的可以啟動並執行東西。給它提速是本階段之後的人物。 2009 第三階段(Q3)以及將來 從Q3開始的任務將是“簡單的“做好這些作業。我們不渴望做原創工作，而是儘可能的利用近30年來的研究成果。請移步相關論文來瀏覽我們打算實現內容的論文清單的一部分（遠不及全部）。 我們計劃強調對正則引擎何其他被確定為效能瓶頸的擴充模組的考慮。然而，Regex已經被確定為一個很好的目標並且會是我們考慮第一個進行最佳化的領域。 另外，我們打算去除Python的GIL和多線程的狀態。我們相信通過實現一個更進階的GC，這一點是可以實現的，類似IBM的Recycler。 我們的長期目標是讓Python的速度快到可以從把那些為了速度而使用C實現的類型重新用Python取代。 2009Q3準確的效能最佳化目標會在Q2的期間確定。 原文連結: http://code.google.com/p/unladen-swallow/wiki/Proj ectPlan 譯文連結： http://danmarner.yo2.cn/unladen-swallow-project-pl an 原著： Google 譯者： DaNmarner 歡迎轉載，請保留原/譯文連結。 ========================= Unladen Swallow專案計劃——最佳化Python計劃 註：所有引用資料的連結見相關論文。 來源：http://danmarner.yo2.cn/