Record "fib" for parallel operation: -N2 slower?

Question

I am studying Haskell and trying to write code to execute in parallel, but Haskell always runs it sequentially. And when I execute with the time flag -N2 , it takes longer to execute than if I lowered this flag.

Here is the code:

 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)) 

What did I do wrong? I tried this sample on Windows 7 on the Intel i5 kernel and on Linux on Atom.

Here is the log from my console session:

 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

I think the answer is that "GHC will optimize the fib function so that it does not allocate, and calculations that do not allocate cause problems for RTS, because the scheduler never starts and does not perform load balancing (which is necessary for parallelism ) ", as Simon wrote in this discussion group . Also I found a good tutorial .