大家好，我非常激動宣佈 Pyston，這是一個正在由 Dropbox 開發的開源 Python 直譯器。 這個專案的目標是產生一個高效能的 Python 直譯器，使 Python 也能用於那些被如 C++ 這樣的傳統系統語言佔據的領域。
在 Dropbox ，我們熱愛 Python ，嘗試用它來做一切可以做的事情。然而隨著規模的的變大和要處理的問題越來越多，我們開始發現繼續使用 Python 而要達到我們的效能目標有時候極其困難。有時用另外一門語言重寫也起不了多大作用。我本人非常喜歡 Python ， 每次當我們決定重寫什麼東西的時候我都很受傷，所以我想為它做一點什麼。在靜態編譯上做了一些無用功後，我們到處查資料然後發現 JIT 技術在 Javascript 上非常成功，尤其 是 Chrome 的 V8 引擎大大地改善了 Javascript 的效能。我們希望透過同樣的技術也能在 Python 上達到相同的效能提升。
Pyston 現在仍然處於初期階段，還不能投入使用。但我們希望早點在它的生命週期之初就公佈並開源出來，這樣我們就能和 Python 和 JIT 社群來合作開發了。太多的細節在這篇部落格寫不下，但我們想說一下我們為什麼需要一個新的 Python 實現，以及講一點點 Pyston 是怎麼工作的。
為什麼選擇實現一個新的 Python 直譯器
早就已經有了一大堆使用 JIT 技術的 Python 實現：PyPy 使用它的 tracing JIT 來提高效能；Jython 和 IronPython 都是構建在廣泛支援 JIT 的虛擬機器上的。所以為什麼我們認為還值得開始創造一個新的實現呢？
簡單來說，是因為我們認為絕大多數有前景的技術都和現有的實現不相容。比如，在 Javascript 界就因為強大的效能優勢從 tracing JIT 切換到 method-at-a-time JIT 。對 Python 是否有同樣的效能優勢還有待商榷，但由於這兩種途徑從根本上都是和現有的實現不相容的，所以答案只能是構建一個新的 method-at-a-time JIT。
另外一個區別是我們對傳統的垃圾回收器有計劃地使用來高效地支援擴充模組。同樣，我們現在也無法知道這是否是一種更好的方法，但這個決定對一個很難在現有的實現下進行測試的 JIT 來說是必不可少的。
從零開始的壞處就是，創造一個新的語言的實現毋庸置疑是一個巨大的任務。幸運的是， 有助於這個過程的一些工具已經開始出現了。尤其是 Pyston 是構建在 LLVM 之上的，使得我們不需要自己處理細節就可以生成上層的高質量程式碼。儘管如此，一個新的 Python 實現還是一個巨大 的工程，所以 Pyson 將不會馬上就能投入使用。
它是怎麼工作的
從頂層看，Pyston 將解析好的 Python 程式碼轉換成 LLVM 中間程式碼。然後中間程式碼就透過 LLVM 的最佳化然後傳遞給 LLVM 的 JIT 引擎，產生可執行的機器程式碼。LLVM 包含許多最佳化步驟和機制，使得它能產生非常快的程式碼。
然而問題是 LLVM 不能推出 Python 程式碼，因為動態語言不得不把所有底層的行為都隱藏在型別分派(Type Dispatch)後。為了解決這個問題，Pyston 採用型別推斷：雖然證明一個變數將會是某個特別的型別通常是不可能，但是 Pyston 經常可以根據一些確定的事實來預測某個物件會是什麼型別。一旦做出 了一個預測，Pyston 將在執行時檢測這個預測，在預測所對應的快速分支和預測失敗所對應的慢速分支之間進行選擇。
Pyston 還包含許多其他的現代技術，比如為快速查詢屬性和快速呼叫方法而設計的隱藏類和內聯快取。你可以在 Github 頁面上找到更多的技術細節，以及一篇單獨講述這些技術細節的博文。
現狀
Pyston 仍然處於初始階段，只支援 Python 語言的一個最小子集。拿基準測試資料來說話是不怎麼公平的，因為 1) Pyston 不支援足夠大的基準測試，所以這不具備代表意義。2) Pyston 不支援所有執行時特性（包括一些可能帶來減速的特性），所以這不是一個同類的比較。 在這兩點注意事項下，Pyston 在效能上通常可以擊敗 CPython，但是仍然弱於 PyPy。
程式碼以 Apache 2.0 許可證釋出在 Github 上，技術文件正在增加。還有大量的工作需要做， 我們正在擴張團隊：如果你對這類事感興趣，請聯絡我們！