歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
Linux教程網 >> Linux綜合 >> Linux資訊 >> Linux業界 >> Python狀況:為什麼PyPy是Python的未來?

Python狀況:為什麼PyPy是Python的未來?

日期:2017/2/27 17:32:02   编辑:Linux業界

Python 現在已經不僅僅是膠水腳本語言了. 不信?看看下面使用Python的成功案例:

  • YouTube - 主要由 Python編寫
  • NASA
  • Industrial Light & Magic Runs - 電影公司
  • OpenStack
  • Sage - 科學軟件及其他 (SciPy, PythonXY)
  • WEB框架 Django, Pyramid, bottle...
  • 修訂控制系統
  • 其他不錯的軟件

要是你正在尋找快速介紹美麗的Python語言,我推薦My-Favorite-Python-Things


高級語言是主流

目前高級語言可以寫出簡單具有靈活性的代碼. 所以在快速創建應用程序的時候是一個不錯的選擇, 你不需要花時間來處理各種數據類型 (所有接口示例代碼都是為了滿足編譯處理). 可能有些人就會爭論了,這個特性會產生有bug的代碼. 但是 Guido van Rossum說:“生產的代碼誰會不經過測試呢”? 靜態語言在編譯時期就能處理一些錯誤. 但這並不能檢測出所有的錯誤. 最後你還是得編寫測試代碼。 而有這個時間完全可以為動態語言寫出測試代碼. 此外人們還不能設計一個堪稱完美的類型系統. 對此Jim Treavor寫了一些總結。

新技術允許我們為動態語言設計一個高效的運行環境 (JavaScript V8, LuaJIT, Racket, Common Lisp...), 這也可以和大型的框架競爭 (JVM, .NET, ...)

所有這一切都使得高級語言越來越流行得在大型企業和日常生活中使用。

Python能延續傳奇嗎?
現在Python非常流行,同時它的地位也受到競爭者的挑戰。Python有良好的生態系統,也有大型軟件和社區支持,但它缺乏其競爭者的高效和先進的運行環境。

Python 作為膠水語言.
正如我在開頭說的一個特點,Python很容易連接各種編譯庫,這是它作為膠水語言在20年前流行的重要原因。但是目前依然活躍的工具已經很老舊了,你必須花大量精力才能使用它們。

  • ctypes
  • c 擴展 是邪惡的. 它們綁定到Python的特定版本還不能被重復使用. 更糟糕的是, CPython2和CPython3的c 擴展 API不一樣. 想想將庫移植到Python3會是什麼情況吧!
  • Cython - 這是被設計用來編寫C擴展的. 但是我敢確定,使用C擴展是你最後想做的事. Cython 是一個需要編譯的外部工具. 它最終的代碼並沒有動態行為,但是它的語法還需要學習. Cython不支持類型推斷. 使用Cpython你不得不去編譯. Cython也不是一個標准. 它不能作為解釋代碼來執行. _nuitka_的作者 Kay Hayen在Static Compilation - That is the point總結的非常好.
  • swig, boost - 這些是非常容易的, 通常修改下C/C++ 代碼就可以了, 或者寫一些方案文件.

相比之下,有很多新的工具能在相同的性能下(甚至超出),更好的處理這些任務。
  • cffi - 一個能輕松處理你的c庫的包。在接觸硬件或者支持其他軟件時你會經常做這樣的事(像數據庫客戶端、驅動程序)。嘗試下在python裡使用它是多麼簡單吧。你不需要寫任何的封裝,類型化代碼。而且還有 CPython 和 PyPy 的支持。
  • bitey

將Python作為你代碼的核心 - 膠水語言另一面
膠水語言也有另一面。我們來想想底層高性能編程的過程。可能看起來會是下面幾個過程:
  • 構思
  • 很多復雜的底層代碼和組織機構代碼。很可能是一堆晦澀的泛型代碼(為了重用性)。
  • 編寫膠水語言
  • 編譯
  • 運行
  • 極可能會做很多的調試,然後回去修改,考慮到有這麼多的底層代碼。

感謝Python的簡便性、腳本語言的本質和大量的工具,將他作為你代碼的模板和核心。這就意味著你只需要寫最少的底層代碼,讓Python做剩下的事:生成組織代碼和你的底層代碼需要的環境。

這與以往Lisp的理念一樣,代碼即數據,代碼能夠被其他正在執行的代碼理解(代碼可以作為數據被處理)。因而機器可以理解運行時正在執行的代碼,並且去 優化它,通過通常的方式就能得到全部的數據信息,而不用像C++那樣使用模板。這是C++和其他流行的編程語言所沒有的。最終我們有相對更底層的抽象級 別,而運行時信息相對更豐富,使得編譯器可以:

  • 為未知的硬件做特化 (編碼時),包括支持的數據類型,以及可用的優化方法。
  • 自動調整(tuning) (例如為庫提供的數據,如 ATLAS...)
  • 推送更多的信息給編譯器,得到更好的推理。
  • 人們不用為數據類型煩惱(運行時環境就已經可以保證快速、正確使用數據類型)

於是整個流程就好像這樣:

  • 想法
  • 一點Python代碼(最棒的部分),用來構建整個架構。然後是一些底層的代碼 ,同樣很棒,因為這些代碼沒有惡心的模板和上下文代碼。事實上,底層的代碼也可以通過Python代碼生成。
  • 運行
  • 調試,比起前面的步驟時間更短一些

就性能而言,這樣的過程相比之前的方法有著更好的前景。

這些是已經用到這種方式的:PyPy, cffi, PyOpenCL, PyCUDA, numba, theano...

把Python當做一個高速語言

有很多方法能用Python寫出高速的代碼。最流行而且仍在廣泛傳播的方法是,用底層語言來寫應用裡最復雜的部分,然後使用,這對python來說無疑是很不幸的事。

所有Python裡出色的高效的工具都需要許多復雜的c代碼,這阻礙了其他的貢獻者進來。現在我們想要寫出高速而且美觀的python代碼。

有很多工具可以把python代碼編譯成機器代碼,比如:Nuitka, Python2C, Shedskin, pythran。我認為它們都是失敗的,當你使用它們的時候,就需要跟動態行為說再見了。他們只支持一部分的python語言,並且離完全支持還有很大距 離。我甚至不認為以後他們能做到。另外他們也沒有用那些使JIT(Just-In-Time 運行時編譯執行)的解決方案變得出色的先進的技術和運行時信息。

多核編程
這方面,Armins Rigo的文章寫的很棒,可以參考:Multicore Programming in PyPy and CPython

解釋器的設計

為了讓下一步的開發更簡單,實現動態語言的最佳狀態,Python需要一個合適的架構。當前CPython的架構過於簡單,因而限制比較大,很難做到像JIT編譯器那樣的功能。下面是一些在增強CPython解釋器性能上的失敗的努力:

  • psyco (被PyPy代替)
  • Unladen swallow
  • 消除GIL的很多失敗的嘗試
  • 還有一些嘗試修復CPython一些缺陷的嘗試: Stackless和HotPy,但是Guido (Python之父,仁慈的獨裁者) 的堅持使得這些項目沒有被合並到Python中。(說明一下,HotPy還不是產品級的東西)。

CPython最大的問題是他的C API,這部分沒有很好的設計。其他部分的實現多少都受此影響。

我們能做什麼?

  1. 在粘結代碼中推進新工具的使用 ( cffi, bitey)
  2. 在公共庫中停止對CPython的底層屬性(C API,C擴展)的依賴。作為替代,采用有如下功能的中間工具:
  • cffi - 簡化對C庫的應用
  • cython - 編寫可移植的C擴展。我並不推薦它用於通常的編程,不過它確實在維護C擴展方面更好一些,也更簡單。Cython已經有CPython和PyPy後端。


為何 PyPy 是趨勢?

PyPy為優化和進一步的語言開發提供了更好的架構。對於大部分Python已有的問題,PyPy已經提供了解決方案:

  • 先進的runtime和設計,在此文中作了介紹: The Architecture of Open Source Applications.
  • 速度 - PyPy內置的JIT很棒,有時(其實很少)甚至可以與C相提並論。
  • GIL問題 - PyPy引入了一個很棒的STM實現,在 Armins Rigo的 文章中對此作了介紹。
  • 粘合代碼 - 使用cffi可以簡單的處理C庫,甚至比CPython的ctypes還要快!
  • 異步編程。這方面,PyPy內置的 greenlet 比CPython的C擴展更適合一些。實際上,非堆棧式的概念(也即greenlet)在PyPy中還在繼續發展(參看https://ep2012.europython.eu/conference/talks/the-story-of-stackless-python)
  • 沙盒技術
  • 應用在web和移動中。這裡有Dusty的一些文章:Pushing Python Past the Present

PyPy已經支持多平台 (x86, 64_x86, ARM)

PyPy同時還包含了一個優秀的現代的架構,在 Jim Huang 的演講 中做了介紹,演講的要點是:

  • 解釋性語言的框架
  • 用於研究和產品的組件組合 (不同的數據模型,垃圾回收 - 這些可以在具體的應用場景進行改變)
  • 構建在基於組件鏈的功能架構之上(翻譯工具鏈)。每一個步驟都會延續/轉換程序模型、引入特征、各種後端(JVM, JavaScript, LLVM, GCC IR等等)。來看一下翻譯鏈的例子:python 代碼 -> 字節碼 -> 函數對象 -> 類型推斷 -> 垃圾收集器 -> JIT
  • 包含大量在架構的不同層次開發的現代的優化技術 (這個任務可以簡化)

相信讓所有軟件支持PyPy需要付出艱巨的努力 - 需要在現有的庫上做很多工作。不過使用新的工具,編寫支持PyPy和CPython的軟件會比采用C擴展的方式更簡單一些(在我們能做什麼一節有介紹)。

CPython遺留問題
現在來說一下CPython依賴性代碼的遺留問題 (源於它們緊密依賴 c 擴展)。 這些主要是科學相關的軟件 (NumPy, SciPy 等等)。Python在PyPy成為產品級軟件之前早就被用於科學計算(我認為實在2年之前),之後這些軟件在工具、代碼和社區方面都得到很多發展。這些 軟件一起構建了一個很棒的平台,通常被用來作為Matlab之類的軟件的替換(有人甚至認為是更好的選擇)。要實現這些,C擴展是目前唯一的解決方案。現在,這些軟件的發展仍然與CPython緊密綁定,因為要讓科學計算相關的軟件全部支持PyPy,需要大量的工作。近似的方案是使用按需執行的JIT - 對特定的函數做修飾,然後動態的把它們編譯成機器碼並切換到使用c擴展。這個想法不需要重寫所有的科學計算的平台,而速度同樣快速。采用這種方式的典型項目是numba,這是由Continuum Analytics (這家公司主要發布基於python庫的強壯的科學計算平台)贊助的。Numba采用這種方式是因為它的快速腳本需要與其他依賴CPython的科學計算代碼兼容。numba值得學一下,SciPy會議的 numba演講 是一個很好的闡述。

不得不說Python的科學計算社區非常棒。他們非常關注於質量、易用性和推廣他們的產品(為此組織了很多會議:SciPy大會,PyData等)。感謝 他們讓Python成為免費的科學分析平台的首選。這裡還需要提一下Travis Oliphant,他在社區中付出了很多努力,讓整個平台協調一致。關於這些可以看一下這篇博客文章:為何Python是你最終必須學習的編程語言

PyPy呢?
我希望PyPy當時並沒有達到產品級可用。

後續
關於本文的後續在Reddit上有一個有趣的討論。這是關於在商業上應用PyPy的優缺點的討論。討論者總結了如何使用基於高性能庫的PyPy。最重要的是使用PyPy軟件棧(原始Python、cffi,等等)可以讓維護和優化很簡單(例如:延遲計算)。至於缺點,上面提到了,主要與CPython的遺留問題有關。

Copyright © Linux教程網 All Rights Reserved