May 2003 - Glasgow-haskell-users

-O and -prof
by ketil＠ii.uib.no 16 May '03

16 May '03

Hi, Is there any reason not to use these options in combination? Out of habit, I don't usually combine them, but it'd probably be more interesting to do time profiling with optimized code, since the compiler tend to optimize away some of the more pedestrian stuff on its own. When I recently tried this, I got a surprising stack overflow -- surprising, as I don't get that with either option by itself. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

3 4

RE: -O and -prof
by Simon Marlow 16 May '03

16 May '03

> John Meacham <john(a)repetae.net> writes: > > > I always use them in combination. simply because optimization can > > drastically change the memory useage/profile. profiling the > unoptimized > > version seems rather moot. > > Exactly. If this is indeed the intention, I guess the stack overflow > is a bug? Yes, strictly speaking. It may be a spurious case of the code generated with -O -prof being slightly different from that generated by -O alone - this happens because having cost centres floating around in the intermediate code disables some transformations that would normally be applicable. Nevertheless, if you can provide a test case we'll look into it. > > BTW. does O2 still do not much more than -O? it seems to reduce the > > memory footprint of some of my apps pretty noticbly. > > Not sure. The docs seem to indicate the speed improvement is > negligible. It's normally negligible. -O2 turns on one more optimisation pass, which *might* have a significant impact on your program if it hits the inner loop, but in most cases just costs you extra compilation time for not much benefit. > I thought I saw some hints in the GHC docs, including using > -fvia-C, but I couldn't find them, and I'm not sure if they would be > still current. > > Memory footprint is a problem, I wonder if GHC makes any > effort to pack strict data types? I.e. > > data D1 = A | B > data D2 = A2 | B2 | C2 > > data D3 = D !D1 !D2 -- could fit inside e.g. a Word8? We don't do any useful optimsation of the representation of D3 here, but we could (it's been on my ToDo list since I implemented -funbox-strict-fields some time ago). In a similar vein, the strictness analyser doesn't take advantage of strict enumerated types - it could map them to Int#, for example. Semitagging (an optimisation in the works along with optimistic evaluation) will provide some of the benefit that a more efficient representation would yield here. > Is there an elegant way to achieve this manually (if I know I'll need > large arrays of D3s, for instance -- can I map them to arrays of Word8 > or a similar type?) If you map D1 and D2 to Int by hand, then use data D3 = D !Int !Int you'll get the speed benefit, but not all the space (each field will still take up a 32-bit word). Cheers, Simon

1 0

RE: ghc-5.04.3-1.src.rpm -i
by Simon Marlow 15 May '03

15 May '03

> There's a hidden gotcha in the rpm spec file (the file which gives > instructions for building) - it only does a stage1 build, > whereas ghci > needs a stage2 build. This is OK as long as it's understood by rpm > builders that they need to build binary rpms using a previous install > of 5.04.3. We could probably trick up the spec file to be clever and > trigger a stage2 build if it's necessary. For version 6.0, let's have the spec file do a stage2 build by default. It's much easier these days, you only need one source tree and just saying "make" at the top-level will cause a stage2 build to happen. Cheers, Simon

3 2

RE: Alignment of doubles in ghc
by Simon Peyton-Jones 12 May '03

12 May '03

Try http://research.microsoft.com/~simonpj/papers/eval-apply/ This paper discusses the eval/apply stuff in some detail Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Jerzy Karczmarczuk | Sent: 12 May 2003 12:59 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: Alignment of doubles in ghc | | Simon Marlow wrote: | | > We've already made the switch to eval/apply for the next release of GHC. | > However, deferring the entirety of stack management to an underlying | > compiler is not that easy: we do accurate garbage collection, so we need | > to retain enough information about the compiler's idea of stack layout | > in order to be able to find all the pointers during GC. We therefore | > can't compile via C using an ordinary C compiler and leave the stack | > management up to the C compiler. | | Is there anything published/unofficially available about it? | | I have pure academic interest in all that. I must say that rarely had I | the occasion to learn something more crunchy about the implementation | of Haskell and FP than from the description of concrete solutions, such | as STG (and the implementation of Clean, and Appel's paper on the imple- | mentation of ML). | | Now, my white/bald hair tell me that the eval/apply model is something | quite oriented towards strict evaluation paradigms, and I would enjoy very | much a thorough discussion of the implementation of laziness. | | | Jerzy Karczmarczuk | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: file too large
by Simon Marlow 12 May '03

12 May '03

> Ferenc Wagner writes: > > > - Macro: _FILE_OFFSET_BITS > > Shouldn't Autoconf determine what needs to be done for > large-file support? If you call the AC_SYS_LARGEFILE macro > in the configure script, your build will be transparently > switched to large-file support by providing the necessary > compiler flags (like -D_FILE_OFFSET_BITS=64). > > The configure.in script coming with GHC 5.04.3 doesn't seem > to make use of this. Maybe adding the macro call is all that > is to fixing this problem? This has come as something of a shock to me: it seems I've been living in a dream world in which off_t was always 64 bits and large files were supported by default :-) The AC_SYS_LARGEFILE macro seems to be a relatively new addition to autoconf (i.e. not in 2.13), but I'll see what I can do about enabling large file support in GHC. Cheers, Simon

1 0

RE: file too large
by Simon Marlow 12 May '03

12 May '03

> There seems to be a 2Gb file limit when using GHC, I don't suppose > there's any way to get around it, apart from manually splitting the > contents over several smaller files? (I'm even unable to use > writeFile on a file that's larger than 2Gb) That's probably a bug, as long as the underlying OS uses 64-bit file offsets. How does the 2Gb limit manifest itself? Cheers, Simon

4 7

RE: Alignment of doubles in ghc
by Simon Marlow 12 May '03

12 May '03

> I've recently browsed some assembly code generated by GHC > (via gcc). It appeared that most values were accessed via > memory, because the stack is managed by GHC explicity. Even > intermediate results seem accessed via memory, probably due > to shortcomings of aliasing analysis in gcc. (?) > > This brings on the topic of eval/apply vs push/enter. In the > eval/apply model, the stack management can (possibly) be left to an > underlying compiler, which would remove most memory accesses, > and leave most of the alignment issue to the back-end. > (http://research.microsoft.com/Users/simonpj/papers/eval-apply/) > > From that article, I can only assume that GHC will switch to > the eval/apply model. Can we expect that soon? The > "alignment" thing would > become easier to deal with... We've already made the switch to eval/apply for the next release of GHC. However, deferring the entirety of stack management to an underlying compiler is not that easy: we do accurate garbage collection, so we need to retain enough information about the compiler's idea of stack layout in order to be able to find all the pointers during GC. We therefore can't compile via C using an ordinary C compiler and leave the stack management up to the C compiler. C-- has a solution to this problem, but there is neither a C-- compiler or a C-- back end for GHC (yet). Cheers, Simon

2 1

RE: Alignment of doubles in ghc
by Simon Marlow 12 May '03

12 May '03

> 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... It's quite a difficult task. You would need to arrange that the stack pointer and heap pointer are always 8-byte aligned, which is something we don't do at the moment: they're always 4-byte aligned only. This would mean changes to the code generator to add alignment padding to stack frames, and to pad the heap pointer to an 8-byte boundary after each allocation. We haven't looked into it, but you're welcome to try! We *have* seen examples where gcc spilled some intermediate double values to the stack, and it made a big difference whether the stack address used was 8-byte aligned or not. I seem to recall this was the mysterious cause of a 40% or so difference in speed between two runs of the same binary at different times of the day :-) Cheers, Simon

2 1

glasgow-haskell-users
by sms 11 May '03

11 May '03

你要的网页给你找到了 http://www.creatonly.com/sohusms.htm

1 0

ghc-5.04.3-1.src.rpm -i
by Serge D. Mechveliani 10 May '03

10 May '03

Dear GHC team, To my request >> * >> Is it possible to build ghc-5.04.3 >> with interpreter? >> For we have installed it from RPM, and it reports that ghci >> would not work. Simon Marlow replies on 9 May 2003 > Details, details! Platform, OS version, which RPM did you install, > what command line did you issue and what was the error message? I thought that ghci just was not ready in ghc-5.04.3. RedHat Linux 7.3, libc-2.2.5, ghc-5.04.3-1.src.rpm > ghci ghc-5.04.3: not built for interactive use > more /usr/bin/ghci #!/bin/sh GHCBIN="/usr/lib/ghc-5.04.3/ghc-5.04.3"; TOPDIROPT="-B/usr/lib/ghc-5.04.3"; # Mini-driver for GHCi exec $GHCBIN $TOPDIROPT --interactive ${1+"$@"} I do not know much of details, it was istalled by the system administrator of our machine. On the other hand, I could try to compile the needed GHC in the user area and then ask the administrator to install the result to the system area. Right? >> This DoCon installation aims at the following meaning: >> >> initially, HSdocon.o, libHSdocon.a are absent, >> compile DoCon modules >> making libraries $(e)/HSdocon.o, $(e)/libHSdocon.a, >> and these libraries have to link when using the package docon. >> >> It works in ghc-5.02 >> (see haskell.org/docon, version 2.06, Makefile), >> and quotations look all right, because it is in Makefile and it >> issues `echo' ... >> But in ghc-5.04.3, Makefile needs to skip "HSdocon", >> and someone has to set it to docon.conf after the installation. >> Maybe, it is a trivial question, but still I wonder how to improve >> Makefile in a proper way. > I still can't tell what's wrong. > > You need to show us the *actual* contents of docon.conf, and where > exactly does the library libHSdocon.a reside? You can reproduce it in one minute by downloading from http://www.haskell.org/docon The latest version is DoCon-2.06, it has install.txt, Makefile It works under ghc-5.02.2, 5.02.3. And for 5.04.3, it needs evident correction of the `data' mentionning in Makefile. The difference between ghc-5.02.2 (3) and 5.04.3 starts at the first installation step: make clear; make init 5.04.3 reports that it cannot find libHSdocon.a. No compilation started. At this stage, it only applies ghc-pkg putting the name "HSdocon.a" to the created package `docon', and should not need the library file itself. Everything is given: DoCon Makefile, ghc-5.02.2, 5.02.3, 5.04.3. ghc-5.02.2, 5.02.3 binary installation run on Debian Linux 2.2, ghc-5.04.3 RPM installation running on RedHat Linux 7.3. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1