Haskell中的多核编程 - Control.Parallel

Raf*_*ini 10 parallel-processing multithreading haskell multicore

我正在努力学习如何使用该Control.Parallel模块,但我认为我做得不对.

我正在尝试运行以下代码(fibs.hs).

import Control.Parallel

fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = p `par` (q `pseq`  (p + q))
    where
      p = fib (n-1)
      q = fib (n-2)


main = print $ fib 30
Run Code Online (Sandbox Code Playgroud)

我编译了这个:

ghc -O2 --make -threaded fibs.hs
Run Code Online (Sandbox Code Playgroud)

然后我得到以下执行该程序的结果(输出每个程序100次的Python脚本并返回执行时间的平均值和标准差):

./fibs +RTS -N1 -> avg= 0.060203 s, deviation = 0.004112 s  
./fibs +RTS -N2 -> avg= 0.052335 s, deviation = 0.006713 s  
./fibs +RTS -N3 -> avg= 0.052935 s, deviation = 0.006183 s  
./fibs +RTS -N4 -> avg= 0.053976 s, deviation = 0.007106 s  
./fibs +RTS -N5 -> avg= 0.055227 s, deviation = 0.008598 s  
./fibs +RTS -N6 -> avg= 0.055703 s, deviation = 0.006537 s  
./fibs +RTS -N7 -> avg= 0.058327 s, deviation = 0.007526 s  
Run Code Online (Sandbox Code Playgroud)

我的问题是:

  1. 我评估时到底发生了什么:

    a `par` (b `pseq` (a + b))   ?
    
    Run Code Online (Sandbox Code Playgroud)

    我知道parb应该暗示编译器有关与b并行计算a并返回b.好.但是做了pseq什么?

  2. 为什么我会看到如此小的性能提升?我在Intel Core 2 Quad机器上运行它.我希望用-N5或-N6运行不会对性能产生真正的影响,或者程序实际上会开始表现得非常糟糕.但为什么我看不到从-N2到-N3的改善,为什么最初的改进如此之小?

Mic*_*ele 15

正如唐解释的那样,问题在于你创造了太多的火花.这是你如何重写它以获得良好的加速.

import Control.Parallel

cutoff :: Int
cutoff = 20

parFib :: Int -> Int
parFib n | n < cutoff = fib n
parFib n = p `par` q `pseq` (p + q)
    where
      p = parFib $ n - 1
      q = parFib $ n - 2

fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n - 1) + fib (n - 2)

main :: IO ()
main = print $ parFib 40
Run Code Online (Sandbox Code Playgroud)

示范:

[computer ~]$ ghc --make -threaded -O2 Main.hs
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
[computer ~]$ time ./Main +RTS -N1
102334155

real    0m1.509s
user    0m1.450s
sys     0m0.003s
[computer ~]$ time ./Main +RTS -N2
102334155

real    0m0.776s
user    0m1.487s
sys     0m0.023s
[computer ~]$ time ./Main +RTS -N3
102334155

real    0m0.564s
user    0m1.487s
sys     0m0.030s
[computer ~]$ time ./Main +RTS -N4
102334155

real    0m0.510s
user    0m1.587s
sys     0m0.047s
[computer ~]$ 
Run Code Online (Sandbox Code Playgroud)


Don*_*art 12

你正在创建一个指数的火花(想想你在这里创建了多少个递归调用).要实际获得良好的并行性,在这种情况下需要创建较少的并行工作,因为您的硬件无法处理那么多线程(因此GHC不会创建它们).

解决方案是使用截止策略,如本演讲中所述:http://donsbot.wordpress.com/2009/09/05/defun-2009-multicore-programming-in-haskell-now/

基本上,一旦达到一定深度,切换到直线版本,并使用+ RTS -sstderr查看正在转换的火花数量,这样您就可以确定是否在浪费工作.

  • 它会自动平衡线程.运行时具有未评估表达式(sparks)的队列,当工作负载减少时,它将转换为线程.你还是不要创造太多的火花(因而浪费时间填满火花队列) (2认同)