- 想提高計(jì)算速度？作為數(shù)據(jù)科學(xué)家你應(yīng)該知道這些Python多線程、進(jìn)程知識(shí)
- skura 雷鋒網(wǎng) 2019-09-18
每個(gè)數(shù)據(jù)科學(xué)項(xiàng)目遲早都會(huì)面臨一個(gè)不可避免的挑戰(zhàn)：速度問題。使用更大的數(shù)據(jù)集會(huì)導(dǎo)致處理速度變慢，因此最終必須想辦法優(yōu)化算法的運(yùn)行時(shí)間。正如你們大多數(shù)人已經(jīng)知道的，并行化是這種優(yōu)化的必要步驟。python 為并行化提供了兩個(gè)內(nèi)置庫：多處理和線程。在這篇文章中，我們將探討數(shù)據(jù)科學(xué)家如何在兩者之間進(jìn)行選擇，以及在這樣做時(shí)應(yīng)注意哪些因素。
并行計(jì)算與數(shù)據(jù)科學(xué)
眾所周知，數(shù)據(jù)科學(xué)是處理大量數(shù)據(jù)并從中提取有用見解的科學(xué)。通常情況下，我們對(duì)數(shù)據(jù)執(zhí)行的操作很容易并行化，這意味著不同的處理代理可以一次對(duì)數(shù)據(jù)執(zhí)行一個(gè)操作，最后進(jìn)行組合以獲得完整的結(jié)果。
為了更好地解釋并行性，讓我們拿一個(gè)真實(shí)世界的例子作為類比。假設(shè)你需要打掃你家的三個(gè)房間。你可以自己打掃，打掃完一個(gè)再打掃另一個(gè)，也可以讓你的兩個(gè)兄弟姐妹幫你打掃，每個(gè)人打掃一個(gè)房間。在后一種方法中，每個(gè)人完成整個(gè)任務(wù)的一部分，從而減少了完成任務(wù)所需的總時(shí)間。這就是實(shí)際中的并行性。
并行處理可以用 python 以兩種不同的方式實(shí)現(xiàn)：多處理和線程。
多處理與線程：理論
基本上，多處理和線程是實(shí)現(xiàn)并行計(jì)算的兩種方法，分別使用進(jìn)程和線程作為處理代理。為了理解它們的工作原理，我們必須搞清楚什么是進(jìn)程和線程。
進(jìn)程
進(jìn)程是正在執(zhí)行的計(jì)算機(jī)程序的實(shí)例。每個(gè)進(jìn)程都有自己的內(nèi)存空間，用來存儲(chǔ)正在運(yùn)行的指令，以及需要存儲(chǔ)和訪問才能執(zhí)行的任何數(shù)據(jù)。
線程
線程是進(jìn)程的組件，可以并行運(yùn)行。一個(gè)進(jìn)程中可以有多個(gè)線程，它們共享相同的內(nèi)存空間，即父進(jìn)程的內(nèi)存空間。這意味著要執(zhí)行的代碼以及程序中聲明的所有變量將由所有線程共享。
例如，讓我們回想一下正在你的計(jì)算機(jī)上運(yùn)行的程序。你可能正在瀏覽器中閱讀本文，瀏覽器可能打開了多個(gè)選項(xiàng)卡。你也可以同時(shí)通過 Spotify 桌面應(yīng)用程序收聽音樂。瀏覽器和 spotify 應(yīng)用程序是不同的進(jìn)程;每個(gè)進(jìn)程都可以使用多個(gè)進(jìn)程或線程來實(shí)現(xiàn)并行性。瀏覽器中的不同選項(xiàng)卡可能在不同的線程中運(yùn)行。Spotify 可以在一個(gè)線程中播放音樂，在另一個(gè)線程中從 Internet 下載音樂，并使用第三個(gè)線程顯示圖形用戶界面。這稱為多線程。對(duì)多個(gè)進(jìn)程進(jìn)行多處理也可以做到這一點(diǎn)。事實(shí)上，像 chrome 和 firefox 這樣的大多數(shù)現(xiàn)代瀏覽器使用多處理，而不是多線程來處理多個(gè)選項(xiàng)卡。
技術(shù)細(xì)節(jié)
一個(gè)進(jìn)程的所有線程都存在于同一個(gè)內(nèi)存空間中，而進(jìn)程有各自的內(nèi)存空間。
與進(jìn)程相比，線程更輕量級(jí)，開銷更低。生成進(jìn)程比生成線程慢一點(diǎn)。
在線程之間共享對(duì)象更容易，因?yàn)樗鼈児蚕硐嗤膬?nèi)存空間。為了實(shí)現(xiàn)同一個(gè)進(jìn)程間通信，我們必須使用某種 IPC (inter-process communication) 模型，它通常由 OS 提供。
并行計(jì)算的陷阱
將并行性引入程序并不總是一個(gè)正和博弈，也有一些陷阱需要注意。其中，最重要的是下面的這些問題。
- 競(jìng)爭(zhēng)條件：正如我們已經(jīng)討論過的，線程有一個(gè)共享內(nèi)存空間，因此它們可以訪問共享變量。當(dāng)多個(gè)線程試圖同時(shí)更改同一個(gè)變量時(shí)，會(huì)出現(xiàn)競(jìng)爭(zhēng)條件。線程調(diào)度程序可以在線程之間任意交換，因此我們無法知道線程嘗試更改數(shù)據(jù)的順序。這可能會(huì)導(dǎo)致兩個(gè)線程中的任何一個(gè)出現(xiàn)不正確的行為，特別是當(dāng)線程決定基于變量的值執(zhí)行某些操作時(shí)。為了防止這種情況發(fā)生，可以在修改變量的代碼段周圍放置互斥鎖，以便一次只能有一個(gè)線程寫入變量。
- 饑餓：當(dāng)一個(gè)線程在較長時(shí)間內(nèi)被拒絕訪問某個(gè)特定的資源時(shí)，就會(huì)發(fā)生饑餓，在這種情況下，整個(gè)程序的速度會(huì)減慢。這可能是由于線程調(diào)度算法設(shè)計(jì)不當(dāng)而產(chǎn)生的意外副作用。
- 死鎖：過度使用互斥鎖也有一個(gè)缺點(diǎn)——它會(huì)在程序中引入死鎖。死鎖是一個(gè)線程等待另一個(gè)線程釋放鎖時(shí)的狀態(tài)，但另一個(gè)線程需要一個(gè)資源來完成第一個(gè)線程保持的操作。這樣，兩個(gè)線程都會(huì)停止，程序也會(huì)停止。死鎖可以被認(rèn)為是饑餓的極端情況。為了避免這種情況，我們必須小心不要引入太多相互依賴的鎖。
- 活鎖：活鎖是指線程在循環(huán)中繼續(xù)運(yùn)行，但沒有任何進(jìn)展。這也是由于互斥鎖設(shè)計(jì)不當(dāng)和使用不當(dāng)造成的。
python 中的多處理和線程
全局解釋器鎖
說到 python，有一些奇怪的地方需要記住。我們知道線程共享相同的內(nèi)存空間，因此必須采取特殊的預(yù)防措施，以便兩個(gè)線程不會(huì)寫入相同的內(nèi)存位置。CPython 解釋器使用名為 GIL 的機(jī)制或全局解釋器鎖來處理這個(gè)問題。
python wiki 上面的資料：
- 在 CPython 中，全局解釋器鎖(GIL)是一個(gè)互斥鎖，它保護(hù)對(duì) python 對(duì)象的訪問過程，防止多個(gè)線程同時(shí)執(zhí)行 python 字節(jié)碼。這個(gè)鎖是必要的，這主要是因?yàn)?CPython 的內(nèi)存管理不是線程安全的。
了解 python GIL 的詳細(xì)信息，請(qǐng)查看 。
GIL 完成了任務(wù)，但付出了代價(jià)。它在解釋器級(jí)別上有效地序列化指令。其工作原理如下：任何線程要執(zhí)行任何函數(shù)，都必須獲取全局鎖。一次只有一個(gè)線程可以獲取該鎖，這意味著解釋器最終會(huì)以串行方式運(yùn)行指令。這種設(shè)計(jì)使得內(nèi)存管理線程安全，但結(jié)果是，它根本不能利用多個(gè) cpu 內(nèi)核。在單核 cpu 中，這不是什么大問題。但是如果你使用多核 cpu，這個(gè)全局鎖最終會(huì)成為一個(gè)瓶頸。
但是，如果你的程序在其他地方(例如在網(wǎng)絡(luò)、IO 或用戶交互中)有更嚴(yán)重的瓶頸，則此瓶頸將變得無關(guān)緊要。在這些情況下，線程是一種完全有效的并行化方法。但對(duì)于 CPU 受限的程序，線程最終會(huì)使程序變慢。讓我們通過一些示例用例來探討這個(gè)問題。
線程的使用案例
GUI 程序始終使用線程來使應(yīng)用程序響應(yīng)。例如，在文本編輯程序中，一個(gè)線程負(fù)責(zé)記錄用戶輸入，另一個(gè)線程負(fù)責(zé)顯示文本，第三個(gè)線程負(fù)責(zé)拼寫檢查，等等。在這里，程序必須等待用戶交互，這是最大的瓶頸。使用多處理不會(huì)使程序更快。
線程的另一個(gè)用例是 io 綁定或網(wǎng)絡(luò)綁定的程序，例如 web-scrapers。在這種情況下，多個(gè)線程可以同時(shí)處理多個(gè)網(wǎng)頁的刮擦。線程必須從 Internet 下載網(wǎng)頁，這將是最大的瓶頸，因此線程是一個(gè)完美的解決方案。Web 服務(wù)器是受網(wǎng)絡(luò)約束的，工作原理與此類似;有了它們，多處理就沒有線程的優(yōu)勢(shì)了。另一個(gè)相關(guān)的例子是 tensorflow，它使用線程池并行地轉(zhuǎn)換數(shù)據(jù)。
多處理的使用案例
如果程序是 CPU 密集型的，并且不需要進(jìn)行任何 IO 或用戶交互，那么多處理就比線程更加突出。例如，任何一個(gè)只處理數(shù)字的程序都可以使用多處理得到極大的加速;事實(shí)上，線程可能會(huì)減慢它的速度。一個(gè)有趣的實(shí)際例子是 Pytorch Dataloader，它使用多個(gè)子進(jìn)程將數(shù)據(jù)加載到 GPU 中。
python 中的并行化
python 為同名的并行化方法提供了兩個(gè)庫——多處理和線程。盡管它們之間有著根本的區(qū)別，但這兩個(gè)庫提供了非常相似的 API(從 python 3.7 開始)。讓我們來具體看看吧。
你可以看到，我創(chuàng)建了一個(gè)函數(shù) func，它創(chuàng)建一個(gè)隨機(jī)數(shù)列表，然后按順序?qū)⑵渌性叵喑?。如果物品?shù)量足夠大，比如說 5 萬或 10 萬件，這可能是一個(gè)相當(dāng)繁重的過程。
然后，我創(chuàng)建了兩個(gè)線程來執(zhí)行同一個(gè)函數(shù)。線程對(duì)象有一個(gè)異步啟動(dòng)線程的 start 方法。如果我們想等待它們終止并返回，我們必須調(diào)用 join 方法，這就是我們?cè)谏厦嫠龅摹?/p>
如你所見，在后臺(tái)將新線程轉(zhuǎn)到任務(wù)的 API 非常簡(jiǎn)單。最棒的是，用于多處理的 API 也幾乎完全相同;讓我們來檢查一下吧~
在這里它只是交換線程。有著多處理的線程。
顯然，你可以用它做很多事情，但這不在本文的范圍內(nèi)，所以我們不在這里討論。如果你有興趣了解更多信息，請(qǐng)查看這里和這里的文檔：https://docs.python.org/3/library/threading.html 和 https://docs.python.org/3/library/threading.html 。
基準(zhǔn)點(diǎn)
現(xiàn)在我們已經(jīng)了解了實(shí)現(xiàn)并行化的代碼是什么樣子的，讓我們回到性能問題上來。如前所述，線程不適合用于 CPU 限制的任務(wù);在這些情況下，它最終成為一個(gè)瓶頸。我們可以使用一些簡(jiǎn)單的基準(zhǔn)來驗(yàn)證這一點(diǎn)。
首先，讓我們看看在我上面展示的代碼示例中，線程處理與多處理是如何比較的。請(qǐng)記住，此任務(wù)不涉及任何類型的 IO，因此它是純 CPU 綁定的任務(wù)。
讓我們看看一個(gè) IO 綁定任務(wù)的類似基準(zhǔn)。例如，以下函數(shù)：
這個(gè)函數(shù)只是獲取一個(gè)網(wǎng)頁并將其保存到一個(gè)本地文件中，循環(huán)多次。無用但直截了當(dāng)，因此很適合演示。讓我們看看基準(zhǔn)是什么吧。
現(xiàn)在，從這兩張圖表中可以注意到以下幾點(diǎn)：
- 在這兩種情況下，單個(gè)進(jìn)程的執(zhí)行時(shí)間都比單個(gè)線程長。顯然，進(jìn)程比線程有更多的開銷。
- 對(duì)于受 CPU 限制的任務(wù)，多個(gè)進(jìn)程的性能比多個(gè)線程要好。然而，當(dāng)我們使用 8x 并行化時(shí)，這種差異就變得不那么明顯了。由于我的筆記本電腦中的處理器是四核的，因此最多有四個(gè)進(jìn)程可以有效地使用多核。所以當(dāng)我使用更多的進(jìn)程時(shí)，它的伸縮性就不好。但是，它仍然比線程性能好很多，因?yàn)榫€程根本不能利用多個(gè)核。
- 對(duì)于 IO 綁定的任務(wù)，瓶頸不是 CPU。因此，GIL 帶來的通常限制在這里不適用，多處理也沒有優(yōu)勢(shì)。不僅如此，線程的輕量級(jí)開銷實(shí)際上使它們比多處理更快，并且線程始終優(yōu)于多處理。
差異、優(yōu)缺點(diǎn)
- 線程在相同的內(nèi)存空間中運(yùn)行;進(jìn)程有單獨(dú)的內(nèi)存。
- 從前面的觀點(diǎn)來看：在線程之間共享對(duì)象更容易，但與此同時(shí)，你必須采取額外的措施來實(shí)現(xiàn)對(duì)象同步，以確保兩個(gè)線程不會(huì)同時(shí)寫入同一個(gè)對(duì)象，并且不會(huì)出現(xiàn)爭(zhēng)用情況。
- 由于對(duì)象同步增加了編程開銷，多線程編程更容易出現(xiàn)錯(cuò)誤。另一方面，多進(jìn)程編程很容易實(shí)現(xiàn)。
- 與進(jìn)程相比，線程的開銷更低;生成進(jìn)程比線程花費(fèi)更多的時(shí)間。
- 由于 python 中 GIL 的局限性，線程不能利用多個(gè) CPU 核實(shí)現(xiàn)真正的并行。多處理沒有任何這樣的限制。
- 進(jìn)程調(diào)度由操作系統(tǒng)處理，而線程調(diào)度則由 python 解釋器完成。
- 子進(jìn)程是可中斷和可終止的，而子線程不是。你必須等待線程終止或加入。
從所有這些討論中，我們可以得出以下結(jié)論：
- 多處理應(yīng)該用于 CPU 受限、計(jì)算密集型的程序。
從數(shù)據(jù)科學(xué)家的角度
典型的數(shù)據(jù)處理管道可分為以下步驟：
- 讀取原始數(shù)據(jù)并存儲(chǔ)到主存儲(chǔ)器或 GPU 中;
- 使用 CPU 或 GPU 進(jìn)行計(jì)算;
- 將挖掘出的信息存儲(chǔ)在數(shù)據(jù)庫或磁盤中。
讓我們來探索如何在這些任務(wù)中引入并行性，從而加快它們的速度。
步驟 1 包括了從磁盤讀取數(shù)據(jù)，因此很明顯磁盤 IO 將成為此步驟的瓶頸。正如我們所討論的，線程是并行這種操作的最佳選擇。同樣，步驟 3 也是引入線程的理想候選步驟。
但是，步驟 2 包含涉及 CPU 或 GPU 的計(jì)算。如果是基于 CPU 的任務(wù)，那么使用線程將毫無用處;相反，我們必須進(jìn)行多處理。只有這樣，我們才能利用 CPU 的多個(gè)核并實(shí)現(xiàn)并行性。如果這是一個(gè)基于 GPU 的任務(wù)，因?yàn)?GPU 已經(jīng)在硬件級(jí)別實(shí)現(xiàn)了一個(gè)大規(guī)模并行化的體系結(jié)構(gòu)，那么使用正確的接口(庫和驅(qū)動(dòng)程序)與 GPU 交互應(yīng)該可以處理剩下的事情。
現(xiàn)在你可能會(huì)想，「我的數(shù)據(jù)管道看起來與此有些不同;我有一些任務(wù)并不真正適合這個(gè)通用框架?！共贿^，在這里你應(yīng)該考慮的因素是：
- 你的任務(wù)是否有任何形式的 IO
- IO 是否是程序的瓶頸
- 你的任務(wù)是否取決于 CPU 的大量計(jì)算
考慮到這些因素，再加上上面的要點(diǎn)，你應(yīng)該能夠做出決定。另外，請(qǐng)記住，你不必在整個(gè)程序中使用單一形式的并行，而是應(yīng)該在程序的不同部分使用不同的并行。
現(xiàn)在我們來看看數(shù)據(jù)科學(xué)家可能面臨的兩個(gè)常見場(chǎng)景，以及如何使用并行計(jì)算來加速它們。
場(chǎng)景 1：下載電子郵件
假設(shè)你想分析自己創(chuàng)業(yè)公司收件箱中的所有電子郵件，并了解其趨勢(shì)：誰是最頻繁的發(fā)件人，電子郵件中出現(xiàn)的最常見關(guān)鍵字是什么，一周中的哪一天或一天中的哪一小時(shí)收到的電子郵件最多，等等。當(dāng)然，這個(gè)項(xiàng)目的第一步是將電子郵件下載到你的計(jì)算機(jī)上。
首先，讓我們按順序進(jìn)行，而不使用任何并行化。下面是要使用的代碼，應(yīng)該非常簡(jiǎn)單明了。有一個(gè)下載電子郵件的功能，它以電子郵件 ID 列表作為輸入，并按順序下載它們。這個(gè)函數(shù)一次調(diào)用 100 個(gè)電子郵件的 ID 列表。
所用時(shí)間：35.65300488471985 秒。
現(xiàn)在讓我們?cè)谶@個(gè)任務(wù)中引入一些并行性來加快速度。在開始編寫代碼之前，我們必須在線程和多處理之間做出決定。正如你目前所了解到的，當(dāng)任務(wù)的瓶頸是 IO 時(shí)，線程是最好的選擇。這里的任務(wù)顯然屬于這一類，因?yàn)樗谕ㄟ^ Internet 訪問 IMAP 服務(wù)器。所以我們要開始使用線程了。
我們將要使用的大部分代碼將與我們?cè)陧樞虬咐惺褂玫拇a相同。唯一不同的是，我們將把 100 個(gè)電子郵件 ID 的列表分成 10 個(gè)較小的塊，每個(gè)塊包含 10 個(gè) ID，然后創(chuàng)建 10 個(gè)線程，并使用每個(gè)線程的不同塊調(diào)用 download_emails 函數(shù)。我正在使用 python 標(biāo)準(zhǔn)庫中的 concurrent.futures.threadpoolexecutor 類進(jìn)行線程處理。
所用時(shí)間：9.841094255447388 秒。
如你所見，線程大大加快了它的速度。
場(chǎng)景 2：使用 scikit learn 進(jìn)行分類
假設(shè)你有一個(gè)分類問題，你想使用一個(gè)隨機(jī)森林分類器。由于這是一種標(biāo)準(zhǔn)的、眾所周知的機(jī)器學(xué)習(xí)算法，我們不需要重新發(fā)明輪子，而只需使用 RandomForestClassifier 即可。
以下代碼用于演示。我使用助手函數(shù) sklearn.datasets.make_classification 創(chuàng)建了一個(gè)分類數(shù)據(jù)集，然后在此基礎(chǔ)上訓(xùn)練了一個(gè) RandomForestClassifier。另外，我正在計(jì)時(shí)代碼中完成模型擬合核心工作的部分。
任務(wù)花費(fèi)時(shí)間：34.17733192443848 秒。
現(xiàn)在我們將研究如何減少該算法的運(yùn)行時(shí)間。我們知道這個(gè)算法可以在一定程度上并行化，但是什么樣的并行化才是合適的呢?它沒有任何 IO 瓶頸，相反，它是一個(gè)非常 CPU 密集型的任務(wù)。所以多處理是合乎邏輯的選擇。
幸運(yùn)的是，sklearn 已經(jīng)在這個(gè)算法中實(shí)現(xiàn)了多處理，我們不必從頭開始編寫它。正如你在下面的代碼中看到的，我們只需要提供一個(gè)參數(shù) n_jobs(它應(yīng)該使用的進(jìn)程數(shù))來啟用多處理。
所用時(shí)間：14.576200723648071 秒。
正如預(yù)期的那樣，多處理使其速度更快。
結(jié)論
大多數(shù)(如果不是所有的)數(shù)據(jù)科學(xué)項(xiàng)目將會(huì)發(fā)現(xiàn)并行計(jì)算能大幅提高計(jì)算速度。事實(shí)上，許多流行的數(shù)據(jù)科學(xué)庫已經(jīng)內(nèi)置了并行性，你只需啟用它即可。因此，在嘗試自己實(shí)現(xiàn)它之前，請(qǐng)查看正在使用的庫的文檔，并檢查它是否支持并行性。如果沒有，本文將幫助你自己實(shí)現(xiàn)它。
本文轉(zhuǎn)自雷鋒網(wǎng)，如需轉(zhuǎn)載請(qǐng)至雷鋒網(wǎng)官網(wǎng)申請(qǐng)授權(quán)。
【責(zé)任編輯：未麗燕 TEL：（010）68476606】 分享到朋友圈 分享到微博- Python
- 數(shù)據(jù)科學(xué)
- 多線程
