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