Dropbox正開發的開源Python 解釋器Pyston的實例分析

這期內容當中小編將會給大家帶來有關Dropbox正開發的開源Python 解釋器Pyston的實例分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

大家好，我非常激動宣布 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。

上述就是小編為大家分享的Dropbox正開發的開源Python 解釋器Pyston的實例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。