#5234: The parListWHNF optimisation isn't
---------------------------------+------------------------------------------
Reporter: duncan | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries (other)
Version: 7.1 | Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
In Control.Parallel.Strategies there is:
{{{
parListWHNF :: Strategy [a]
parListWHNF xs = go xs `pseq` return xs
where -- go :: [a] -> [a]
go [] = []
go (y:ys) = y `par` go ys
}}}
Plus a rule:
{{{
{-# RULES
"parList/rseq" parList rseq = parListWHNF
#-}
}}}
However this rule never fires because both `parList` and `rseq` get
inlined too early (they have no `INLINE [n]` pragma).
This makes a difference because `parListWHNF` really is better than
`parList rseq`. Consider this trivial test program:
{{{
main =
let xs = [0..100000] `using` parListWHNF
in print (sum xs)
}}}
This correctly generates 100001 dud sparks. They are all dud because all
the elements of `[0..100000]` are already evaluated.
However if we use the same program with `parList rseq` then we get 100001
converted (but obviously rather trivial) sparks. This is less good (it
runs at half the speed) because it pushes all these sparks through the
spark pool, rather than not bothering to put them in the spark pool in the
first place.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5234>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
