Just another definition of calculateSeq: calculateSeq = zipWith ($) (cycle [sin,cos]) . map sqrt
2012/11/15 Janek S. <fremenz...@poczta.onet.pl> > > Do you really mean to calculate the 'sin . sqrt' of just the head of the > list, or do you mean: > > calculateSeq = map (sin . sqrt) ? > Argh.. of course not! That's what you get when you code in the middle of a > night. But in my code I > will not be able to use map because elements will be processed in pairs, > so let's say that my > sequential function looks like this: > > calculateSeq :: [Double] -> [Double] > calculateSeq [] = [] > calculateSeq [x] = [sin . sqrt $ x] > calculateSeq (x:y:xs) = (sin . sqrt $ x) : (cos . sqrt $ y) : calculateSeq > xs > > > I don't think there's a memory leak. It looks more like you're just > > allocating much more than is sane for such a simple function. > > On a recent processor, sin . sqrt is two instructions. Meanwhile, you > have > > a list of (boxed?) integers being split up, then recombined. That's bound > > to hurt the GC. > I am not entirely convinced that my idea of using eval+strategies is bound > to be slow, because > there are functions like parListChunk that do exactly this: split the list > into chunks, process > them in parallel and then concatenate the result. Functions in > Control.Parallel.Strategies were > designed to deal with list so I assume it is possible to process lists in > parallel without GC > problems. However I do not see a way to apply these functions in my > setting where elements of > lists are processed in pairs, not one at a time (parList and parMap will > not do). Also, working > on a list of tuples will not do. > > > Also, you might want to configure criterion to GC between > > runs. That might help. > The -g flag passed to criterion executable does that. > > > What I'd suggest doing instead, is breaking the input into chucks of, > say, > > 1024, and representing it with a [Vector]. Then, run your sin.sqrt's on > > each vector in parallel. Finally, use Data.Vector.concat to combine your > > result. > As stated in my post scriptum I am aware of that solution :) Here I'm > trying to figure what am I > doing wrong with Eval. > > Thanks! > Janek > > > > > Hope that helps, > > - Clark > > > > On Wed, Nov 14, 2012 at 4:43 PM, Janek S. <fremenz...@poczta.onet.pl> > wrote: > > > Dear Haskellers, > > > > > > I am reading Simon Marlow's tutorial on parallelism and I have problems > > > with correctly using Eval > > > monad and Strategies. I *thought* I understand them but after writing > > > some code it turns out that > > > obviously I don't because parallelized code is about 20 times slower. > > > Here's a short example > > > (code + criterion benchmarks): > > > > > > {-# LANGUAGE BangPatterns #-} > > > module Main where > > > > > > import Control.Parallel.Strategies > > > import Criterion.Main > > > > > > main :: IO () > > > main = defaultMain [ > > > bench "Seq" $ nf calculateSeq xs > > > , bench "Par" $ nf calculatePar xs ] > > > where xs = [1..16384] > > > > > > calculateSeq :: [Double] -> [Double] > > > calculateSeq [] = [] > > > calculateSeq (x:xs) = (sin . sqrt $ x) : xs > > > > > > calculatePar :: [Double] -> [Double] > > > calculatePar xss = runEval $ go xss > > > where > > > go :: Strategy [Double] > > > go [] = return [] > > > go xs = do > > > lsh <- (rpar `dot` rdeepseq) $ calculateSeq as > > > lst <- go bs > > > return (lsh ++ lst) > > > where > > > !(as, bs) = splitAt 8192 xs > > > > > > Compiling and running with: > > > > > > ghc -O2 -Wall -threaded -rtsopts -fforce-recomp -eventlog evalleak.hs > > > ./evalleak -oreport.html -g +RTS -N2 -ls -s > > > > > > I get: > > > > > > benchmarking Seq > > > mean: 100.5990 us, lb 100.1937 us, ub 101.1521 us, ci 0.950 > > > std dev: 2.395003 us, lb 1.860923 us, ub 3.169562 us, ci 0.950 > > > > > > benchmarking Par > > > mean: 2.233127 ms, lb 2.169669 ms, ub 2.296155 ms, ci 0.950 > > > std dev: 323.5201 us, lb 310.2844 us, ub 344.8252 us, ci 0.950 > > > > > > That's a hopeless result. Looking at the spark allocation everything > > > looks fine: > > > > > > SPARKS: 202 (202 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) > > > > > > But analyzing eventlog with ThreadScope I see that parallel function > > > spends most of the time doing > > > garbage collection, which suggests that I have a memory leak > somewhere. I > > > suspected that problem > > > might be caused by appending two lists together in the parallel > > > implementation, but replacing > > > this with difference lists doesn't help. Changing granularity (e.g. > > > splitAt 512) also brings no > > > improvement. Can anyone point me to what am I doing wrong? > > > > > > Janek > > > > > > PS. This is of course not a real world code - I know that I'd be better > > > of using unboxed data > > > structures for doing computations on Doubles. > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe