Viết "fib" để chạy song song: -N2 chậm hơn?

Question

Tôi đang học Haskell và cố gắng viết mã để thực thi song song, nhưng Haskell luôn chạy theo tuần tự. Và khi tôi thực thi với cờ thời gian chạy là -N2 thì phải mất nhiều thời gian hơn để thực thi hơn nếu tôi bỏ qua cờ này.

Đây là mã:

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

Tôi đã làm gì sai? Tôi đã thử mẫu này trong Windows 7 trên lõi i5 của Intel và trong Linux trên Atom.

Dưới đây là đăng nhập từ Console Session của tôi:

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

Tôi nghĩ rằng câu trả lời là "GHC sẽ tối ưu hóa các chức năng fib nữa kẻo nó không phân bổ, và tính toán rằng làm không có vấn đề phân bổ nguyên nhân cho RTS vì trình lên lịch không bao giờ được chạy và thực hiện cân bằng tải (là cần thiết cho song song) "như đã viết Simon trong số discussion group này. Ngoài ra tôi tìm thấy tốt tutorial.