Dictionaries and full laziness transformation
Hi, I'm using GHC 7.0.1. I found that recursive overloaded functions tend to leak memory when compiled with full-laziness optimization on. Here is a simple case. -- TestSub.hs {-# LANGUAGE BangPatterns #-} module TestSub where {-# NOINLINE factorial #-} factorial :: (Num a) => a -> a -> a factorial !n !acc = if n == 0 then acc else factorial (n - 1) (acc * n) -- main.hs import TestSub factorial1 :: Int -> Int -> Int factorial1 = factorial main = do n <- readLn print $ factorial1 n 1 main This program should run in constant space, and compiled with -O0 or -O2 -fno-full-laziness, it does. However with -O2, it takes a linear amount of memory. The core for factorial looks like this: TestSub.factorial = \ (@ a_ajm) ($dNum_slz :: GHC.Num.Num a_ajm) -> let { a_slA :: GHC.Classes.Eq a_ajm [LclId] a_slA = GHC.Num.$p1Num @ a_ajm $dNum_slz } in let { lvl2_slC :: a_ajm -> a_ajm -> a_ajm [LclId] lvl2_slC = TestSub.factorial @ a_ajm $dNum_slz } in ... The problem is that lvl2_slC closure is created whenever factorial is applied to a Num dictionary, and kept alive until that application is GCed. In this program it never happens, because an application to the Num Int dictionary is referred to by the factorial1 CAF, and it recursively keeps the whole chain of closures alive. I know that full laziness transformation *sometimes* causes a space leak, but this looks like a bad result to me, because: - It looks like there is no point building a lot of equivalent closures, instead of one. - A lot of code can suffer from this behavior, because overloaded recursive functions are fairly common. For example, unfoldConvStream function from the latest iteratee package suffers from this problem, if I understand correctly. Does anyone have an idea on whether this can be fixed in GHC, or how to work around this problem? Regards, Takano Akio ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
a compiled program is slower than byte code
Hello, If I compile the attach code with GHC of the newest ghc-7.0 darcs branch, the compiled program is much slower than byte code. This phenomenon does not exist in GHC 6.12.3. 6.12.3 runghc -- 6.23s user 0.59s system 98% cpu 6.912 total ghc -- 5.72s user 0.70s system 99% cpu 6.422 total ghc -O -- 5.70s user 0.67s system 99% cpu 6.376 total ghc -O2 -- 5.69s user 0.67s system 99% cpu 6.373 total ghc-7.0 runghc -- 6.43s user 0.10s system 99% cpu 6.593 total ghc -- 9.20s user 0.09s system 99% cpu 9.302 total ghc -O -- 9.20s user 0.09s system 99% cpu 9.298 total ghc -O2 -- 9.38s user 0.09s system 99% cpu 9.478 total Is this a bug? My environment is Mac which runs Snow Leopard. --Kazu import System.IO n :: Int n = 1 main :: IO () main = withFile "/dev/null" WriteMode $ \h -> hPutStr h . foldr1 (++) . replicate n . replicate n $ 'a' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Question about Haskell AST
On Mon, Jan 10, 2011 at 9:21 AM, Jane Ren wrote: > Hi, > > I need to be able to take a piece of Haskell source code and get an > simplified, typed, intermediate representation of the AST, which means I need > to use compiler/coreSyn/CoreSyn.lhs > > So I'm first trying to get the desguaredModule of the source code with > ... > modSum <- getModSummary $ mkModuleName "..." > p <- parseModule modSum > t <- typecheckModule p > d <- desugarModule t > > Now I'm really stuck on figuring out how to connect the variable d of type > desugaredModule to compiler/coreSyn/CoreSyn.lhs to get Expr patterns like > App, Let, Case, etc. > > Also, is it correct to get the deguaredModule first? At least CoreSyn.lhs > seems to suggest this. > Sorry for the very late reply, but have you considered using External Core? http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/ext-core.html http://hackage.haskell.org/package/extcore IMO, it's less pain than linking with the GHC library unless your application really needs to get transformed Core back into the GHC back-end. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
System.Posix.Signals weirdness
Hi, I'd expect the following program (compiled with ghc and without any specieal flags) to produce Just (Exited ExitSuccess) True but it produces Just (Exited ExitSuccess) False on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current (ghc=7.0 from the 7.0 branch). module Main where import Data.IORef import System.Posix.Process import System.Posix.Signals import System.Posix.Unistd main = do caughtCHLD <- newIORef False installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) Nothing pid <- forkProcess $ sleep 2 >> return () s <- sleep 8 getProcessStatus False False pid >>= print readIORef caughtCHLD >>= print The sigCHLD handler is never called in this program. Is this expected behaviour? If so, why? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users