Commit 36fb02b0 authored by Simon Peyton Jones's avatar 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
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
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.
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.
* 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!
Please register or to comment