Memory use blowup with -O1 (versus -O0) in GHC 6.12.1/6.12.2

Simon Peyton-Jones simonpj at microsoft.com
Tue May 25 12:56:08 EDT 2010


Robert

Great example!  Your test case makes the type checker work hard to produce solve the type-equality constraints (and you have a lot of them); when pretty-printed it comes to 7000 lines!  But these large proofs are readily simplified to something tiny, just a few lines.

As luck would have it, I've already implemented a proof simplifier in the HEAD (it will appear in 6.14), and that makes short work of it.  Everything goes through in a snap.

Thanks for giving me such a convincing example of why a proof simplifier is Really Really worth it!

Simon


bash-3.2$

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-
| haskell-users-bounces at haskell.org] On Behalf Of Robert Greayer
| Sent: 10 May 2010 18:33
| To: glasgow-haskell-users at haskell.org
| Subject: Memory use blowup with -O1 (versus -O0) in GHC 6.12.1/6.12.2
| 
| Hi,
| 
| I've encountered an interesting issue with GHC 6.12.1 and 2 in which a
| small program compiles quickly without using loads of memory with
| optimization turned off, but with optimization (-O1) turned on, GHC's
| memory usage becomes very high (and compilation takes much much
| longer).
| 
| $ time ghc -c -O0 Tst.hs
| 
| real    0m0.107s
| user    0m0.073s
| sys     0m0.035s
| 
| $ time ghc -c -O1 Tst.hs
| 
| real    0m38.605s
| user    0m36.669s
| sys     0m1.923s
| 
| Memory used by GHC looks like it tops out at 3G (in the -O1 case).
| 
| Constraining the heap size to 1G causes compilation to fail:
| 
| $ ghc +RTS -M1g -RTS -c -O1 Tst.hs
| Heap exhausted;
| Current maximum heap size is 1073741824 bytes (1024 MB); use `+RTS -
| M<size>' to increase it.
| 
| (whereas, without optimization, a heap of 16m is sufficient)
| 
| The module being compiled is (probably deceptively) simple:
| 
| module Tst where
| import Merge
| data Rec1 = Rec1 !Int
| mkRec1 v = mk $ merge v () where mk (Tagged i :* ()) = Rec1 i
| 
| but the devil is in the details of 'merge' (attached) which merges
| heterogeneous lists of values, using a lot of type level programming
| with type families.  Does this sound like an known, open issue?  I was
| unable to find anything in GHC Trac that looked similar.
| 
| Thanks,
| Rob


More information about the Glasgow-haskell-users mailing list