Запись «fib» для параллельной работы: -N2 медленнее?

Question

Я изучаю Haskell и пытаюсь написать код для выполнения параллельно, но Haskell всегда запускает его последовательно. И когда я выполняю с флагом выполнения -N2, для выполнения требуется больше времени, чем если бы я опустил этот флаг.

Вот код:

import Control.Parallel 
import Control.Parallel.Strategies 

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

fib2 :: Int -> Int 
fib2 n = a `par` (b `pseq` (a+b)) 
    where a = fib n 
      b = fib n + 1 

fib3 :: Int -> Int 
fib3 n = runEval $ do 
       a <- rpar (fib n) 
       b <- rpar (fib n + 1) 
       rseq a 
       rseq b 
       return (a+b) 

main = do putStrLn (show (fib3 40)) 

Что я сделал не так? Я попробовал этот образец в Windows 7 на ядре Intel i5 и в Linux на Atom.

Здесь необходимо войти с моей консоли сессии:

ghc -rtsopts -threaded -O2 test.hs 
[1 of 1] Compiling Main    (test.hs, test.o) 

test +RTS -s 
331160283 
      64,496 bytes allocated in the heap 
      2,024 bytes copied during GC 
      42,888 bytes maximum residency (1 sample(s)) 
      22,648 bytes maximum slop 
       1 MB total memory in use (0 MB lost due to fragmentation) 

    Generation 0:  0 collections,  0 parallel, 0.00s, 0.00s elapsed 
    Generation 1:  1 collections,  0 parallel, 0.00s, 0.00s elapsed 

    Parallel GC work balance: nan (0/0, ideal 1) 

         MUT time (elapsed)  GC time (elapsed) 
    Task 0 (worker) : 0.00s ( 6.59s)  0.00s ( 0.00s) 
    Task 1 (worker) : 0.00s ( 0.00s)  0.00s ( 0.00s) 
    Task 2 (bound) : 6.33s ( 6.59s)  0.00s ( 0.00s) 

    SPARKS: 2 (0 converted, 0 pruned) 

    INIT time 0.00s ( 0.00s elapsed) 
    MUT time 6.33s ( 6.59s elapsed) 
    GC time 0.00s ( 0.00s elapsed) 
    EXIT time 0.00s ( 0.00s elapsed) 
    Total time 6.33s ( 6.59s elapsed) 

    %GC time  0.0% (0.0% elapsed) 

    Alloc rate 10,191 bytes per MUT second 

    Productivity 100.0% of total user, 96.0% of total elapsed 

gc_alloc_block_sync: 0 
whitehole_spin: 0 
gen[0].sync_large_objects: 0 
gen[1].sync_large_objects: 0 


test +RTS -N2 -s 
331160283 
      72,688 bytes allocated in the heap 
      5,644 bytes copied during GC 
      28,300 bytes maximum residency (1 sample(s)) 
      24,948 bytes maximum slop 
       2 MB total memory in use (0 MB lost due to fragmentation) 

    Generation 0:  1 collections,  0 parallel, 0.00s, 0.00s elapsed 
    Generation 1:  1 collections,  1 parallel, 0.00s, 0.01s elapsed 

    Parallel GC work balance: 1.51 (937/621, ideal 2) 

         MUT time (elapsed)  GC time (elapsed) 
    Task 0 (worker) : 0.00s ( 9.29s)  0.00s ( 0.00s) 
    Task 1 (worker) : 4.53s ( 9.29s)  0.00s ( 0.00s) 
    Task 2 (bound) : 5.84s ( 9.29s)  0.00s ( 0.01s) 
    Task 3 (worker) : 0.00s ( 9.29s)  0.00s ( 0.00s) 

    SPARKS: 2 (1 converted, 0 pruned) 

    INIT time 0.00s ( 0.00s elapsed) 
    MUT time 10.38s ( 9.29s elapsed) 
    GC time 0.00s ( 0.01s elapsed) 
    EXIT time 0.00s ( 0.00s elapsed) 
    Total time 10.38s ( 9.30s elapsed) 

    %GC time  0.0% (0.1% elapsed) 

    Alloc rate 7,006 bytes per MUT second 

    Productivity 100.0% of total user, 111.6% of total elapsed 

gc_alloc_block_sync: 0 
whitehole_spin: 0 
gen[0].sync_large_objects: 0 
gen[1].sync_large_objects: 0 

Answer 1

Я думаю, ответ в том, что "GHC оптимизирует функцию Фибо, так что он не делает распределения, а вычисления, которые не делают ни одного распределения вызывают проблемы для RTS, потому что планировщик никогда не запускается и не выполняет балансировку нагрузки (что соответствует , необходимого для параллелизма) «как написано Саймоном в этом discussion group. Также я нашел хороший tutorial.