多线程 – parBuffer评估未给出预期的加速

前端之家收集整理的这篇文章主要介绍了多线程 – parBuffer评估未给出预期的加速前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个 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

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

$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?)而不是做有用的工作.

解决方法

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

猜你在找的Java相关文章