#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