[GHC] #1600: Optimisation: CPR the results of IO

[GHC]

#1600: Optimisation: CPR the results of IO
-------------------------------------+-------------------------------------
        Reporter:  simonmar          |            Owner:  nomeata
            Type:  task              |           Status:  new
        Priority:  lowest            |        Milestone:  7.6.2
       Component:  Compiler          |          Version:  6.6.1
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  Runtime           |       Difficulty:  Moderate (less
  performance bug                    |  than a day)
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:  #8598
-------------------------------------+-------------------------------------

Comment (by nomeata):

 It helps, i.e. removes all increases of Allocs (I don’t trust `cacheprof`,
 the allocations there seem to vary even from run to run):

 {{{
 --------------------------------------------------------------------------------
         Program           Size    Allocs   Runtime   Elapsed  TotalMem
 --------------------------------------------------------------------------------
       cacheprof          +0.0%     +0.2%     +1.5%     +0.9%     -1.8%
          gamteb          +0.1%     -0.2%      0.06      0.06     +0.0%
           infer          +0.0%     -1.2%      0.09      0.09     +0.0%
             pic          +0.0%     -0.6%      0.01      0.01     +0.0%
 --------------------------------------------------------------------------------
             Min          -0.0%     -1.2%     -5.2%     -5.2%     -4.0%
             Max          +0.6%     +0.2%     +3.3%     +3.0%     +9.1%
  Geometric Mean          +0.0%     -0.0%     +0.1%     +0.1%     +0.0%
 }}}

 So on the one hand: Nice, no regression due to nested CPR, and some
 improvements (although very minor – is that even significant?)

 But the “fix” is not well-targeted, it rather is a heuristic.
 Unfortunately, I don’t see anything smarter to do here if we do not do
 whole-program compilation, or do not provide multiple implementations of
 the the function with varying degrees of CPRness.

 An alternative, not well-aimed fix would be to zap the CPR property for
 all top-level constants (and not just for thunks). This would make CPR
 much more robust against allocation increase, but that would prevent a lot
 of CPR where we really want it, i.e. where the constant is on the cold
 path and the unshared `Int#` cell is worth having an unboxed result type
 (i.e. in a naive `fac` function).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:31>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler