細粒度多線程 - 工作任務應該執行多少？

我正在使用work_pile模式，以便線程始終運行並等待傳入的新函數指針+隊列中的數據的信號量。那是什麼蘋果營銷人員現在稱之爲大中央調度和推廣作爲新的切片面包的事情。細粒度多線程 - 工作任務應該執行多少？

我只是想知道如何將短任務分成兩個更短的任務是否有用。是否有我可以判斷是否值得排隊新對象的規則？

2009-08-26 Lothar

這是我在GCD上找到的鏈接：http://episteme.arstechnica.com/eve/forums?a=dl&f=174096756&x_id=mtid39095 – 2009-08-26 20:26:24

兩個可能的答案：

我更喜歡第二個。

無論如何，如果兩個任務總是依次運行（即按順序），那麼我認爲沒有增益來分割它們。

2009-08-26 12:39:25 mouviciel

基準測試並不容易，只有在實施後才能做到。我想有一個清單，當我應該開始尋找分裂。我甚至不知道線程激活的平均成本是多少，是否需要納秒，微秒？如果我排隊算法的多個步驟，那麼沒有隻有一個信號量計數器遞減和一個互斥體，比如100個週期+緩存未命中？ – Lothar 2009-08-26 13:49:26

我想補充一點，一個重要因素也是CPU /內核的數量以及如何爲它們分配任務。雖然理論上你可以從可用內核的數量中抽象出來，但我確信只有基準測試才能正確回答你的問題。 – mouviciel 2009-08-26 14:33:13

@mouvicel：基準測試的侷限性在於它只能給出具體問題的答案，並不一定能提供很多關於如何在稍微不同的情況下調整最佳性能的深入見解。這就是爲什麼我們希望有一些理論上的見解可以用於自動調整。 – 2009-08-27 14:10:35

多任務的限制是您擁有多少個核心以及多少算法是併發的。各種類型的開銷（包括鎖定）可以減少併發的數量，降低甚至扭轉多任務的好處。這就是爲什麼當有獨立的，長時間運行的任務時，它是最好的。話雖如此，只要開銷並不能帶來性能上的提升，就可以在覈心之間劃分一個短小的任務。

2009-08-26 12:45:53

工作模式背後的想法是，您可以從可用內核數量中抽象出來。 – Lothar 2009-08-26 13:34:49

對，對於CPU綁定的活動，您可能會設置n + 1個線程從輸入隊列中讀取，其中n是核心數。對於I/O綁定的，您可能需要更多。 – 2009-08-26 16:50:18

好吧，我對它做了更多的研究，聽起來操作系統正在爲池中的線程數量負責。我想這很方便，但我不確定它是如何決定調整的。當I/O阻塞時，n + 1啓發式失敗。 – 2009-08-26 20:27:46

簡而言之，您需要考慮資源+工作量+基準。

這裏有一些事情會打破方式：

因此，總之，我會說，你需要輸入你三思。如果你已經有了可以工作的代碼，那就好比銀行裏的錢。是否值得投入更多時間來提高代碼的生產力，或者投資回報率是否太低（或負值）？

2009-08-26 12:59:35

回答