multithreading - parBuffer 评估没有给出预期的加速

Question

我有一个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

我在这里做错了什么？看起来它在锁(系统？)上花费了相当长的时间，而不是做有用的工作。

Answer 1

我认为，由于整体运行时间相对较小，因此在垃圾收集期间初始调整堆大小会造成很大影响。您可以尝试通过传递 +RTS -A100M 使初始分配区域更大。 .