May 2003 - Glasgow-haskell-users

Re: Slow compile times
by Kirsten Chevalier 01 May '03

01 May '03

On Fri, May 02, 2003 at 02:56:45AM +0200, Peter Simons wrote: > Kirsten Chevalier writes: > > > I'm running GHC with the following options: > > -fallow-overlapping-instances -cpp -O1 -fvia-C -fglasgow-exts -package text > > -dcore-lint -prof -auto-all +RTS -K48M -M1024M -RTS -fno-strictness > > -Rghc-timing > > Did you try setting a bigger "suggested heap size" for GHC with > the run-time-system option "-H"? I found that setting something > like "-H128M" affected compile times positively on my machine. > > I hope this helps ... > I tried compiling the same file with -H512M -M512M instead of -M1024M, keeping all other options the same. I got the following results: <<ghc: 3763646968 bytes, 33 GCs, 17879484/44290920 avg/max bytes residency (6 samples), 528M in use, 0.00 INIT (0.83 elapsed), 54.89 MUT (116.82 elapsed), 9.58 GC (11.56 elapsed) :ghc>> With -O0, I get: <<ghc: 1482033536 bytes, 26 GCs, 9519452/29147696 avg/max bytes residency (5 samples), 515M in use, 0.00 INIT (0.28 elapsed), 15.27 MUT (69.29 elapsed), 2.63 GC (2.92 elapsed) :ghc>> This is better than before, but it still seems pretty slow; any other suggestions? Thanks, Kirsten -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

1 0

Slow compile times
by Kirsten Chevalier 01 May '03

01 May '03

Hi, I'm running GHC 5.04.3 on a Pentium IV machine with 1 GB of RAM, running RedHat Linux 7.2 and gcc version 2.96. I'm experiencing some very slow compile times; for the worst offender, a 1500-line module, -Rghc-timing reports the following stats: <<ghc: 3737832832 bytes, 14031 GCs, 31054695/68706248 avg/max bytes residency (18 samples), 178M in use, 0.00 INIT (0.01 elapsed), 53.88 MUT (103.47 elapsed), 30.18 GC (31.42 elapsed) :ghc>> I'm running GHC with the following options: -fallow-overlapping-instances -cpp -O1 -fvia-C -fglasgow-exts -package text -dcore-lint -prof -auto-all +RTS -K48M -M1024M -RTS -fno-strictness -Rghc-timing Since the section on improving compile times in the users' guide suggests adding more RAM if GC takes more than 20% of the time, I recently added 512 MB of RAM (bringing the total of 1 GB), but that doesn't seem to have helped much; the "top" command says that GHC takes up at most 20% of available memory, so it's not thrashing. All of my source code lives on a local disk, so NFS isn't an issue either. I tried running with -v2 as the manual suggests, but no single stage seems to stand out as being particularly slow. If anyone could help me track this down, I'd much appreciate it. BTW, when I tried compiling the same module with -O0 instead of -O1, I got the following stats: <<ghc: 1477256508 bytes, 5319 GCs, 17428260/41019496 avg/max bytes residency (16 samples), 104M in use, 0.00 INIT (0.01 elapsed), 15.64 MUT (68.13 elapsed), 13.44 GC (13.86 elapsed) :ghc>> which is somewhat better, but it still seems like GC is taking up more time than it should. Thanks, Kirsten -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

1 0

joinPS missing from Data.PackedString
by Hal Daume III 01 May '03

01 May '03

is this omission intentional? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

1 0

Sockets again
by George Russell 30 Apr '03

30 Apr '03

The attached short program (compile with "ghc VServer.hs -o v -package net") is supposed to set up a server on port 15151, wait for a connection, read the first character from the connection, and print it out. Unfortunately if I test it, by running it, and starting up "telnet [machine] 15151" somewhere else, and then type some random text, EG "foo[RETURN]", it does not work. It looks as if the problem is that VServer.hs issues the command hSetBuffering handle (BlockBuffering (Just 4096)) on the connection, because when I change it to hSetBuffering handle NoBuffering the program works. However this is not what I want to do!! Because setting NoBuffering on the handle is going to mean that when the Server *outputs* something, it will potentially be done very expensively character by character. How do I get block buffering on the Server's output, but not have input to the server held up? The same thing seems to happen with client Handles by the way. -- Test program for server using GHC Socket library. module Main(main) where import IO import Network main = do socket <- listenOn (PortNumber 15151) (handle,hostName,_) <- accept socket hSetBuffering handle (BlockBuffering (Just 4096)) putStr ("Accepted: "++hostName++"\n") c <- hGetChar handle putStrLn (show c)

4 6