2016-04-21 10 views
5

Stavo cercando di banco parMap vs mappa con un esempio molto semplice:Prestazioni di PARMAP di Haskell?

import Control.Parallel.Strategies 
import Criterion.Main 

sq x = x^2 

a = whnf sum $ map sq [1..1000000] 
b = whnf sum $ parMap rseq sq [1..1000000] 

main = defaultMain [ 
    bench "1" a, 
    bench "2" b 
    ] 

I miei risultati sembrano indicare lo zero speedup da parMap e mi chiedevo perché questo potrebbe essere?

benchmarking 1 
Warning: Couldn't open /dev/urandom 
Warning: using system clock for seed instead (quality will be lower) 
time     177.7 ms (165.5 ms .. 186.1 ms) 
        0.997 R² (0.992 R² .. 1.000 R²) 
mean     185.1 ms (179.9 ms .. 194.1 ms) 
std dev    8.265 ms (602.3 us .. 10.57 ms) 
variance introduced by outliers: 14% (moderately inflated) 

benchmarking 2 
time     182.7 ms (165.4 ms .. 199.5 ms) 
        0.993 R² (0.976 R² .. 1.000 R²) 
mean     189.4 ms (181.1 ms .. 195.3 ms) 
std dev    8.242 ms (5.896 ms .. 10.16 ms) 
variance introduced by outliers: 14% (moderately inflated) 
+0

Square è quasi un no op. Non guadagni nulla dal tentativo di farlo in parallelo. – Cubic

+0

@Cubic Avevo l'impressione che dovesse allocare parti dell'elenco a thread diversi in modo tale che ci sarebbero effettivamente meno operazioni per thread. – allidoiswin

risposta

7

Il problema è che parMap scintille un calcolo parallelo per ogni elemento di lista individuo. Non è affatto una lista di ciò che sembra pensare dai tuoi commenti, il che richiederebbe l'uso della strategia parListChunk.

Quindi il parMap ha spese generali elevate, quindi il fatto che ogni scintilla quadra semplicemente un numero significa che il suo costo è sopraffatto da quel sovraccarico.

+3

Squaring è così a buon mercato che indovinerei che la lista che si divide in 'parListChunk' travolga anche i guadagni paralleli. –

+3

Inoltre la paralellizzazione uccide la fusione, che altrimenti darebbe ordini di accelerazione di magnitudo. –

+0

@ AndrásKovács: Infatti. Quando [ho parallelizzato un mio programma] (https://github.com/sacundim/tau-sigma/pull/18) (usando 'parBuffer', comunque) ho osservato precisamente quel genere di cose. Il programma calcola una famiglia di funzioni statistiche sui dati di input e alcuni molto più costosi di altri. Quindi ha reso i più veloci un po 'più lenti al costo di rendere quelli lenti molto più veloci. Con il minimo sforzo –

Problemi correlati