當你在機器上啟動某個程序時，它只是在自己的“bubble”里面運行，這個氣泡的作用就是用來將同一時刻運行的所有程序進行分離。這個“bubble”也可以稱之為進程，包含了管理該程序調用所需要的一切。

例如，這個所謂的進程環(huán)境包括該進程使用的內存頁，處理該進程打開的文件，用戶和組的訪問權限，以及它的整個命令行調用，包括給定的參數(shù)。

此信息保存在UNIX/Linux系統(tǒng)的流程文件系統(tǒng)中，該系統(tǒng)是一個虛擬文件系統(tǒng)，可通過/proc目錄進行訪問。條目都已經根據(jù)進程ID排過序了，該ID是每個進程的唯一標識符。示例1顯示了具有進程ID#177的任意選擇的進程。

示例1:可用于進程的信息

?

構建程序代碼以及數(shù)據(jù)

程序越復雜，就越有助于將其分成較小的模塊。不僅僅源代碼是這樣，在機器上執(zhí)行的代碼也同樣適用于這條規(guī)則。該規(guī)則的典型范例就是使用子進程并行執(zhí)行。這背后的想法就是：

單個進程包含了可以單獨運行的代碼段

某些代碼段可以同時運行，因此原則上允許并行

使用現(xiàn)代處理器和操作系統(tǒng)的特性，例如可以使用處理器的所有核心，這樣就可以減少程序的總執(zhí)行時間

減少程序/代碼的復雜性，并將工作外包專門的代理

使用子進程需要重新考慮程序的執(zhí)行方式，從線性到并行。它類似于將公司的工作視角從普通員工轉變?yōu)榻浝怼惚仨氷P注誰在做什么，某個步驟需要多長時間，以及中間結果之間的依賴關系。
這有利于將代碼分割成更小的部分，這些更小的部分可以由專門用于此任務的代理執(zhí)行。如果還沒有想清楚，試想一下數(shù)據(jù)集的構造原理，它也是同樣的道理，這樣就可以由單個代理進行有效的處理。但是這也引出了一些問題：

為什么要將代碼并行化?落實到具體案例中或者在努力的過程中，思考這個問題有意義嗎?

程序是否打算只運行一次，還是會定期運行在類似的數(shù)據(jù)集上?

能把算法分成幾個單獨的執(zhí)行步驟嗎?

數(shù)據(jù)是否允許并行化?如果不允許，那么數(shù)據(jù)組織將以何種方式進行調整?

計算的中間結果是否相互依賴?

需要對硬件進行調整嗎?

在硬件或算法中是否存在瓶頸，如何避免或者最小化這些因素的影響?

并行化的其他副作用有哪些?

可能的用例就是主進程，以及后臺運行的等待被激活的守護進程(主/從)。此外，這可能是啟動按需運行的工作進程的一個主要過程。在實踐中，主要的過程是一個饋線過程，它控制兩個或多個被饋送數(shù)據(jù)部分的代理，并在給定的部分進行計算。

請記住，由于操作系統(tǒng)所需要的子進程的開銷，并行操作既昂貴又耗時。與以線性方式運行兩個或多個任務相比，在并行的情況下，根據(jù)您的用例，可以在每個子過程中節(jié)省25%到30%的時間。例如，如果在系列中執(zhí)行了兩項消耗5秒的任務，那么總共需要10秒的時間，并且在并行化的情況下，在多核機器上平均需要8秒。這8秒中的3秒可能會在頭頂上消失，限制你的速度提高。

運行與Python并行的函數(shù)

Python提供了四種可能的處理方式。首先可以使用multiprocessing模塊并行執(zhí)行功能。第二，進程的替代方法是線程。從技術上講，這些都是輕量級的進程，不在本文的范圍之內。想了解更加詳細的內容，可以看看Python的線程模塊。第三，可以使用os模塊的system()方法或subprocess模塊提供的方法調用外部程序，然后收集結果。

multiprocessing模塊涵蓋了一系列方法來處理并行執(zhí)行例程。這包括進程，代理池，隊列以及管道。
清單1使用了五個代理程序池，同時處理三個值的塊。對于代理的數(shù)量和對chunksize的值都是任意選擇的，用于演示目的。根據(jù)處理器中核心的數(shù)量來調整這些值。

Pool.map()方法需要三個參數(shù) - 在數(shù)據(jù)集的每個元素上調用的函數(shù)，數(shù)據(jù)集本身和chunksize。在清單1中，我們使用square函數(shù)，并計算給定整數(shù)值的平方。此外，chunksize不是必須的。如果未明確設置，則默認chunksize為1。

請注意，代理商的執(zhí)行訂單不能保證，但結果集的順序是正確的。它根據(jù)原始數(shù)據(jù)集的元素的順序包含平方值。

清單1：并行運行函數(shù)

?