[commit: nofib] master: Update Simon-nofib-notes (36fb02b)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/nofib

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/36fb02b02cdbd8945312b4a6267c5cacd0d9a2a1/nofib

>---------------------------------------------------------------

commit 36fb02b02cdbd8945312b4a6267c5cacd0d9a2a1
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Fri May 4 10:41:31 2018 +0100

    Update Simon-nofib-notes


>---------------------------------------------------------------

36fb02b02cdbd8945312b4a6267c5cacd0d9a2a1
 Simon-nofib-notes | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/Simon-nofib-notes b/Simon-nofib-notes
index 33e9597..9527859 100644
--- a/Simon-nofib-notes
+++ b/Simon-nofib-notes
@@ -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