[GHC] #11545: Strictness signature blowup
#11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code takes a lot of memory (556MB) to compile: {{{#!hs data A = A A A A A A deriving (Eq) }}} More {{{A}}}s result in more memory consumption during compilation. Using {{{ghc -O A.hs -v -dverbose-core2core -c -ddump-simpl +RTS -s}}} it seems like the strictness signatures of (==) and (/=) blow up quite a bit. A less silly example could be the following: {{{#!hs data QuadTree a = QuadTree !Int [a] (QuadTree a) (QuadTree a) (QuadTree a) (QuadTree a) foldQuadTree :: (a -> b -> b) -> Int -> b -> QuadTree a -> b foldQuadTree f maxSize = go where go z (QuadTree size elems t1 t2 t3 t4) | size <= maxSize = foldr f z elems | otherwise = go (go (go (go z t4) t3) t2) t1 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11545 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "A.log.gz" added. Output when compiling (22MB when uncompressed!) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11545 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): So every `QuadTree` is infinite? As is every value of type `A`. But yes, it'd be much better not to blow up. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11545#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This is because of demand analysis -- the usage part of the demand signature of {{{(/=)}}} isn't reaching to a fixpoint, so it's looping 10 times (because that's the hard-coded upper bound for fixpoint iterations), each time generating a bigger usage type. I'm a bit confused about why this is happening though. First, strictness type is reaching to a fixpoint very fast (maybe in the first iteration), but why? Second, {{{(/=)}}} is actually defined as {{{not (a == b)}}}, and {{{(==)}}} is demand type is top (i.e. (Lazy, Used)). This looks wrong to me, because the definition has case expressions on arguments and recursively calls itself. The strictness part should be more precise than that.. (more on this later...) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11545#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC