在維基百科的這篇文章中：https ://en.wikipedia.org/wiki/Go_(programming_language)#Suitability_for_parallel_programming據稱 Go 專家使用分布式工作同步模式來組織他的并行程序，而非專家使用叉連接：https : //upload.wikimedia.org/wikipedia/commons/thumb/f/ f1/Fork_join.svg/2000px-Fork_join.svg.png我在學校就熟悉 fork-join，但我想知道分布式工作同步模式是什么，它與我熟悉的經典 fork-join 模型有什么區別？當我執行 fork join 時，我通常會運行與運行內核一樣多的線程，但在論文中他們說 go 專家也這樣做了，并且他們簡要地提到了創建新線程的開銷是 go 專家優化的方式之一代碼，但似乎沒有詳細說明。
1 回答
弒天下
TA貢獻1818條經驗 獲得超8個贊
我會非常小心地將您從https://en.wikipedia.org/wiki/Go_(programming_language)#Suitability_for_parallel_programming引述為 Go 編程的一般真理。
我假設研究中描述的分布式工作同步是將問題劃分為子任務的方法，這主要取決于可以在硬件中實現的并行化，而不是由問題分解成更小的任務的自然方式決定.
根據您的具體問題和專業知識，這種方法可能會給您帶來一些性能優勢，但即使應用于令人尷尬的并行問題也可能并非易事。此外，這種方法更依賴于您使用的特定硬件（例如 2-32 與 64-1024 核、常規 CAS 與 LL/SC）、特定問題的大?。ɡ邕m合 L1 與幾乎適合 RAM )，最重要的是，關于您使用該方法和用于解決問題的工具的專業知識。
以上是標準的“過早優化是萬惡之源”/“簡單、充分和正確勝過復雜、超快和潛在錯誤”的建議，但論文中引用的實際實驗也給出了一些例子，為什么你應該這樣做使用您自己的判斷來使用哪種方法。
該研究使用了 Go 1.0.3。在調度、垃圾收集和 goroutine/channel 性能方面所做的重大改進可能已經有效地使結果過時了。
1.1. 具有諷刺意味的是，該論文提到了對于 Chapel 解決方案之一，當使用 Chapel 1.6（而不是 1.5）時，專家版的速度慢了約 68%。
該研究并未聲稱提供了具有統計意義的結果——對于 4 個平臺中的每一個，一個非專家解決了 6 個符合特定藍圖的綜合問題，然后根據一個專家的建議重寫了他的解決方案。
專家不應對在特定背景之外應用他的建議負責。如果您是 Golang 團隊 (Luuk van Dijk) 的高級軟件工程師，并且您的替代方案是在 Go 1.0.3 中使用簡單的分而治之，那么分布式工作同步是解決這些特定問題的更好方法。
當我執行 fork join 時，我通常會運行與運行內核一樣多的線程，但在論文中他們說 go 專家也這樣做了，并且他們簡要地提到了創建新線程的開銷是 go 專家優化的方式之一代碼，但似乎沒有詳細說明。
我假設創建新線程的開銷與接近遞歸樹底部時任務的擴散有關。
我認為屬于主定理案例 2 和 3 的算法將受到特別影響，但即使屬于案例 1 的算法（在樹的葉級別上完成的工作最重要，即生成的線程被稀釋最多）將受到影響。例如，在自上而下的歸并排序中為每對元素的比較創建一個新的邏輯任務可能是多余的。
恕我直言，運行的線程數與內核數一樣多，但在邏輯上自然地/在每個遞歸級別上劃分工作是我對分布式工作同步和簡單分而治之的理解之間的巨大妥協。
您仍在為在 K 個工作線程上調度 N 個任務的復雜性（可能，但不一定，在運行時間方面）付出一些代價。這個價格可能會讓你在運行時錯過并行化機會，例如因為緩存顛簸，因為次優調度，因為線程或核心親和性等。但是這可能會從你的程序中抽象出來在語言平臺級別，或在 Fork-Join 框架級別（如果您正在使用框架），或者在操作系統級別。在這種情況下，您的解決方案并不完全負責適應語言平臺、問題規?；驒C器硬件的變化，您應該能夠從底層的優化中受益，而無需觸及您的解決方案。
我敢打賭，只有當你能證明你的自然分而治之解決方案是不夠的并且你知道后果時，定制的分布式工作同步解決方案增加的復雜性和降低的可移植性是值得的。
- 1 回答
- 0 關注
- 145 瀏覽
添加回答
舉報
0/150
提交
取消