parBuffer评估未给出预期的加速

时间:2013-06-11 08:32:58

标签: multithreading haskell concurrency

我有一个haskell函数,我想用精确的中间结果进行评估:

f 0 x = 0
f n x = let tmp = f (n-1) x in
        tmp + (x-tmp^2)/2

由于(^ 2),复杂性在n中呈指数增长。由于我想做一个情节并且两个不同x的计算是完全独立的,我本来期望从并行评估中获得近乎最佳的加速。我的代码:

import Data.Ratio
import Control.Parallel.Strategies

f 0 x = 0
f n x = let tmp = f (n-1) x in
        tmp + (x-tmp^2)/2

main = do
        it <- readLn
        let fn = fromRational . f it 
            values = map fn [0,1%2..10] :: [Double]
            computed = values `using` parBuffer 16 rseq
        mapM_ (putStrLn . show) computed

但令我惊讶的是,这并没有真正扩展(在我的HT双核i3上):

$ ghc -threaded -O f.hs
[1 of 1] Compiling Main             ( f.hs, f.o )
Linking f ...
$ time echo 20 | (./f +RTS -N1 > /dev/null)

real    0m4.760s
user    0m4.736s
sys     0m0.016s
$ time echo 20 | (./f +RTS -N2 > /dev/null)

real    0m4.041s
user    0m5.416s
sys     0m2.548s
$ time echo 20 | (./f +RTS -N3 > /dev/null)

real    0m4.884s
user    0m10.936s
sys     0m3.464s
$ time echo 20 | (./f +RTS -N4 > /dev/null)

real    0m5.536s
user    0m17.028s
sys     0m3.888s

我在这里做错了什么?它似乎花了很长时间在锁(sys?)而不是做有用的工作。

1 个答案:

答案 0 :(得分:6)

我认为由于整体运行时间相对较小,因此在垃圾收集期间从堆的初始大小调整中会遇到很多麻烦。您可以尝试通过传递+RTS -A100M来扩大初始分配区域。