#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): Finally I got the code in a shape good enough for controlled experiments. I started with a merge of branch `better-ho-cardinality` and master (at [4025d66/ghc]). This is my baseline. The next measurement is with the nested CPR analysis, but without changing the worker-wrapper code, i.e. the CPR information is only used as far as before. Here is the result (skipping lines with `+0.0%`): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +0.0% +0.6% +0.3% +0.6% -3.4% -------------------------------------------------------------------------------- Min +0.0% -0.0% -8.9% -8.7% -3.4% Max +0.1% +0.6% +9.1% +9.1% +3.0% Geometric Mean +0.0% +0.0% -0.4% -0.4% -0.0% }}} I did not look at `cacheprof`, but I am confident that I did not break anything serious by introducing nested CPR to the analysis. Next measurement is is with the worker/wrapper code handling nested CPR, but using `-fnested-cpr-off` to make sure that all CPR information is actually what we had before. I used this to ensure that my `mkWWcpr`-implementation did not regress over the old one (it turned out that I did mess up in various ways, so this is important): {{{ -------------------------------------------------------------------------------- cacheprof +0.0% -0.6% -0.3% -0.6% +1.8% -------------------------------------------------------------------------------- Min +0.0% -0.6% -1.4% -1.7% +0.0% Max +0.0% +0.0% +2.3% +2.4% +1.8% Geometric Mean -0.0% -0.0% +0.1% +0.1% +0.0% }}} And now the exciting part: The same code, but now without `-fnested-cpr- off`: {{{ -------------------------------------------------------------------------------- anna +0.5% +0.1% 0.18 0.19 +0.0% boyer2 +0.5% +0.4% 0.01 0.01 +0.0% bspt +1.1% +0.2% 0.01 0.01 +0.0% cacheprof +0.5% -0.7% +0.6% +1.2% -2.6% calendar +0.5% +0.1% 0.00 0.00 +0.0% comp_lab_zift +0.5% +0.1% +0.0% +0.0% +0.0% infer +0.4% -1.2% 0.09 0.09 +0.0% para +0.4% +0.2% -1.5% -1.5% +0.0% prolog +0.5% +0.2% 0.00 0.00 +0.0% reptile +0.7% +0.3% 0.02 0.02 +0.0% -------------------------------------------------------------------------------- Min +0.4% -1.2% -8.0% -8.0% -4.4% Max +1.1% +0.4% +6.9% +6.9% +4.2% Geometric Mean +0.5% -0.0% +0.0% -0.0% -0.1% }}} so most of the 101 benchmarks are not affected by nested CPR (in its current, prelimary) form at all (besides a quite reliable increase of binary sizes by `+0.5%` – does Size include `.hi`-files?). When it changes the Allocs number the effect is small and indecisive. It may be that fixing #8598 would improve matters (or at least allow nested CPR to occur more often, whether for the better or for the worse, I don’t know.) I might look at that next, but probably off master, as it is an independent feature. Of course it is also quite likely that the nested CPR analysis needs more tuning by looking at code where we want it to fire. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1600#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler