- Glasgow-haskell-users

RE: fatal error: heapCensus
by Simon Marlow 03 Nov '00

03 Nov '00

> unfortunately I forgot to ask my questions ;o) > > What does heapCensus mean ? It's an internal error in GHC's heap profiler, and indicates a bug somewhere. Could you send us the code? Cheers, Simon

1 0

RE: My mistake is harder to diagnose than it could be
by Simon Peyton-Jones 02 Nov '00

02 Nov '00

In the new GHCi system we plan to make it *required* that the module name and the file name match, EXCEPT for module Main. This seems to remove a whole class of errors. Yell if that'll be problematic for you Simon | -----Original Message----- | From: qrczak(a)knm.org.pl [mailto:qrczak@knm.org.pl] | Sent: 18 August 2000 19:45 | To: glasgow-haskell-users(a)haskell.org | Subject: My mistake is harder to diagnose than it could be | | | I've just done the same mistake a third time: took a module A, moved | part of it to a new module B, imported A from B, but forgot to change | the module header in B which still said "module A". | | The GHC's answer to that when compiling B.hs is that the module A | does not export a bunch of things (if listed explicitly in import), | or that they are not found at all (if imported the whole A). Things | that are easily seen exported from A.hs - strange that I was wondering | again what's going on. | | GHC should warn when a module imports itself. Or warn about mismatches | between the module and file name except Main. Or whatever - | the current | error message is not very helpful. | | -- | __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ | \__/ | ^^ SYGNATURA ZASTEPCZA | QRCZAK | |

1 0

fatal error: heapCensus
by Oliver Braun 02 Nov '00

02 Nov '00

Dear GHC-Users, I am currently developing part of the EdComb library (http://ist.unibw-muenchen.de/EdComb/) I have compiled all files with the -prof and the -auto-all flag. When starting the program * without any RTS options -> everything is OK * with +RTS -p -> everything is OK * with +RTS -h -> fatal error: heapCensus I am using GHC version 4.08.1 on a Debian/GNU Linux Box, installed with the newest Debian packages from http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian. Olli -- Federal Armed Forces University Munich Tel. 089 - 60190686 Werner-Heisenberg-Weg 102/128 Fax. 089 - 244333158 85577 Neubiberg mobil 0170 - 9317618

1 1

RE: Fun with GHC's optimiser
by Simon Peyton-Jones 02 Nov '00

02 Nov '00

I can never resist messages like these, even when I'm meant to be doing other things. It's very helpful when people offer fairly precise performance-bug reports. Thanks! | I am wondering whether there is a particular reason why the | optimiser doesn't pull the | | (1) a = NO_CCS PArray! [wild1 mba#]; This one is a definite bug. It turns out that the head of the before-ghci-branch doesn't have this bug, so I'm disinclined to investigate it further. | (2) case w of wild3 { | I# e# -> | | As for (2), the loop would be nice and straight if that | unboxing where outside of the loop - as it is, we break the | pipeline once per iteration it seems This one is a bit harder. Basically we want to make a wrapper for a recursive function if it's sure to evaluate its free variables. In fact the 'liberate-case' pass (which isn't switched on in 4.08) is meant to do just this. It's in simplCore/LiberateCase.lhs, and it's not very complicated. I've just tried it and it doesn't seem to have the desired effect, but I'm sure that's for a boring reason. If anyone would like to fix it, go ahead! (You can't just say '-fliberate-case' on the command line to make it go; you have to add -fliberate-case at a sensible point to the minusOflags in driver/Main.hs.) Incidentally, you'll find that -ddump-simpl gives you a dump that is pretty close to STG and usually much more readable. Most performance bugs show up there. -dverbose-simpl gives you more clues about what is happening where. | Also if somebody is looking at the attached source, I was | wondering why, when I use the commented out code in | `newPArray', I get a lot worse code (the STG code is in a | comment at the end of the file). In particular, the lambda | abstraction is not inlined, whereas `fill' gets inlined into | the code of which the dump is above. Is it because the | compiler has a lot harder time with explicit recursion than | with fold/build? If so, the right RULES magic should allow | me to do the same for my own recursively defined | combinators, shouldn't it? I couldn't figure out exactly what you meant. The only commented out code is STG code. Maybe send a module with the actual source you are bothered about. S

2 1

RE: Fun with GHC's optimiser
by Simon Marlow 02 Nov '00

02 Nov '00

> I am wondering whether there is a particular reason why the > optimiser doesn't pull the > > (1) a = NO_CCS PArray! [wild1 mba#]; > > and the > > (2) case w of wild3 { > I# e# -> I checked with the before-ghci-branch compiler, and it pulls out (1) but not (2). Simon did a fair amount of work on improving the compilation of IO-ish code and code with lots of newtypes in it after we noticed some problems like the ones you point out above. We'll need to investigate whether the case can be pulled out of the loop too, though. Cheers, Simon

1 0

RE: Quick question re RULES
by Simon Peyton-Jones 02 Nov '00

02 Nov '00

| PrelBase contains the appended code. Am I correct in | assuming that the stuff is structured as it is, because the | "map" rule first `breaks' the map `open', which exposes it | to the various foldr/build rules, and if no foldr/build rule | matches, the "mapList" rule `closes' it again in a later | phase of optimisation - after build was inlined? If so, it | seems like the whole thing depends a bit on the timing of | the various optimsations (the map might be closed again | before any of the foldr/build rules fires). Is this maybe | the reason that build has an INLINE 2 pragma, which delays | its inlining, and thus, the closing of the map? That's exactly it. | All very cunning, it seems ;-) A bit too cunning for comfort. I wish I could think of a better way to expose map's impl using build without paying a price for doing so if it turns out not to fuse with anything. But so far I've failed to do so. Is this a propos of your new transformations for parallelism? Simon

2 1

Fun with GHC's optimiser
by Manuel M. T. Chakravarty 02 Nov '00

02 Nov '00

Questions over questions arise in my quest to understand GHC's code generator. In this nice little piece of STG $w$snewPArray = NO_CCS[] \r[ww w] case newIntArray# [ww realWorld#] of wild { (#,#) s2# mba# -> case -# [ww 1] of y { DEFAULT -> let { wild1 = NO_CCS I#! [ww]; } in case ># [0 y] of wild2 { True -> PArray [wild1 mba#]; False -> let { $wgo2 = NO_CCS[] \r[y1 y2] let { a = NO_CCS PArray! [wild1 mba#]; } in case w of wild3 { I# e# -> case writeIntArray# [mba# y1 e# y2] of s2#1 { DEFAULT -> case ==# [y1 y] of wild11 { True -> (#,#) [s2#1 a]; False -> case +# [y1 1] of stg_c2aL { DEFAULT -> $wgo2 stg_c2aL s2#1 }; } }; }; } in case $wgo2 0 s2# of wild3 { (#,#) ds r -> r; }; } }; }; I am wondering whether there is a particular reason why the optimiser doesn't pull the (1) a = NO_CCS PArray! [wild1 mba#]; and the (2) case w of wild3 { I# e# -> out off the $wgo2 loop - or at least push (1) down into the True branch of `case ==# [y1 y] of'. I would say that (1) in this form pointlessly allocates heap like mad, but is only using one of the many copies of `a', namely the one allocated in the final iteration and returned to the caller. As for (2), the loop would be nice and straight if that unboxing where outside of the loop - as it is, we break the pipeline once per iteration it seems (if the branch prediction isn't very clever). Or do I misunderstand something here, or is there maybe some magic after STG that gets rid of the stuff? I attach the Haskell source, which I compiled with ghc -O -c PArrays.hs -fglasgow-exts -ddump-stg (This is 4.08.1 of course.) Also if somebody is looking at the attached source, I was wondering why, when I use the commented out code in `newPArray', I get a lot worse code (the STG code is in a comment at the end of the file). In particular, the lambda abstraction is not inlined, whereas `fill' gets inlined into the code of which the dump is above. Is it because the compiler has a lot harder time with explicit recursion than with fold/build? If so, the right RULES magic should allow me to do the same for my own recursively defined combinators, shouldn't it? Cheers, Manuel PS: Otherwise, it is quite impressive what the RULES and inliner do to the foldr that produced the above code.

1 0

Quick question re RULES
by Manuel M. T. Chakravarty 02 Nov '00

02 Nov '00

PrelBase contains the appended code. Am I correct in assuming that the stuff is structured as it is, because the "map" rule first `breaks' the map `open', which exposes it to the various foldr/build rules, and if no foldr/build rule matches, the "mapList" rule `closes' it again in a later phase of optimisation - after build was inlined? If so, it seems like the whole thing depends a bit on the timing of the various optimsations (the map might be closed again before any of the foldr/build rules fires). Is this maybe the reason that build has an INLINE 2 pragma, which delays its inlining, and thus, the closing of the map? All very cunning, it seems ;-) Cheers, Manuel -=- map :: (a -> b) -> [a] -> [b] map = mapList -- Note eta expanded mapFB :: (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst mapFB c f x ys = c (f x) ys mapList :: (a -> b) -> [a] -> [b] mapList _ [] = [] mapList f (x:xs) = f x : mapList f xs {-# RULES "map" forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs) "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f.g) "mapList" forall f. foldr (mapFB (:) f) [] = mapList f #-}

1 0

RE: ppr for Haskell Abstract Syntax
by Simon Marlow 01 Nov '00

01 Nov '00

> Hi - > I was wondering if anyone knows if there is a pretty printer > for Haskell > Abstract Syntax anywhere? I've been asking around, but > haven't located > one yet. If you know of one that I could use, it would be > really helpful! > Thanks in advance, > *Kate We have one in GHC's CVS source tree now. hslibs/hssource contains a Haskell abstract syntax, parser, and a pretty printer. It should compile on pretty much any version of GHC, but you'll probably need a recent version of Happy (1.8) for the parser. Cheers, Simon

1 0

RE: ppr for Haskell Abstract Syntax
by Simon Peyton-Jones 01 Nov '00

01 Nov '00

GHC has a pretty printer for Haskell. It's in ghc/compiler/hsSyn/*.lhs, along with the (numerous) data type declarations that define the full Haskell syntax. It would take a little work to rip it out of GHC, mind you Simon | -----Original Message----- | From: Kate S. Golder [mailto:kgolder@wellesley.edu] | Sent: 31 October 2000 21:07 | To: glasgow-haskell-users(a)haskell.org | Subject: ppr for Haskell Abstract Syntax | | | Hi - | I was wondering if anyone knows if there is a pretty printer | for Haskell | Abstract Syntax anywhere? I've been asking around, but | haven't located | one yet. If you know of one that I could use, it would be | really helpful! | Thanks in advance, | *Kate | | ********************** | Kate S. Golder | Wellesley College | Class of 2002 | | Freeman Hall | Wellesley College | Wellesley, Ma 02481 | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0