February 2005 - Glasgow-haskell-users

RE: Help with a Shootout program
by Bayley, Alistair 25 Feb '05

25 Feb '05

> From: Simon Marlow [mailto:simonmar@microsoft.com] > > PackedStrings are still slow in 6.x. I know there are various other > PackedString implementations out there, we just need to > incorporate one. They certainly seem to be. Below are the profiles (compiled with -O2; ran them twice; took the second run) of Simon's old PackedString version, and Alson's Hash version. Simon's uses way more memory, too. I might try some more profiling later to narrow down the slow bits. > From: Alson Kemp [mailto:Alson.Kemp@sloan.mit.edu] > > I tried Simon's version, but it throws a "Fail: > Ix{Int}.index: Index > (5) out of range ((0,4))" error. Haven't tracked down the cause yet. Here's the fix (subtract one from (lengthPS ps)): -- Looks bad, but GHC does a great job of optimising it: hashPS :: PackedString -> Int hashPS ps = foldr f 0 (map (ord.indexPS ps) [0..((lengthPS ps) - 1)]) where f n m = n + m * 128 `mod` 1048583 ------------------------------- Alson's: spellcheck +RTS -p -hr -H10m -K20m -RTS total time = 1.84 secs (92 ticks @ 20 ms) total alloc = 69,112,588 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc main Main 58.7 21.2 spellcheck Main 23.9 34.2 buildHash Main 17.4 44.6 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 main Main 146 1 58.7 21.2 100.0 100.0 spellcheck Main 149 0 23.9 34.2 23.9 34.2 buildHash Main 148 1 17.4 44.6 17.4 44.6 CAF Main 140 1 0.0 0.0 0.0 0.0 main Main 147 0 0.0 0.0 0.0 0.0 CAF GHC.Handle 103 6 0.0 0.0 0.0 0.0 CAF System.Posix.Internals 81 4 0.0 0.0 0.0 0.0 ------------------------------- Simon's: spellcheck +RTS -p -hr -H10m -K20m -RTS total time = 6.90 secs (345 ticks @ 20 ms) total alloc = 351,514,332 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc main Main 93.0 93.6 hashPS Main 3.2 2.4 elemHashTable Main 2.0 0.1 addToHashTable Main 1.7 0.2 CAF Data.PackedString 0.0 3.6 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 main Main 166 1 93.0 93.6 100.0 96.4 elemHashTable Main 171 38618 2.0 0.1 2.9 1.3 hashPS Main 172 38618 0.9 1.2 0.9 1.2 addToHashTable Main 168 38617 1.7 0.2 4.1 1.4 hashPS Main 169 38617 2.3 1.2 2.3 1.2 CAF Main 160 4 0.0 0.0 0.0 0.0 hashPS Main 170 0 0.0 0.0 0.0 0.0 main Main 167 0 0.0 0.0 0.0 0.0 CAF GHC.Handle 123 5 0.0 0.0 0.0 0.0 CAF System.Posix.Internals 101 4 0.0 0.0 0.0 0.0 CAF Data.PackedString 86 1 0.0 3.6 0.0 3.6 ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

Re: Help with a Shootout program
by Alson Kemp 25 Feb '05

25 Feb '05

>Welcome to the club :-) >http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg06012.html I tried Simon's version, but it throws a "Fail: Ix{Int}.index: Index (5) out of range ((0,4))" error. Haven't tracked down the cause yet. So I guess that the upshot is just that "GHC is slow on this test." Is lazy evaluation what is slowing this down so badly? - Alson

1 0

RE: Kinds in ghc
by Simon Peyton-Jones 25 Feb '05

25 Feb '05

Well, it's a bug really, but not one that's easy to fix. Thanks for pointing it out; I've added it as a SourceForge bug so we don't forget it. SImon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Johan Glimming | Sent: 24 February 2005 12:31 | To: glasgow-haskell-users(a)haskell.org | Subject: Kinds in ghc | | Hi | | I can report success on compiling latest CVS on Mac OS X including | stage 2 with ghci support. (greencard does not compile, but that's not | a problem for ghc to be compiled it seems.) | | Now that I have the compiler up, I notice that types are not reported | as before. Instead of nice t,t', etc, I get random strings: | | Kind error: Expecting kind `k_a1JA -> k_a1JE -> k_a1JI -> *', | but `DUnit t' has kind `k_a1JA -> k_a1JE -> *' | | Is this a mere debug mode I have enabled by accident (no parameter | passed to make or configure though), or is this something else? | | P.S. infix type synonyms seems to work well so far! | | Johan Glimming. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Infix typeconstructors shown as prefix
by Simon Peyton-Jones 25 Feb '05

25 Feb '05

Ive fixed this to print the parens round the type constructor anyway. But it won't print infix. Doing the right thing requires knowledge of fixities, which isn't (yet) plumbed to the right place S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Remi Turk | Sent: 20 February 2005 22:00 | To: glasgow-haskell-users(a)haskell.org | Subject: Infix typeconstructors shown as prefix | | Hi, | | with the following definitions | | {-# OPTIONS -fglasgow-exts #-} | data a :++: b | class a :--: b | | ghci prints the infix type(classe)s as prefix: | | *Main> :i :++: | data :++: a b -- Defined at foo.hs:2:7 | | *Main> :i :--: | class :--: a b where -- Defined at foo.hs:3:8 | | or (a "real-world" example): | | *Main> :t fac (One:@Zero:@Zero) | fac (One:@Zero:@Zero) :: :@ (:@ (:@ (:@ One One) Zero) Zero) Zero | | Is this a bug, a feature or just Not Implemented Yet(TM)? | | Groeten, | Remi | | P.S. Are infix class-names a documented extension at all? | | -- | Nobody can be exactly like me. Even I have trouble doing it. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: new ghc under solaris
by Simon Marlow 25 Feb '05

25 Feb '05

On 25 February 2005 10:09, Christian Maeder wrote: > Simon Marlow wrote: >> What version of gcc are you using? > > I used gcc_2.95.3 until I discovered the warning: > > LdvProfile.c:43: #error Please use gcc 3.0+ to compile this file > with DEBUG; gcc < 3.0 miscompiles it > > I've switched to gcc_3.4.3. Now the final linking of the stage2 > compiler fails (with thousands of undefined symbols). > > ../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.5 -H16m -O > [...] > DriverState_WayThreaded_closure stage2/main/DriverFlags.o > ld: fatal: Symbol referencing errors. No output written to > stage2/ghc-6.5 > collect2: ld returned 1 exit status > > As a linker (that ./configure finds) I use gnu-ld_2.14, but gcc_3.4.3 > uses the solaris linker (see below). This looks like a mangler or a splitter problem (those manky Perl scripts we use to postprocess assembly code). Probably gcc 3.4.3 is generating something we don't recognise. Could you try the following: - Add SplitObjs=NO to build.mk, recompile the libraries (make clean && make) and try to compile a simple program with the stage1 ghc. If that works, then it's a splitter problem. - If you get link errors, then $ cd libraries/base $ rm -f GHC/Base.o $ make GHC/Base.o EXTRA_HC_OPTS='-keep-s-file -keep-raw-s-file' and send me the contents of GHC/Base.s and GHC/Base.raw_s. Cheers, Simon

1 0

RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86or x86-64)
by Simon Marlow 24 Feb '05

24 Feb '05

On 22 February 2005 20:05, Brian Strand wrote: > I'm having some serious "issues" getting GHC to run on Suse 9.2/x86 > (or x86-64 for that matter, although I didn't really expect that to > work without some pain and suffering). I've had no luck with 6.2.2, > or any 6.4 release candidate. Here is a typical example: after doing > a "./configure; make in-place", I get the following: > > /home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20 050221: > error while loading shared libraries: libreadline.so.4: cannot open > shared object file: No such file or directory > > Fair enough; "rpm -q readline" gives me readline-5.0-1.2. So off to > the sources I go: > > cd ~/src/ghc-6.4.20050221 > ./configure > ... > configure: error: GHC is required unless bootstrapping from .hc files. > > After reading through most of the GHC building guide (paying > particular attention to section 10), I try: > > ./configure --enable-hc-boot You actually need the .hc source files too, which don't come with the source distribution because they have to be built for each target platform. That section of the Building Guide wasn't really clear enough on this issue, so sorry if that meant you wasted some time. We've since updated the instructions in the Building Guide. For compiling GHC on a platform for which you don't already have a GHC binary, the Approved Method is to go through the unregisterised bootstrap instructions in section 10.2. It's possible to do a registerised bootstrap, which would be shorter, but we haven't tested and documented the procedure. Cheers, Simon

5 7

RE: RFC: hyperlinks in Haddock docs
by Simon Marlow 24 Feb '05

24 Feb '05

On 22 February 2005 19:37, Duncan Coutts wrote: > Excellent! Thanks a lot. > > Any hint as to when the next Haddock release will be? Maybe when I've got this GHC release out of the way and my hair has grown back :-S Simon

2 1

RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86or x86-64)
by Simon Marlow 24 Feb '05

24 Feb '05

On 24 February 2005 02:38, Wolfgang Thaller wrote: > So maybe x86-Linux needs a ghc binary with as few library dependencies > as possible, to facilitate bootstrapping on different Linux distros? That's a good idea. GHCi doesn't work if the GHC binary is linked with -static, so we'll have to make a separate statically-linked binary distribution, though. Cheers, Simon

1 0

RE: Help with a Shootout program
by Simon Marlow 24 Feb '05

24 Feb '05

On 24 February 2005 14:47, Carsten Schultz wrote: > The real performance problem propbably is not O(n) vs. O(n*log n) but > slow String operations in general. After all, String is a lazy list > of Char. Have a look at the thread mentioned above, possibly Simon's > version has become fast again, otherwise it would be an opportuniy to > reconsider the problems mentioned there. PackedStrings are still slow in 6.x. I know there are various other PackedString implementations out there, we just need to incorporate one. Cheers, Simon

1 0

RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86 or x86-64)
by Simon Marlow 24 Feb '05

24 Feb '05

On 24 February 2005 11:12, Malcolm Wallace wrote: > Ideally, if ghc were implemented in something closer to Haskell'98, > it would be possible to double-bootstrap up from gcc -> nhc98 -> > ghc unregisterised -> ghc registerised, on almost any new platform. > But the amount of work required to 98-ify ghc is considerable (there > are 148 kLoC to check), and it is hard to say whether it would > be worthwhile. Maybe someone fancies tackling it as a medium-size > project? It's feasible, but unfortunately probably not practical. Not only would someone have to do the work, we'd have to maintain the Haskell 98 version too. That's yet another way to build GHC, and there are already too many variables for us to test them all. However, a more reasonable approach might be to remove the platform dependencies from GHC and the libraries it requires for bootstrapping. That is, make it so that unregisterised .hc files are platform-independent. I think we used to have this property in the distant past, but it got lost somewhere along the way. It would mean banishing platform differences into C code wherever necessary, which would result in more C code and less Haskell code, but it might be worthwhile. Cheers, Simon

1 0