- Glasgow-haskell-users

problems using ghc-6.6.1 (due to fgl-5.4.1)
by Christian Maeder 09 May '07

09 May '07

I wrote: > Dear Hets- and GHC-Developers, > we have a problem using ghc-6.6.1. The created hets binary runs a > couple > of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where "hiding (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1

2 2

problems using ghc-6.6.1
by Christian Maeder 09 May '07

09 May '07

Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_sign CASL.Sublogic 5.3 3.7 compInclusion Logic.Grothendieck 3.2 3.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.5 1.6 isSubOpMap CASL.Sign 1.2 0.9 primCoerce Logic.Coerce 0.8 1.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_sign CASL.Sublogic 6.8 4.2 compInclusion Logic.Grothendieck 3.7 3.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.8 3.1 isSubOpMap CASL.Sign 1.6 1.1 sublogics_join CASL.Sublogic 1.5 1.1 primCoerce Logic.Coerce 1.3 1.4 isSameTranslation Proofs.Local 1.2 0.9

3 3

Why do we have stack overflows?
by Adrian Hey 08 May '07

08 May '07

Hello Folks, Just wondering about this. Please understand I'm not asking why programs use a lot of stack sometimes, but specifically why is using a lot of stack (vs. using a lot of heap) generally regarded as "bad". Or at least it seems that way given that ghc run time makes distinction between the two and sets separate limits for them (default max stack size being relatively small whereas default max heap size in unlimited). So programs can fail with a stack overflow despite having bucket loads of heap available? Frankly I don't care if my program fails because it's used a lot of stack or a lot of heap. I would rather set some common memory budget and have them fail if that budget was exceeded. This policy seems to have unfortunate consequences. Sometimes you end up re-writing stuff in a manner that just trades stack use for heap use (I.E. doesn't do anything to reduce overall memory consumption). Given the cost of reclaiming heap is rather high (compared to stack), this seems like bad idea (the version that used a lot of stack would be better IMO if only it didn't risk stack overflow). Example.. -- Strict version of take stackGobbler :: Int -> [x] -> [x] stackGobbler 0 _ = [] stackGobbler _ [] = [] stackGobbler n (x:xs) = let xs' = stackGobbler (n-1) xs in xs' `seq` (x:xs') -- Another strict version of take heapGobbler :: Int -> [x] -> [x] heapGobbler = heapGobbler' [] where heapGobbler' rxs 0 _ = reverse rxs heapGobbler' rxs _ [] = reverse rxs heapGobbler' rxs n (x:xs) = heapGobbler' (x:rxs) (n-1) xs But I guess everyone here is already aware of this, hence the question (current ghc memory system design seems a bit odd, but maybe there's a good reason why the rts can't work the way I would like). Thanks -- Adrian Hey

8 12

Cost of Overloading vs. HOFs
by Adrian Hey 07 May '07

07 May '07

Hello, The GHC users guide says overloading "is death to performance if left to linger in an inner loop" and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an explicit argument at the start seemed to give noticable a performance boost (compared with dictionary passing presumably). I'm not sure why that should be, but has anyone else noticed this? If so, maybe this advice should be added to the user guide, especially if your function repeatedly uses just one method from a class? (or maybe not if it's nonsense :-) I guess having done this there would be little to gain by using the SPECIALIZE pragma though (unless ghc also specialises HOFs). Regards -- Adrian Hey

11 16

recent Windows installer for ghc head?
by Conal Elliott 04 May '07

04 May '07

I'd like to try out the new & improved combination of type classes and GADTs, which I understand is only in head. Is there a recent working windows installer for head? Thanks, - Conal

4 5

ANNOUNCE: GHC version 6.6.1
by Ian Lynagh 04 May '07

04 May '07

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.6.1 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a significant number of bugfixes relative to 6.6, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.6.1/html/users_guide/release-6-6-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

9 17

Error compiling GHC/Num.lhs
by Bas van Dijk 03 May '07

03 May '07

Hello, I'm trying to build GHC from darcs. Unfortunately compilation fails with the following error: ... cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1) in GHC/Num.lhs at line 27 col 1 make[1]: *** [doc.library.base] Error 1 make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' make: *** [stage1] Error 2 ... The following is the part where the error occurs in libraries/base/GHC/Num.lhs : ... #include "MachDeps.h" #if SIZEOF_HSWORD == 4 #define LEFTMOST_BIT 2147483648 #define DIGITS 9 #define BASE 1000000000 #elif SIZEOF_HSWORD == 8 #define LEFTMOST_BIT 9223372036854775808 #define DIGITS 18 #define BASE 1000000000000000000 #else #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1) -- DIGITS should be the largest integer such that 10^DIGITS < LEFTMOST_BIT -- BASE should be 10^DIGITS. Note that ^ is not available yet. #endif ... Note that in build.mk I set BuildFlavour = quick and I also tried building it with the following options added: SRC_HC_OPTS += -optc-march=athlon64 -opta-march=athlon64 SRC_CC_OPTS += -march=athlon64 What can be the problem? Thanks, Bas van Dijk Some info on my system (please ask for more if you need it): $ uname -a Linux bassbox 2.6.20-gentoo-r6 #1 PREEMPT Thu Apr 19 10:53:57 CEST 2007 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux $ gcc --version gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)

5 10

Pretty printing type annotations
by C.M.Brown 03 May '07

03 May '07

Hi, I was wondering if there was an easy way to pretty print the result of the type checker from GHC. I basically want the format that GHCi spits out, rather than a type annotation with qualified types. I know I can knock up a parser that removes the qualifiers, but I was wondering if there was a simple function that I could call that would just printy print it for me (and saving me the work). The type checker gives me something of the form: (GHC.Num.Num t1, GHC.Num.Num t) => t1 -> t -> t1 But GHCi gives me the same without any qualifying. Hope someone can help. Chris.

1 0

GHC -O2 and unsafePerformIO
by Neil Mitchell 03 May '07

03 May '07

Hi I have a program (below) which when compiled with -O2 gives the result: H:\work\supero\charcount>type log.txt | diff.exe i am here 109 done The process tried to write to a nonexistent pipe. And when compiled with -O0 gives: H:\work\supero\charcount>type log.txt | diff i am here 109 i am here 111 done The process tried to write to a nonexistent pipe. It tries to read two characters, so I really do want two characters to appear. I have tried NOINLINE, but with no effect. Any suggestions? Thanks Neil --------------- -- The program import System.IO.Unsafe import System.IO import Data.Word import Debug.Trace main = p_System_IO_hGetChar 1 `seq` p_System_IO_hGetChar 2 `seq` putStrLn "done" {-# NOINLINE wrapIO #-} wrapIO x = unsafePerformIO (x >>= return) foreign import ccall "stdio.h getchar" getchar :: IO Word8 {-# NOINLINE p_System_IO_hGetChar #-} p_System_IO_hGetChar h = trace "i am here" $ wrapIO (getchar >>= \c -> print c >> return (if c == (-1) then 0 else chr_ c)) chr_ = fromEnum

4 6

GHC on ia64
by Cristian Perfumo 30 Apr '07

30 Apr '07

Hello, We've been trying to compile GHC 6.6 on ia64, and although we have applied the patch on http://hackage.haskell.org/trac/ghc/ticket/1150 , we still get some mangler errors with "nop 0"s. We have gcc 4.1, and Linux SUSE. Specifically: == make all -r; in .../ghc-6.6/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -H16m -O -optc-O2 -optc-DNOSMP -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o WARNING: Epilogue junk?: nop 0 nop 0 nop 0 Unmangled TAILCALL tokens remain after mangling at .../ghc-6.6/driver/mangler/ghc-asm line 1187, <INASM> line 1154. make[1]: *** [Apply.o] Error 255 make: *** [stage1] Error 1 Thank you very much in advance. Cheers, Cristian Perfumo

2 2