PyParallel：Python的一個快速並行版本

PyParallel是Trent Nelson發起的一個研究項目，其目標是以提供高效能非同步支援的方式將Windows I/O完成連接埠（IOCP）的強大功能移到Python中。

Python的非同步支援多少有點問題。它是圍繞Unix/Linux的非同步、非阻塞I/O理念設計的。線程會持續輪詢進入的資料，然後相應進行分發。儘管Linux針對該模式進行了調優，但在Windows機器上，這種處理方式是效能的災難。將資料從輪詢線程複製到真正處理任務的線程，非常昂貴。

PyParallel帶來的就是使用了原生IOCP的真正的非同步。在IOCP模型下，每個核有一個線程。每個線程負責處理完成I/O請求（比如，從網卡複製資料）和執行請求相關 App層回調。

只有這一點尚不足以橫向擴充Python；還需要解決GIL（Global Interpreter Lock，全域解譯器鎖）帶來的問題。否則我們仍然被限制於每次執行一個線程。使用細粒度的鎖替換GIL，結果會更糟糕；像PyPy中的軟體事務記憶體往往最終會導致1個線程繼續推進，N-1個線程持續重試的問題。所以我們需要別的解決方案。

對PyParallel團隊來說，這個解決方案就是不允許自由建立線程。換言之，應用不能隨意建立新線程。相反，並行操作被綁定到非同步回調機制和並行上下文（parallel context）的概念。

在深入並行上下文之前，我們先反過來看一下。當並行上下文不啟動並執行時候，主線程會運行；反之亦然。主線程就是你進行正常的Python開發所考慮的東西。主線程持有GIL，對全域命名空間具有完全的存取權限。

相反，並行上下文對全域命名空間只能進行唯讀訪問。這意味著，開發人員需要注意某個事物是主線程對象還是並行內容物件。處理過套間執行緒模式（apartment threading models）的COM程式員對其中的痛苦是再清楚不過了。

對於非I/O任務，主線程使用async.submit_work函數對任務進行排隊，然後使用async.run 函數切換到並行上下文。這會掛起主線程，並啟用並行解譯器。多個並行上下文可以同時運行，由Windows作業系統處理線程池的管理。

與GIL並行

有一點非常重要，需要注意一下，這裡並沒有建立多個進程。儘管多進程技術在Python開發中很常用，但PyParallel將所有東西都放在了一個進程中，以減少跨進程通訊的代價。這通常是不允許的，因為CPython解譯器不是安全執行緒的，這包括：

全域待用資料會頻繁用到

引用計數不是原子的

對象沒有用鎖保護

垃圾收集不是安全執行緒的

拘留字串（Interned string）的建立不是安全執行緒的

bucket記憶體 Clerk不是安全執行緒的

arena記憶體 Clerk不是安全執行緒的

Greg Stein曾嘗試通過向Python 1.4中加入細粒度的鎖來解決該問題，但是在單線程代碼中，他的項目導致速度下降40%，所以被拒絕了。因此Trent Nelson決定採用不同的方案。在主線程中，GIL和原來一樣運作。但是當在並行上下文中啟動並執行時候，會使用安全執行緒的替換方案代替核心函數來運行。

Trent的方案的代價是0.01%，比Greg的方案好得多。至於PyPy的軟體事務記憶體，對單執行緒模式而言，其代價大概是200～500%。

該設計的一個有趣的地方是，在並行上下文中啟動並執行代碼，當要從全域命名空間中的對象中讀取資料時，不需要獲得鎖。不過它只有讀的能力。

PyParallel沒有垃圾收集器

為了避免處理記憶體配置、存取和垃圾收集相關的鎖，PyParallel使用了一種無共用模式。每個並行上下文都有自己的堆，沒有垃圾收集器。就是這樣，沒有與並行上下文關聯的垃圾收集器。因此實際上是這樣：

記憶體配置使用一個簡單的塊分配器完成。每次記憶體配置只是調整一下指標。

根據需要分配4K或2MB大小的新頁面，這由並行內容相關的大版面設定控制。

不使用引用計數。

當並行上下文結束時，與它關聯的所有頁面同時釋放。

這種設計避免了安全執行緒的垃圾收集器或安全執行緒的引用計數的代價。另外，它支援前面提到的塊分配器，這可能是最快的記憶體配置方式了。

PyParallel團隊認為這種設計可以成功，因為並行上下文意在支援生命週期較短、範圍較為有限的應用。一個很好的例子是並行排序演算法或Web頁面請求處理常式。

為使這種設計正常工作，在並行上下文中建立的對象不能逃逸到主線程中。這是通過唯讀訪問全域命名空間這一限制來保證的。