Commit 36fb02b0 by Simon Peyton Jones

### Update Simon-nofib-notes

parent 1364fe62
 ... ... @@ -13,6 +13,15 @@ whereas it didn't before. So allocations go up a bit. Imaginary suite --------------------------------------- queens ~~~~~~ The comprehension gen n = [ (q:b) | b <- gen (n-1), q <- [1..nq], safe q 1 b] has, for each iteration of 'b', a new list [1..nq]. This can floated and hence and shared, or fused. It's quite delicate which of the two happens. integrate ~~~~~~~~~ integrate1D is strict in its second argument 'u', but it also passes 'u' to ... ... @@ -229,9 +238,9 @@ it was inlined regardless by the instance-decl stuff. So perf drops slightly. integer ~~~~~~~ A good benchmark for beating on big-integer arithmetic. In this function: A good benchmark for beating on big-integer arithmetic There is a delicate interaction of fusion and full laziness in the comprehension integerbench :: (Integer -> Integer -> a) -> Integer -> Integer -> Integer -> Integer -> Integer -> Integer ... ... @@ -242,12 +251,15 @@ In this function: , b <- [ bstart,astart+bstep..blim ]]) return () if you do a bit of inlining and rule firing before floating, we'll fuse the comprehension with the [bstart, astart+bstep..blim], whereas if you float first you'll share the [bstart...] list. The latter does 11% less allocation, but more case analysis etc. and the analogous one for Int. Since the inner loop (for b) doesn't depend on a, we could float the b-list out; but it may fuse first. In GHC 8 (and most previous version) this fusion did happen at type Integer, but (accidentally) not for Int because an interving eval got in the way. So the b-enumeration was floated out, which led to less allocation of Int values. knights Knights ~~~~~~~ * In knights/KnightHeuristic, we don't find that possibleMoves is strict (with important knock-on effects) unless we apply rules before floating ... ...
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!