如果我可以使用RPAR完成所有工作?'
我有操作x*x + 2*y
,我想同时评估+
的左右操作数。
我的问题是以下两个实现之间有什么区别:
import Control.Parallel.Strategies
foo x y = runEval $ do
left <- rpar a
right <- rpar b -- <==
return $ left+right
where a = x*x
b = 2*y
import Control.Parallel.Strategies
foo x y = runEval $ do
left <- rpar a
right <- rseq b -- <==
return $ left+right
where a = x*x
b = 2*y
? 我需要哪一个,为什么?
我可以对par
和pseq
~~&gt;我可以做到这一点:
import Control.Parallel
foo x y = a `par` b `par` a+b
where a=x*x; b=2*y
而不是这样:
import Control.Parallel
foo x y = a `par` b `pseq` a+b
where a=x*x; b=2*y
I have the operation x*x + 2*y
and I want to evaluate the left and right operands of the +
concurrently.
My question is what is the difference between the following two implementations:
import Control.Parallel.Strategies
foo x y = runEval $ do
left <- rpar a
right <- rpar b -- <==
return $ left+right
where a = x*x
b = 2*y
import Control.Parallel.Strategies
foo x y = runEval $ do
left <- rpar a
right <- rseq b -- <==
return $ left+right
where a = x*x
b = 2*y
?
Which one do I need, and why?
I could ask the same about par
and pseq
~~> I could do this:
import Control.Parallel
foo x y = a `par` b `par` a+b
where a=x*x; b=2*y
instead of this:
import Control.Parallel
foo x y = a `par` b `pseq` a+b
where a=x*x; b=2*y
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
a`par`B`B`Par` a+b
sparksa
,然后sparksb
,然后anforcea+b
在某些任意顺序上强制a
和b
。在理想的情况下,火花将已经强迫a
和b
,在这种情况下,a+b
的强迫被暂停等待计算要完成。但是,当thunk即将被强迫时,还有一个微妙的种族条件,另一个线程开始同时强迫它,然后他们俩都会冗余地运行相同的计算,并互相比赛以在Thunk上写下他们的结果,由于纯度,这应该是相同的,因此为什么在GHC的运行时可以容忍这种比赛条件。a`PAR`B`B`PSEQ`A+B
sparksa
,然后强制b
,最后强迫a+b
代码>。如果b
运行足够长的时间,则为a
的火花提供了机会,在a+b
被迫之前,避免了上述竞赛健康)状况。a `par` b `par` a+b
sparksa
, then sparksb
, then forcesa+b
which forcesa
andb
in some arbitrary order. In an ideal scenario, the sparks will already be forcinga
andb
, in which case the forcing ofa+b
is suspended waiting for the computations to finish. However there is a subtle race condition, when a thunk is just about to be forced, and another thread starts forcing it at the same time, then they will both run the same computation redundantly, and race each other to write their results over the thunk, which should be the same thanks to purity hence why this race condition is tolerated in GHC's runtime.a `par` b `pseq` a+b
sparksa
, then forcesb
, and finally forcesa+b
. Ifb
runs for long enough, that gives the opportunity for the spark ofa
to fire beforea+b
gets forced, avoiding the aforementioned race condition.