- Glasgow-haskell-users

Alignment of doubles in ghc
by Matthew Donadio 04 May '03

04 May '03

Hi all, I was wondering if anyone has investigated the alignment of doubles in ghc. On x86 machines, doubles can be aligned on 4 byte boundaries, but there is a performace improvement if they have 8 byte alignment. As far as I can tell, ghc uses 4 byte alignment for doubles. I started to look into the changes needed to go from 4 to 8 byte alignment... >From what I saw, it looks like I need to add -malign-double to the gcc flags in ghc/compiler/main/DriverFlags.hs for the x86 architecture. The only other place I saw is in the autoconf stuff. The FPTOOLS_CHECK_ALIGNMENT macro is defined in aclocal.m4, and I can just set CFLAGS="-malign-double" in that macro (despite the name, that flag also effects other types...). Are there any other places that need attention? Has anyone else looked into this? Thanks. -- Matthew Donadio <m.p.donadio(a)ieee.org>

1 0

RE: Slow compile times
by Simon Marlow 02 May '03

02 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? The main thing to reduce GC time is to use -H<size>, as suggested. We do have some compilation speed "issues" with large source files, which I hope we'll get around to investigating at some point. You're using -prof, which precludes use of the native code generator. If you can do without -prof, then -fasm should improve compilation times a lot without affecting performance of the compiled program too much. Cheers, Simon

1 0

RE: joinPS missing from Data.PackedString
by Simon Marlow 02 May '03

02 May '03

> is this omission intentional? No, and I just added it recently (along with unlinesPS and unwordsPS defined in terms of it). Cheers, Simon

1 0

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

02 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 01 May '03

01 May '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

RE: Problem Building Package
by Simon Marlow 30 Apr '03

30 Apr '03

> I am having a bit of trouble builing local packages. > > I have three libraries, A, B, and C, that I want to make into local > packages. A and B depend only on base, while C depends on > base, A, and > B. > > The souces gets built with > > ghc --make -package-name=A {list of files} > ghc --make -package-name=B {list of files} > ghc --make -package-name=C {list of files} > > and I create the archives libHS[A,B,C].a This all works fine. > > I have three simple .pkg. If I add the dependencies into > package-deps, > then ghc-pkg says that the dependencies do not exist. If I leave that > blank, then I can create my local .conf file. I can't tell what the problem is from this description. Are the dependencies between your packages, or on other packages? It will help if you send us the .conf files, and cut-n-paste the exact command lines and the errors GHC produces. Cheers, Simon

1 0

RE: eta-expansion
by Simon Marlow 30 Apr '03

30 Apr '03

> | In the same paper is the case-eta-expansion, but I don't understand > | the correctness of this transformation: > | > | case e of {p1 -> e1,...,pn -> en} > | ===> \y -> case e of {p1 -> e1 y, ..., pn -> en y} > | > | The rhs is a WHNF, but the lhs isn't, so the rule > | can't be correct in general. For example, assume that e is bot. > > Right. It's only done if 'e' is cheap (a variable, or something like > that). Actually, looking at the code, we also do it if 'e' is known to be bottom: CoreUtils.exprIsCheap returns True for known-divergent expressions. Which seems wrong for eta expansion, no? It's probably the case that if we have 'case _|_ of ...' then the simplifier will already have turned it into _|_, so it won't crop up. But it still looks wrong, unless I'm missing something? Cheers, Simon

1 0

"less polymophic" problem
by Seth Kurtzberg 30 Apr '03

30 Apr '03

Hello list, I don't know how to solve this problem. Using GHC 5.04.3. The following snippet shows the problem, as minimally as I could. tl2 = ["123","abc","def"] tl3 = newSTRef tl2 -- this works: tl3unref = runST(tl3 >>= \ref -> readSTRef ref) -- this code, the same but with a formal parameter, doesn't compile: -- this is line 61 in the error message below getaline rlines = runST(rlines >>= \ref -> readSTRef ref) --ghci complains as follows: Inferred type is less polymorphic than expected Quantified type variable `s' escapes It is mentioned in the environment: rlines :: ST s (STRef s a) (bound at misstring.hs:61) In the first argument of `runST', namely `(rlines >>= (\ ref -> readSTRef ref))' In the definition of `getaline': runST (rlines >>= (\ ref -> readSTRef ref)) -- I tried the following signature for getaline: getaline :: forall s. ST s (STRef s [[Char]]) -> [[Char]] -- which does not change the error. The type in the signature for -- rlines is that displayed by ghci for tl3 Any help will be greatly appreciated. TIA -- Seth Kurtzberg MIS Corp 480-661-1849 seth(a)cql.com

2 1