[GHC] #8457: -ffull-laziness does more harm than good

18 Oct 2013

      #8457: -ffull-laziness does more harm than good
------------------------------------+-------------------------------------
       Reporter:  errge             |             Owner:
           Type:  bug               |            Status:  new
       Priority:  high              |         Milestone:  7.8.1
      Component:  Compiler          |           Version:  7.7
       Keywords:                    |  Operating System:  Unknown/Multiple
   Architecture:  Unknown/Multiple  |   Type of failure:  None/Unknown
     Difficulty:  Unknown           |         Test Case:
     Blocked By:                    |          Blocking:
Related Tickets:                    |
------------------------------------+-------------------------------------
 In this bug report I'd like to argue that `-ffull-laziness` shouldn't
 be turned on automatically with either `-O` nor `-O2`, because it's
 dangerous and can cause serious memory leaks which are hard to debug
 or prevent.  I'll also try to show that its optimization benefits are
 negligible.  Actually, my benchmarks show that it's beneficial to turn
 it off even in the cases where we don't hit a space leak.

 We've met this issue last week, but it had been reported several times
 before: e.g. #917 and #5262.

 A typical example is the following:
 {{{
 #!haskell
 main :: IO ()
 main = task () >> task ()

 task :: () -> IO ()
 task () = printvalues [1..1000000 :: Int]

 printvalues :: [Int] -> IO ()
 printvalues (x:xs) = print x >> printvalues xs
 printvalues [] = return ()
 }}}

 We succeed with `-O0`, but fail with `-O`:
 {{{
 errge@curry:~/tmp $ ~/tmp/ghc/inplace/bin/ghc-stage2 -v0 -O0 -fforce-
 recomp lazy && ./lazy +RTS -t >/dev/null
 <>
 errge@curry:~/tmp $ ~/tmp/ghc/inplace/bin/ghc-stage2 -v0 -O -fforce-recomp
 lazy && ./lazy +RTS -t >/dev/null
 <>
 }}}

 28M?  What the leak!?  Well, it's `-ffull-laziness`:
 {{{
 errge@curry:~/tmp $ ~/tmp/ghc/inplace/bin/ghc-stage2 -v0 -O -fno-full-
 laziness  -fforce-recomp lazy && ./lazy +RTS -t >/dev/null
 <>
 }}}

 We get constant space and the fastest run-time too, since we spare
 some cycles on GC.

 Note, that in this instance we are trying to explicity disable sharing
 by using `()` as a fake argument for the function.  Also note, that
 this function may easily be a utility function in a larger code base
 or in a library, therefore it's impractical to say that you shouldn't
 use it twice "too close together".

 Quoting from the GHC user guide:
 {{{
  -O2:

     Means: “Apply every non-dangerous optimisation, even if it means
     significantly longer compile times.”

     The avoided “dangerous” optimisations are those that can make
     runtime or space worse if you're unlucky. They are normally turned
     on or off individually.

     At the moment, -O2 is unlikely to produce better code than -O.
 }}}

 This seems to be false at the moment.

 We decided to make a broader investigation into this issue and wanted
 to know if we can disable this optimization without too much pain.
 Came up with this benchmark plan:

   - let's benchmark GHC,

   - compile all stages with -O, but hack the stage1 compiler to
     emit `-t` statistics for every file compiled,

   - gather these statistics while compiling the libraries and the
     stage2 compiler.

 On the second run we compile the stage1 compiler with
 `-O -fno-full-laziness`, but leave everything else unchanged in the
 environment.

 When we have both results of the compilation of ~1600 files, we match
 them up and compute the (logarithmic) ratio of CPU and memory
 difference between compilations, the final results for our benchmark.

 The results and the raw data can be found at
 https://github.com/errge/notlazy.

 The overall compilation time dropped from 26:20 to 25:12, which is a
 4% improvement.  Investigating the full matching shows that this
 overall result is from small improvements all around the place.

 The results plotted:
   - https://github.com/errge/notlazy/blob/master/cpu.png
   - https://github.com/errge/notlazy/blob/master/mem.png

 The graphs show the logarithmic (100*log_10(new/orig)) ratio of change
 in cpu and memory consumption.  Therefore negative results mean that
 the new compilation method is faster.

 As can be seen on the CPU graph, in most of the cases the difference
 is negligible (actually smaller than what can be measured on small
 files, this is why we have the spike at 0).  In overall we see a small
 improvement in CPU, and there are some outliers in both directions,
 but there are more drastic improvement cases than drastic regressions.

 On the memory graph the situation is much more close to zero.  There
 is one big positive memory outlier: `DsListComp.lhs`.  It uses 69M
 originally and now uses 103M.  But compiles in 2 seconds both ways and
 there are files in the source tree which requires 400M to compile, so
 this is not an issue.

 After all this, I'd like to hear other opinions about just disabling
 this optimization in `-O` and `-O2` and leaving it as an option that
 can be turned on when needed, my reasons once more:
   - it's unsafe,
   - it's hard to debug when you hit its issues,
   - the optimization doesn't seem to be very productive,
   - it's always easy to force sharing, but it's not easy to force
     copying.

 Apparently a Haskell programmer should be lazy, but never fully lazy.

 Research done by Gergely Risko <errge> and Mihaly Barasz <klao>,
 confirmed on two different machines with no other running processes.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8457
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

tags

participants (1)