December 2001 - Glasgow-haskell-users

(no subject)
by mailer.daemon＠server1.home4.com 14 Dec '01

14 Dec '01

1 0

ghc image size
by Vorin, Michael 14 Dec '01

14 Dec '01

I just recently starting to use the ghc compiler and am astonished by the size of the executables. Out of interest, why are they so large? Is there any work in progress to make the resulting executable/object somewhat more "normal" in size? I read in the Haskell mailing list archives discussions relating to reducing the barriers to broader acceptance of functional programming by the general programming community (in particular Haskell) - I would regard this as one of these barriers.

3 2

Re: ghc image size
by Mike Gunter 14 Dec '01

14 Dec '01

Why is executable size a barrier? 1.64 megabytes (that's the size of the executable I built with GHC most recently) of disk space costs less than half a cent. The total cost of the storage will be higher (backup, installing the drive, etc.) but I don't think it will be important. Are there other reasons that size matters? mike > I just recently starting to use the ghc compiler and am astonished by the > size of the executables. Out of interest, why are they so large? Is there > any work in progress to make the resulting executable/object somewhat more > "normal" in size? > > I read in the Haskell mailing list archives discussions relating to reducing > the barriers to broader acceptance of functional programming by the general > programming community (in particular Haskell) - I would regard this as one > of these barriers.

1 0

ANN: GHC 5.02.1 RPMs including xlib and HGL packages
by Manuel M. T. Chakravarty 12 Dec '01

12 Dec '01

The following might be of special interest to people who are using Paul Hudak's Haskell textbook for teaching and or study and would like to run the SOE graphics examples with GHC - or if you simply want to have an X-based graphics library for an application. GHC's source distribution contains the two library packages `xlib' and `HGL' (Alastair Reid's Haskell Graphics Library) as part of hslibs, which are not by default built and installed. For our local teaching needs at the University of New South Wales, we have produced a patched version of GHC 5.02.1 that includes the aforementioned libraries in a working form. Haskell modules can be compiled or linked against these libraries, by providing the command line options `-package xlib' and `-package HGL', respectively (or you can specify them using the :s command in the interpreter). RPM packages for x86 GNU/Linux based on glibc 2.2 (eg, RedHat 7.x) containing GHC 5.02.1 including the xlib and HGL packages are available as ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.02.1-graphics.1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.02.1-graphics.1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-doc-5.02.1-graphics.1.i386.rpm with the source RPM at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.02.1-graphics.1.src.rpm The source RPM contains a patched source tar ball and build instructions in the form of an RPM .spec that may be used to build the packages for other Linux distributions and on other Unix systems. (NB: GreenCard need not be installed to build this package, as a throw-away version of GreenCard is included in the tar ball - ie, it is used in the build process, but not installed.) Cheers, Manuel

1 0

RE: Questions about sharing
by Simon Marlow 10 Dec '01

10 Dec '01

> My understanding is that GHC tries to have it both ways. Here's my > understanding of how it works (implementors should probably chime in > if my memory is faulty or out of date): > > 1) There is a single, canonical copy of every nullary constructor. > This canonical copy is used wherever possible---just like a > top-level constant. > > 2) Updating a thunk with an indirection makes it expensive to obtain > the thunk's value. The extra indirection does not require > allocation---the only reason we need indirections at all is to > overwrite memory that previously held a thunk. The real problem is > that it takes time to chase down indirections once they exist. > > Therefore when a thunk evaluates to a nullary constructor, it is > overwritten directly. This effectively creates another copy of the > nullary constructor. > > 3) When the GC runs, instead of copying these newly-created nullary > constructors, it replaces them with the canonical copy. > > [The GC also eliminates indirections, and thus helps us no matter > what we do in 2) above] Actually we don't do (2) and (3) - update in place only happens in very limited conditions nowadays, namely when we know we're returning to an update frame and the constructor being returned is not nullary and also has no pointer fields (the latter restriction is to avoid complications due to generational GC). In The Olden Days (<= 3.02) we used a return-in-registers policy to avoid heap-allocating return values when they were about to be used once and thrown away, and this also enabled update-in-place in certain circumstances. However the whole thing was terribly complicated to implement, so now we have standard heap returns but we also do analysis (previously CPR analysis, now incorporated into the new demand analysis) to discover when a value can be returned on the stack instead of the heap. Cheers, Simon

1 0

RE: Combining Module Interfaces
by Simon Peyton-Jones 10 Dec '01

10 Dec '01

No, GHC just does not support this. GHC tries to avoid duplicating information (which might become inconsistent with catastrophic results), so C.hi simply records the dependency on A.hi and B.hi. You must have both of the latter available. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 07 December 2001 22:03 | To: GHC List | Subject: Combining Module Interfaces | | | Is there a way to combine interfaces into a single file? | | If I have modules A and B, I want to create a module C with all the | exported definitions of A and B such that I can compile | against C.hi file | without needing the A.hi and B.hi files. | | I tried this: | | module C (module A,module B) where | { | import A; | import B; | } | | ...but if I attempt to compile against C.hi using definitions | from A and | B, GHC complains if I don't have A.hi and B.hi. I want C.hi | to contain | everything that A.hi and B.hi do. | | -- | Ashley Yakeley, Seattle WA | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

like .ghci for ghc?
by Hal Daume III 08 Dec '01

08 Dec '01

I've read through most of the ghc docs, but haven't found anything like this. Almost all of my programs require -fglasgow-exts -package data -package text as well as -i(long paths here) but the latter three I cannot put in an OPTIONS line in the source code. In ghci I can have a ~/.ghci file, but the same doesn't appear to hold for ghc itself. Is there a way to do this? (If not, could one *please* be added?) Thanks - Hal p.s., yes, I know I could alias ghc or something, but this would be cleaner imo. -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

Re: Questions about sharing
by Jan-Willem Maessen 08 Dec '01

08 Dec '01

On Fri, 7 Dec 2001, Adrian Hey replied: > On Friday 07 December 2001 2:27 pm, D. Tweed wrote: > > > On Fri, 7 Dec 2001, Adrian Hey wrote: > > > The first is.. > > > Does the compiler keep a unique copy of expressions which consist of just > > > a single zero arity constructor (eg. [],True,Nothing..) as a CAF which is > > > referenced each time the constructor appears in an expression, or does it > > > duplicate the constructor (expression) each time it's used. > > Well I suppose if it's necessary to create a new indirection heap record > for each reference, then there's not really any point in having a single > copy of the value itself. But I don't see why that should be so. Even > if it is indirected for some reason it should still be possible to > share the indirection record I think. > > Maybe CAF is the wrong word to use here since there's no application > involved. What I mean is.. are zero arity constructors referenced the > same way as a top level constant would be? (Not that I know how > that's done, but I presume there's only 1 copy of top level > constants in memory at any one time.) My understanding is that GHC tries to have it both ways. Here's my understanding of how it works (implementors should probably chime in if my memory is faulty or out of date): 1) There is a single, canonical copy of every nullary constructor. This canonical copy is used wherever possible---just like a top-level constant. 2) Updating a thunk with an indirection makes it expensive to obtain the thunk's value. The extra indirection does not require allocation---the only reason we need indirections at all is to overwrite memory that previously held a thunk. The real problem is that it takes time to chase down indirections once they exist. Therefore when a thunk evaluates to a nullary constructor, it is overwritten directly. This effectively creates another copy of the nullary constructor. 3) When the GC runs, instead of copying these newly-created nullary constructors, it replaces them with the canonical copy. [The GC also eliminates indirections, and thus helps us no matter what we do in 2) above] Thus we get the best of both worlds---efficient thunk update and reasonable space consumption. -Jan-Willem Maessen

1 0

Questions about sharing
by Adrian Hey 08 Dec '01

08 Dec '01

Hello, I sometimes wonder just how far I should go in obfuscating code by manually implementing trivial optimisations that should (IMHO) be implemented by the compiler, but may not be. So I have a couple of specific questions.. The first is.. Does the compiler keep a unique copy of expressions which consist of just a single zero arity constructor (eg. [],True,Nothing..) as a CAF which is referenced each time the constructor appears in an expression, or does it duplicate the constructor (expression) each time it's used. Maybe I should define my own CAF at the top level and use it instead? (or perhaps they're unboxed somehow?) The second is.. If, following pattern matching, the matched pattern appears in an expression, is it shared or duplicated.. e.g. (a:as) -> f (a:as) Maybe I should write something like this.. x@(a:as) -> f x (I know that sometimes the type checker won't allow you to do this) Thanks -- Adrian Hey

2 2

RE: Questions about sharing
by Simon Marlow 08 Dec '01

08 Dec '01

> I sometimes wonder just how far I should go in obfuscating code by > manually implementing trivial optimisations that should (IMHO) be > implemented by the compiler, but may not be. > > So I have a couple of specific questions.. > > The first is.. > Does the compiler keep a unique copy of expressions which > consist of just > a single zero arity constructor (eg. [],True,Nothing..) as a > CAF which is > referenced each time the constructor appears in an > expression, or does it > duplicate the constructor (expression) each time it's used. > Maybe I should define my own CAF at the top level and use it instead? > (or perhaps they're unboxed somehow?) Nullary constructors are represented by a single static constructor, they are never built dynamically. So feel free to write [] wherever you like - it has the same cost as a variable. > The second is.. > If, following pattern matching, the matched pattern appears in an > expression, is it shared or duplicated.. > e.g. (a:as) -> f (a:as) > Maybe I should write something like this.. > x@(a:as) -> f x > (I know that sometimes the type checker won't allow you to do this) Yes, GHC will common these up (with -O). I'm not sure I understand the point about the type checker not letting you do this yourself, though: surely x and (a:as) have the same type? Cheers, Simon

3 2