Haskell提供了一个par
组合子,它与当前线程并行地为可能的评估排队“火花”。它还提供了一个pseq
组合器,它强制评估纯代码按特定顺序发生。
Haskell 不提供的是一种生成多个火花的方法,然后等待让它们全部完成。使用显式并发实现这一点非常简单,但纯粹的火花似乎是不可能的。
在某种程度上,这可能是因为火花的预期用例。它们似乎是为推测性评估而设计的。也就是说,做可能需要的工作,但可能不需要。因此,火花只能在核心上运行,否则它们就会闲置。
然而,这不是我的用例。我有一堆我知道的结果,事实上很快就会需要。如果我在火花爆发前开始尝试处理结果,我将再次以一堆失败的火花结束单线程。
当然,par
等待火花完成,它不会达到任何并行性!但如果有某种方法可以产生几个火花然后等待它们全部完成,那将非常有用。我找不到任何办法。
有人有任何有用的建议吗? (显然,除了“使用显式并发”之外)。
答案 0 :(得分:6)
您可以尝试将引发的计算结果放入严格的数据结构
{-# LANGUAGE BangPatterns #-}
module Main where
import Control.Parallel
fib :: Int -> Int
fib n
| n < 1 = 0
| n == 1 = 1
| otherwise = fib (n-1) + fib (n-2)
trib :: Int -> Int
trib n
| n < 1 = 0
| n < 3 = 1
| otherwise = trib (n-1) + trib (n-2) + trib (n-3)
data R = R { res1, res2 :: !Int }
main :: IO ()
main = do
let !r = let a = fib 38
b = trib 31
in a `par` b `pseq` (R a b)
print $ res1 r
print $ fib 28
print $ res2 r
在这里工作:
$ ./spark +RTS -N2 -s
39088169
317811
53798080
65,328 bytes allocated in the heap
9,688 bytes copied during GC
5,488 bytes maximum residency (1 sample(s))
30,680 bytes maximum slop
2 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 1 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s
Gen 1 1 colls, 1 par 0.00s 0.00s 0.0001s 0.0001s
Parallel GC work balance: 1.33 (686 / 515, ideal 2)
MUT time (elapsed) GC time (elapsed)
Task 0 (worker) : 0.59s ( 0.59s) 0.00s ( 0.00s)
Task 1 (worker) : 0.00s ( 0.59s) 0.00s ( 0.00s)
Task 2 (bound) : 0.59s ( 0.59s) 0.00s ( 0.00s)
Task 3 (worker) : 0.00s ( 0.59s) 0.00s ( 0.00s)
SPARKS: 1 (1 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.00s ( 0.00s elapsed)
MUT time 1.17s ( 0.59s elapsed)
GC time 0.00s ( 0.00s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 1.18s ( 0.59s elapsed)
Alloc rate 55,464 bytes per MUT second
Productivity 99.9% of total user, 199.1% of total elapsed
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0
答案 1 :(得分:6)
真的很短的答案
你不能。
简答
等待火花完成,尝试评估火花评估的内容。例如,如果您有表达式a
和b
,要计算a + b
,您可以
a `par` b `par` (a + b)
或
a `par` b `pseq` (a + b)
长答案
当你使用par
创建一个火花时,你告诉运行时系统“我稍后会需要这个值,所以你应该并行评估它。”当您稍后需要该值时,要么spark已经评估了表达式,要么它没有。如果有,则thunk将被一个值替换,因此重新评估没有成本 - 它只是获取值。如果它没有被评估为火花那么等待火花是没用的 - 可能需要一段时间来安排,而线程等待是浪费时间。而不是等待,你应该自己评估表达式。基本上,没有必要等待火花。您只需尝试评估原始表达式并获得性能优势。
此外,关于猜测的说明 - 虽然火花可以并经常被用于推测,但这并不完全是他们的设计目标。我看到par
用于简单并行化,如下面pfib
中所示,比我用于猜测的频率更高。
<强>实施例强>
标准示例是从串行
并行化Fibonacci数字fib 0 = 0
fib 1 = 1
fib n = fib (n - 1) + fib (n - 2)
到并行
pfib 0 = 0
pfib 1 = 1
pfib n = l `par` r `pseq` (l + r) where
l = pfib (n - 1)
r = pfib (n - 2)
现在举一个使用推测的例子:
spec :: a -- a guess to the input value
-> (a -> b) -- a function to tranform the input value
-> a -- the actual input value - this will require computation
-> b -- the function applied to the input value
spec guess f input = let speculation = f guess in speculation `par`
if guess == input
then speculation
else f input
我从中得到的hackage包speculation实际上有一些优化,比如不在单个核心上执行此操作并检查输入是否已经过评估,但这对于功能
使事情变得更明确的其他解决方案
par
。