Hi there. [...]
So if I use this function:
valueStrictList :: [a] -> [a] valueStrictList [] = [] valueStrictList (x:xs) = x `seq` (x:valueStrictList xs)
before fromList, the maximum residency drops to 67MB, which is pretty good. (58MB is the pure cost of the resulting vector).
[...]
I did not look in Control.Parallel.Strategies, as I am not interested in parallelization at this point.
Thank you for letting me know that Control.Seq exists. I just looked at it and fail to see why it's needed. It seems to provide the "old" parallel strategies, but assuming the new ones are better, I don't see why they shouldn't equally apply to sequential programming as well.
So I tried
Seq.withStrategy (Seq.seqList Seq.rseq)
but this has the same effect as deepseq (140MB), which is probably what was intended, but not what I need.
The difference here is that valueStrictList returns the first element of the resulting list after evaluating it to WHNF, whereas the strategy evaluates the complete list before returning anything.
So I did look at Control.Parallel.Strategies and found evalList, which sounds like what I want, but
Strat.withStrategy (Strat.evalList Strat.rseq)
caused a Stack space overflow, and even using the same function as before, but now from Strategies, i.e.
Strat.withStrategy (Strat.seqList Strat.rseq)
causes a stack overflow.
The strategies "evalList" and "seqList" are the same. They both behave in the same way as the sequential strategy, as can be observed by manually increasing stack size sufficiently. I don't fully understand why they cause a stack overflow. I suspect it has to do with the differences between old and new strategies.
My questions are: 1. Why is there no evalList in Control.Seq? Should it be there?
I think Control.Seq should be removed, or basically just implement the sequential part of the strategies in Control.Parallel.Strategies. Control.Parallel.Strategies should import and reexport Control.Seq and extend it with parallel strategies.
2. Why does seqList behave differently in Control.Parallel.Strategies and in Control.Seq? Is that a bug?
I'm not sure. The "correct" way to reproduce your original strategy is to use "evalBuffer": Strat.withStrategy (Strat.evalBuffer 1 Strat.rseq)
The example code is attached, and the various options are easily tried out by commenting out the apropriate line. I’m using ghc-7.0.4 and parallel-3.1.0.1, and compiled the code with "-O2".
I've used ghc-7.2.1 with parallel-3.1.0.1 and only "-O" with essentially the same results. Cheers, Andres