- ghc-tickets - Haskell.org

Re: [GHC] #7561: Unnecessary Heap Allocations - Slow Performance
by GHC 19 Jan '13

19 Jan '13

#7561: Unnecessary Heap Allocations - Slow Performance -------------------------------+-------------------------------------------- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by wurmli): Let me add a similar case, exemplifying better why I think that not the vector library, but the way the optimiser deals with reductions seems to be the culprit. (That's why I had put "unnecessary heap allocations in the title; #1498 might be a related ticket.) {{{ import System.Environment import Control.Applicative import Control.Monad import Control.Monad.ST import qualified Data.Vector.Storable.Mutable as VSM import qualified Data.Vector.Storable as G ------------------------------------------------------------------- -- Increment counter by 1 acc1 v = do{ k<-VSM.read v 0; VSM.write v 0 (k+1) } -- Increment counter 4 times by 1 until limit is reached -- i.e. each loop adds 4 whileModify1 :: G.MVector s Int -> ST s () whileModify1 v = do go <- do{ k<-VSM.read v 0; n<-VSM.read v 1; return (compare k n)} case go of LT -> do {acc1 v; acc1 v; acc1 v; acc1 v; whileModify1 v} EQ -> return () GT -> return () ------------------------------------------------------------------- -- Increment counter by 2 acc2 v = do{ k<-VSM.read v 0; VSM.write v 0 (k+1); k<-VSM.read v 0; VSM.write v 0 (k+1); } -- Increment counter twice by 2 until limit is reached -- i.e. each loop adds 4 whileModify2 :: G.MVector s Int -> ST s () whileModify2 v = do go <- do{ k<-VSM.read v 0; n<-VSM.read v 1; return (compare k n)} case go of LT -> do {acc2 v; acc2 v; whileModify2 v} EQ -> return () GT -> return () -------------------------------------------------------------------- -- Case 1 is fast with low use of heap space -- Case 2 is slow with high use of heap (about 400 times slower, 300 times more heap) testAcc :: Int -> Int -> G.Vector Int testAcc a n = runST $ do v <- (G.thaw $ G.fromList [0,n]) :: ST s (G.MVector s Int) case a of 1 -> whileModify1 v 2 -> whileModify2 v G.freeze v main = do let k = 50000000 n <- read.head <$> getArgs putStrLn $ show $ testAcc n k }}} The llvm backend improves timing about 4 fold {{{ ghc -threaded -rtsopts -O2 -fllvm heapAndSpeed.hs }}} Even though the two ways of increasing the counter are almost the same, the resulting code behaves vastly different, not only in speed, but also in heap usage (and garbage collector activity). {{{ ./heapAndSpeed 1 +RTS -s fromList [50000000,50000000] 74,088 bytes allocated in the heap 6,296 bytes copied during GC 47,184 bytes maximum residency (1 sample(s)) 18,352 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) ... INIT time 0.00s ( 0.00s elapsed) MUT time 0.02s ( 0.02s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.02s ( 0.02s elapsed) }}} {{{ ./heapAndSpeed 2 +RTS -s fromList [50000000,50000000] 25,000,074,088 bytes allocated in the heap 7,048,952 bytes copied during GC 47,184 bytes maximum residency (2 sample(s)) 22,448 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) ... INIT time 0.00s ( 0.00s elapsed) MUT time 8.06s ( 8.07s elapsed) GC time 0.17s ( 0.17s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 8.23s ( 8.24s elapsed) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7561#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4471: Incorrect Unicode output on Windows Console
by GHC 19 Jan '13

19 Jan '13

#4471: Incorrect Unicode output on Windows Console -------------------------+-------------------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Keywords: | Os: Windows Architecture: x86 | Failure: Incorrect result at runtime Difficulty: | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Changes (by ekmett): * cc: ekmett@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4471#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7561: Unnecessary Heap Allocations - Slow Performance
by GHC 18 Jan '13

18 Jan '13

#7561: Unnecessary Heap Allocations - Slow Performance -------------------------------+-------------------------------------------- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7561#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 18 Jan '13

18 Jan '13

#7542: GHC doesn't optimize (strict) composition with id ---------------------------------+------------------------------------------ Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7542#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7519: CLK_TCK is not always a constant
by GHC 18 Jan '13

18 Jan '13

#7519: CLK_TCK is not always a constant ---------------------------------+------------------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Keywords: qnx | Os: Other Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by kgardas): Looks like QNX and Solaris do exactly the same thing! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7519#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7519: CLK_TCK is not always a constant
by GHC 18 Jan '13

18 Jan '13

#7519: CLK_TCK is not always a constant ---------------------------------+------------------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Keywords: qnx | Os: Other Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by singpolyma): This also affects Solaris: http://www.haskell.org/pipermail/ghc- devs/2013-January/000095.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7519#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7605: HscStats.lhs is not used in the build process
by GHC 18 Jan '13

18 Jan '13

#7605: HscStats.lhs is not used in the build process -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The file [[GhcFile(main/compiler/HscStats.lhs)]] is not used in the build process, since there is [[GhcFile(main/compiler/HscStats.hs)]] that overrides it. I thought it would be safe to delete !HscStats.lhs but in fact it has been modified recently (about a month ago) and I can't figure out whether these changes should be merged into !HscStats.hs. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7605> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7594: GHCi becomes confused about IO type
by GHC 18 Jan '13

18 Jan '13

#7594: GHCi becomes confused about IO type -----------------------------+---------------------------------------------- Reporter: Khudyakov | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE Rank2Types #-} import GHC.Prim (Constraint) class (c1 t, c2 t) => (:&:) (c1 :: * -> Constraint) (c2 :: * -> Constraint) (t :: *) instance (c1 t, c2 t) => (:&:) c1 c2 t data ColD c where ColD :: (c a) => a -> ColD c app :: (forall a. (c a) => a -> b) -> ColD c -> b app f (ColD x) = f x q :: ColD (Show :&: Real) q = ColD (1.2 :: Double) }}} In the interactive mode it's possible to confuse GHCi about IO type. It tries to show expression instread of executing it. {{{ *Main> app print q <interactive>:3:1: No instance for (Show (IO ())) arising from a use of `print' Possible fix: add an instance declaration for (Show (IO ())) In a stmt of an interactive GHCi command: print it }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7534: allocateRegsAndSpill: Cannot read from uninitialized register
by GHC 18 Jan '13

18 Jan '13

#7534: allocateRegsAndSpill: Cannot read from uninitialized register --------------------------+------------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Linux Architecture: powerpc64 | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | --------------------------+------------------------------------------------- Changes (by simonmar): * owner: simonmar => Comment: This could be the same as #7574, I described the fix that was needed on that ticket and @thoughtpolice said he would look into it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7534#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4258: Finish new codegen
by GHC 18 Jan '13

18 Jan '13

#4258: Finish new codegen -------------------------------------------+-------------------------------- Reporter: igloo | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: 7192 Blocking: 1466, 1498, 3462, 4505, 5925 | Related: -------------------------------------------+-------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: The new codegen has been the default for a while now. Closing this to unblock the tickets that depend on it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4258#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0