python 並行處理在一個內核上運行所有任務 - 多處理，射線

Question

我有一個model.predict()方法和 65536 行數據，大約需要 7 秒才能執行。 我想通過這個例子使用joblib.parallel_backend工具來加速這個過程。

這是我的代碼：

import numpy as np
from joblib import load, parallel_backend
from time import clock as time

from urllib.request import urlopen

NN_model=load(urlopen("http://clima-dods.ictp.it/Users/tompkins/CRM/nnet_3var.jl"))

npt=65536
t=np.random.uniform(low=-1,high=1,size=npt)
u=np.random.uniform(low=-1,high=1,size=npt)
q=np.random.uniform(low=-1,high=1,size=npt)
X=np.column_stack((u,t,q))

t0=time()
out1=NN_model.predict(X)os.system('taskset -cp 0-%d %s' % (ncore, os.getpid()))

t1=time()
print("serial",t1-t0)
with parallel_backend('threading', n_jobs=-1):
    out2=NN_model.predict(X)
t2=time()
print("parallel",t2-t1)

這些是我的時間安排：

serial   6.481805
parallel 6.389198

我從過去的經驗中知道，由於開銷，並行共享 memory 技術不會加速非常小的任務， 這里也發布了答案，但這里不是這種情況，因為工作是 7 秒，應該遠遠超過任何高架。 事實上，我跟蹤了機器上的負載，它似乎只是在串行運行。

我對joblib規范做錯了什么？ 如何在我的桌面上使用線程來將此任務與joblib （或替代方法）並行化？

---

編輯 1

從下面的帖子中，我想知道 joblib 的應用程序是否嘗試將並行化應用於 model 本身，而不是將數據行划分為 ncore 批次以分發到每個核心。 因此，我決定也許我需要自己手動進行這個划分，並將數據“塊”分配給每個核心。 因此，我嘗試使用 now Parallel 和 delay 代替， 按照這篇文章對數據進行分塊，

from joblib import Parallel, delayed 

ncore    = 8
nchunk   = int( npt / ncore )
parallel = Parallel( n_jobs = ncore )
results  = parallel( delayed( NN_model.predict )
                            ( X[i*nchunk:(i+1)*nchunk,:] )
                     for i in range( ncore )
                     )

這現在在我的機器上運行ncore -instances，但它們都以1 / ncore效率運行（好像它是門控？）並且掛鍾仍然沒有改善......

---

編輯 2

作為替代方案，我現在還嘗試使用多處理 package 對數據集進行手動划分，

import  multiprocessing 
def predict_chunk(Xchunk):
    results=NN_model.predict(Xchunk)
    return (results)

pool=multiprocessing.Pool(processes=ncore)
os.system('taskset -cp 0-%d %s' % (ncore, os.getpid()))
stats=pool.starmap(predict_chunk,([X[i*nchunk:(i+1)*nchunk,:]] for i in range(ncore)))
res=np.vstack(stats).flatten()
pool.close()
pool.join()

除了划分輸入數據和重新堆疊結果的開銷之外，這個問題應該是令人尷尬的並行。 然后我回想起之前的帖子，想知道性能緩慢的問題是否是由於在導入 numpy 時出現的任務關聯問題，所以我添加了os.system命令，但這似乎沒有幫助，我仍然讓 8 個內核中的每一個都使用大約 12% 的 CPU 負載，並且由於上述開銷，現在的整體時序比串行解決方案略慢。

---

編輯 3

我現在嘗試使用ray代替

import ray

@ray.remote
def predict_chunk(Xchunk,start,end):
    results=NN_model.predict(Xchunk[start:end,:])
    return (results)

ray.init(num_cpus=ncore)
data_id=ray.put(X)
stats=ray.get([predict_chunk.remote(data_id,i*nchunk,(i+1)*nchunk) for i in range(ncore)])
res=np.vstack(stats).flatten()

同樣，這會創建 8 個子進程，但它們都在單個 CPU 上運行，因此並行進程比串行進程慢。

我幾乎可以肯定這與上面提到的親和力問題有關，但解決方案似乎不起作用。

這是架構的摘要：

Linux hp6g4-clima-5.xxxx.it 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Answer 1

問： “我在使用joblib規范時做錯了什么？”

最大的罪過_{（被 FORTRAN 的歷史所原諒， COMMON塊的巧妙使用擁有無與倫比的美感）}
是，
您假設基於進程的 Python 並行性保持共享內存的並行性，這不是基於非進程的 forms 的只是[CONCURRENT]處理流程，您假設它執行得更快（好像它是確實能夠從任何數量的基於線程的代碼執行的中央 GIL 鎖重新[SERIAL]化回到小時間配額驅動的壟斷、純[SERIAL]的幼稚序列（因此並發主要避免）處理，它是（由於python傳福音的原因）不是）

問： “我如何在我的桌面上使用線程來將這個任務與joblib （或替代方案）並行化？”

您的代碼沒有這種方法。

Python 線程是 python 中計算密集型和繁重的內存 I/O 綁定工作負載的不可行方法。

如果需要更多閱讀，請隨意閱讀這個，也許這個，並使用lstopo嘗試您的系統 NUMA-map 詳細信息，並與這個對抗。

---

討論：

正如時間所暗示的：

serial   6.481805
parallel 6.389198

“改進”不超過 1.5%，但在相同的“運行時”差異范圍內也存在其他 O/S 進程噪聲，只有少量內存 I/O 訪問可能會享受一些有意義的延遲屏蔽，當您在 neural-network 內操作矩陣重的許多-MUL/許多-ADD _{（變壓器）}時。

---

主要小姐：

_{早在 1972 年，一位METEO大師、數學家和氣象學家 Edward N. LORENZ在他在美國科學促進協會第 139 次會議，就在 1972 年 12 月 29 日這一天}

神經網絡適用於無模型（統計合理，因為只是懲罰最少）的猜測，非關鍵對象的分類（人類很快就會疲倦或無法看到/聽到破壞性的“隱藏”模式大量樣本可供“學習”——否則，我們人類在模式識別和即時“學習”方面非常出色。進化之母已經開發了我們的認知裝置，可以非常高效（能量）且顯着地做到這一點分層 - 在香蕉池中找到由橙子描繪的“一只貓”）

在所有（已知的）模型驅動領域中“使用”神經網絡，抱歉，這本身就是一個可怕的罪過。

當然，熱力學模型、狀態變化模式、濕度/溫度/壓力/離子相互作用特定的大氣模型很復雜，但已知且物理學不是懲罰驅動的猜測（neural-network 傳播許多-MULs/許多-ADDs _{（變壓器）}聲稱盲目地“擅長”）。

當然，我們可以花費無限的 HPC 預算、無限的研發能力，但在相同的時間、能量（是的，HPC-基礎設施玩具消耗大量能量用於計算（將其直接轉化為散熱）和冷卻（將另一大量能量轉化為冷卻 HPC 基礎設施在進行任何類型的數字運算游戲時散發的廢熱（無論他們是否明智）在前面的步驟中）。

最后但同樣重要的是，正如中學年級學生應該已經知道的那樣，MUL-s/ADD-s 增加了主要不確定性的傳播（不僅是由於浮點 IEEE 指定的值存儲的限制）。 在這樣的過程之后，“結果”的不確定性比輸入要差幾個數量級。 這是用於 HPC 計算的已知字母表，因此需要提醒您注意，但將 NN- many -MUL/ many -ADD _{（變壓器）}引入任何類型的預測系統，對於遠程預測系統（如氣候進化或天氣接近鑄造）是一種可怕的反模式（即使它可能從歐盟機構或硬件供應商（又名技術營銷）那里獲得豐厚的資金 - 抱歉，數字不是這樣工作的，負責任的科學家不應該關閉我們的眼睛從這些主要的差距，如果不是有偏見的認知操縱，更不要稱之為故意傳播的謊言）

給出盡可能簡單的例子，取任何基於模型的超簡單混沌吸引子，無論是 { Duffy | 洛倫茲}-一，


因為我們“知道”精確的 model（因此我們可以計算和模擬零不確定性的時空精確演化）及其參數，這給了我們一個獨特的機會來使用這些演示器向我們展示，（已知的、可重復的和可檢查的）解決方案會因任何和所有不精確和不確定性（在此討論）的自然傳播而受到破壞，因為我們可以在數值模擬的同時定量地“顯示”不確定性的增長范圍
像這樣的未知的經驗模型（近似和許多隱藏的自由度被過度簡化的模型越少），我們永遠不會感到舒適

它們在視覺上令人印象深刻，可能會因為它們看起來如此可接受而被俘虜（我們有零機會及時審查模型結果與現實的對比，我們不能重復整個現實來重新審查 model 等的增量，所以我們只是讓別人“相信” ）
現在，出於這些原因，讓我們轉向“已知”的 model 演示器，以及
添加任何微量的初始數據不確定性 - 在 position 中，在速度上，在時間步長上（作為各種持續存在和不可避免的觀察的抽象共存/讀數的系統+隨機誤差不精確，數據時間不一致-采集/同化等），你很快就會得到相同的模擬工作，但現在有了“新的”-dataPOINT，但這些很快開始承受越來越大，直到很快它們各自主要相關的不確定性的無限范圍（X , Y, Z 位置, dX/dt, dY/dt, dZ/dt 速度), 這使它們的意義較小。

有沒有被認真接受的科學領域，
那可以使
任何嚴重使用DataPOINT == 17.3476 ± ∞
那
許多-MULs/許多-ADDs _{（變壓器）}生產得如此之快？

嚴謹的科學和批判性思維應該有更多的空間，不是嗎？

量子點