Parse Monad與Eval Monad之間的差異與deepseq

Question

我一直在閱讀Simon Marlow在Haskell中的並行和並發Progaramming（很棒的書btw ..）並且他聲明Eval Monad只是並行評估惰性數據結構，而Par Monad是為避免依賴懶惰評估而創建的。 但是使用Eval Monad，您可以使用deepseq和force來獲得完全評估的數據結構，即非惰性數據結構。 那么除了與Eval Monad相關的不同編程模型之外，Par Monad的價值主張是什么？

Answer 1

格拉斯哥並行Haskell中的並行性可以使用par組合子來表示潛在的並行性（類似於懶惰期貨）和seq組合子來指定評估順序。 這被證明是一種非結構化的並行編程方法，因為它需要程序員理解語言的操作屬性（部分依賴於實現）並將組合器插入算法代碼中。 因此，引入了評估策略 （ Algorithm + Strategy = Parallelism ，Trinder等，1998），以分離計算和通信問題，並提供可組合的抽象（超過par和seq），而不會損害非嚴格語言的模塊性 。 Eval Monad被設計用於解決與垃圾收集器的不良交互，這可能導致丟失的並行性或空間泄漏（詳情： Seq no More：Better Strategies for Parallel Haskell ，Marlow et al。，2010）。

Eval Monad中的並行性是建議性的 ，即運行時系統（RTS）可以自由地丟棄所創建的spark （或thunk，指向未評估的閉包的指針），如果並行評估它是不利的。 這允許父任務包含任務，因此啟用動態和隱式粒度控制 （諸如分塊或閾值化的顯式應用級技術可以幫助RTS進一步減少並行度並增加粒度）。 因此， 並行性與處理器的數量無關 ，因為處理器越多，實際任務（輕量級線程）中的火花就越多。

Par Monad專為粗粒度並行而設計，受數據流模型的影響（詳見： 確定性並行的Monad ，Marlow等，2011）。 它被引入來處理直接使用par和seq一些明顯的缺點。 作者聲稱，懶惰往往會妨礙成本估算（在非嚴格的設置中更難）。 常見的缺陷包括：將已經評估的值傳遞給par，而不是確保程序的其余部分稍后需要並行評估的值，或者不嚴格地推斷嚴格性（參見具體示例的文章）。 Par Monad避免了懶惰問題，並在使用惰性數據結構對算法不重要的情況下幫助進行高效的並行編程。

Par Monad使用fork （或spawn ）來顯式地和強制地創建（子）任務（ 顯式粒度控制 ;給程序員提供更多控制，但可以被認為是更低級別並且取決於處理器的數量），同時明確地管理使用IVars進行任務間通信（表示依賴關系），而在Eval Monad中，通過減少的圖形隱含共享（程序員仍然需要表示程序的其余部分需要並行計算的值）。 在Eval Monad中，需要理解操作屬性並明智地應用強制函數，這很容易出錯（引入太多嚴格也可能是一個問題）。 通常，預定義的策略是足夠的，並且可以避免大多數問題。 另一種方法可以是在Par Monad之上定義算法骨架 。

總之，使用評估策略可以被認為是更高級和模塊化的，因為它將計算與協調分開（因此可以在不考慮協調的情況下理解算法），而Par Monad不要求程序員推理懶惰（盡管仍然可以在線程之間共享延遲計算，應該避免這種情況，因為monad調度程序無法檢測到在惰性計算上阻塞的線程，而是安排另一個線程）。 似乎Par Monad更適合粗粒度嚴格的數據流類計算，而如果需要延遲並且可以在順序算法中添加並行性，則可以使用策略。 Par Monad的另一個優點是調度程序是在Haskell級別編寫的，因此更容易修改（例如，Meta-Par使用： Meta-Scheduler用於異構雲的Par-Monad可組合調度 ，A。Foltzer et因為Eval Monad依賴於RTS內部實施的調度程序。 策略更好地支持推測並行性，因為當它被發現是未引用時可被垃圾收集器消除，而在Par Monad中，所有推測並行性都被執行（例如，與parBuffer策略相比，不能從runPar返回一個惰性列表，其中元素已被評估在平行下）。 最后，兩種模型也可以組合在一起。 兩種模型的關鍵優勢在於確定性，從而避免了競爭條件和死鎖。