July 2010 - Glasgow-haskell-users

Casts, and allocation
by Louis Wasserman 02 Jul '10

02 Jul '10

Hey, I was wondering how difficult it would be to improve handling of casts, as follows: when looking at Core, I see things like (\ (ds_dcKZ :: Data.TrieMap.TrieKey.TrieMap (Data.TrieMap.Regular.Base.App f_XcwB k_XcwD) a_acAi) -> f_scPr (ds_dcKZ `cast` (trans (Data.TrieMap.Regular.App.TFCo:R:TrieMapAppa f_XcwB k_XcwD a_acAi) (Data.TrieMap.Regular.App.NTCo:R:TrieMapAppa f_XcwB k_XcwD a_acAi) :: Data.TrieMap.TrieKey.TrieMap (Data.TrieMap.Regular.Base.App f_XcwB k_XcwD) a_acAi ~ Data.TrieMap.Regular.Class.TrieMapT f_XcwB k_XcwD a_acAi))) which is equivalent to a single cast of f. I get that generalized newtype deriving does something like this automatically -- unfortunately, at the moment, I'm using a class with associated types, so I can't do that. How difficult would it be to identify and rewrite these, when they appear in non-recursive lets? (I'm actually experimenting with implementing the change myself, but I've never hacked GHC before, so we'll see how it goes...) Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

1 0

RE: [Haskell-cafe] checking types with type families
by Simon Peyton-Jones 01 Jul '10

01 Jul '10

| Here's a concrete case I recently ran into: | | type family SomeOtherTypeFamily a | class SomeClass a where type SomeType a | instance a ~ SomeOtherTypeFamily b => SomeClass a where | type SomeType a = (b,Int) | -- (error) Not in scope: type variable `b' | | The same thing with fundeps: | | class SomeClass a b | a -> b | instance a ~ SomeOtherTypeFamily b => SomeClass a (b,Int) | -- works fine It's not the same thing at all! The code you give certainly should fail. Suppose you use fundeps thus: class C a b | a->b where op :: a -> b -> b The idiomatic way to replace this with type functions is to remove the 'b' parameter, thus: class C a where type B a op :: a -> B a -> B a Sometimes you don't want to do this. For example, you might have a bidirectional fundep. Then you can (or rather will be able to) use a superclass thus: class (B a ~ b) => C a b where type B a The superclass says that you can only instantiate this class with a second argument b that is equal to (B a). Thus you might have an instance instance C Int Bool where type B Int = Bool Meanwhile we are working hard on the new type inference engine, which will allow superclass equalities like these. Simon

1 0

Help with Win64 port
by George Brewster 01 Jul '10

01 Jul '10

Hey, I'd really like to see ghc working on 64-bit Windows, so I've decided to take at least a quick stab at getting it going. Having talked to some of the people on #ghc, it sounds like the first thing to do is get an unregisterised build going, which sounded like it may be managable. So to that end, I've pulled the 6.12 branch, done a 32-bit build, changed the build config to do an unregisterised build and turn off the native code generator, found a version of mingw64 which seems to work for me, stuffed it in in place of the in-tree mingw, and got my build to fail. At this point, I'd like to get a general idea of what my strategy should be. I read the Building/Porting page on the wiki, and used the config file there as an example of how to do an unregisterised build, but have been ignoring anything related to the hc file bootstrapping process, as I have a working ghc on my platform, just of the wrong bitness. In particular, if there are any changes that you know I'll need to make to the source to get this working, please let me know. The more of those I learn about now, the less fumbling around I'll have to do as things break. In particular, is there some place where I indicate that I'm build a 64-bit compiler? I didn't find anything with a quick look. I have very little time to work on it, and no familiarity with ghc internals, so I wouldn't expect much, but I'm hoping I can get it going... -George

2 1

Re: [Haskell-cafe] Space leak with unsafePerformIO
by Yitzchak Gale 01 Jul '10

01 Jul '10

Henning Thielemann wrote on Haskell Cafe: >> Attached is a program with a space leak... >> I have coded a simple 'map' function, once using unsafePerformIO and >> once without. UnsafePerformIO has a space leak in some circumstances. >> In the main program I demonstrate cases with and without space leak. >> Without space leak the program writes a file to the disk until it >> is full. Bertram Felgenhauer wrote: > The program relies on the GC doing short-cut evaluation of record > selectors to avoid a space leak... > Use of suffix: Due to the call of Main.go1 this is *not* a record > selector. It is compiled to an actual case expression, which to the > garbage collector looks just like an ordinary thunk. A reference to > Main.ds is kept around until the suffix is about to be processed > and a memory leak ensues. > The good news is that the problem is completely unrelated to > unsafePerformIO (the presence of unsafePerformIO makes optimisations > more difficult, but any pure function of sufficient complexity would > have the same effect). Is there already a GHC Trac bug for this? Link to Bertram's original email, with detailed analysis of the GHC Core: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079479.html Thanks, Yitz

2 1

heap profiling
by Evan Laforge 01 Jul '10

01 Jul '10

I've been trying to profile my program and having some trouble. I imagine other people have stumbled across these same issues, so hopefully I can benefit from someone else's experience. In return, if I can figure out some of these things, I'll put it up at http://www.haskell.org/haskellwiki/How_to_profile_a_Haskell_program or maybe make make a heap profiling page linked from that. Firstly a few miscellaneous questions: When running '-hc -hblag,drag' it works for a little while and then stops. The app is still hung, but cpu has gone to 0%. The disk is also idle, so I don't think it's swapping. According to -S, all garbage collection has stopped too. It's apparently due to something about this particular profile, since reducing the amount of data it handles just results in a sooner hang. This same combination works with other profiles, so apparently something the code is doing is locking up. Has anyone else seen this? Any tips on how to troubleshoot where it's getting stuck, doing what? If it sounds like a ghc bug I can try to trim down the size and submit a ticket. GHC 6.12.1 on OSX. The image link from http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/profiling.html is broken, which makes it a little harder to understand the documentation. -s stats say GC time is 46%, productivity is 32%. That's pretty bad, right? And where is the remaining 22% going? The ghc manual says lag is "time between creation and first use" and drag is "time between last use and last reference is dropped". I think I understand drag: it means you haven't touched the data for a while before it goes out of scope or its retainer goes out of scope. So for instance: stuff = do st <- get x1 st x2 Does this mean that 'st' will be dragging through 'x2' as it would in an imperative language? I gather the usual haskell use is when combined with laziness: 'Map.insertWith (+) "a" 42' will keep the old value of "a" around until you look "a" up and force it, since the (+) won't be applied until then. Same with foldl. Are there some other classic examples of drag? Searching for "haskell dragging problem" doesn't yield much to do with memory use. Lag I'm not so sure about. How is something created before it's used? And... what's INHERENT_USE? And what about VOID? How can an object be created but never used? What triggered its creation? So, the main question: I have a program that runs some computation in a monad stack before extracting the final result, a list, and passing it on. When run under the heap profiler, there's a huge spike in that phase, which I think should be mostly bogus usage, since the final output is so relatively small. When I run under -hb I see big bands for LAG and DRAG. According to -hd the top 3 users are: <mtl-1.1.0.2:Control.Monad.Writer.Lazy.sat_sltc> (,) D:Monad This is kind of puzzling to me... first of all I've never seen an explanation for sat_* closure descriptors, and second of all, why does it not show up in the .prof file at all? I switched to Writer.Strict and the drag disappeared, which helped, but the lag is still there, and the top -hd is now <mtl-1.1.0.2:Control.Monad.Writer.Strict.sat_soa1> State stg_ap_2_upd_info (the top -hy is "*", which I gather means "don't know"). And what's "stg_ap_2_upd_info"? The top item accounts for 70% of the memory usage. One obvious candidate for the lag is Writer's data (DList Log.Msg) is collecting and only being forced at the end of the computation, but there is no logging in this section and in any case should never be 30M of it! -hc is not helpful since every monadic operation is charged a little bit, -hr is similarly unhelpful (top retainer is MANY... hah). So what exactly is this sat_*? Where is the memory going? I guess it doesn't have an SCC since it doesn't show up in the .prof output. Is there some place I can manually put an SCC? I was able to fix the drag just by guessing at a strict writer, but the lag is still around. Is there another spot in Writer's >>= that could be accumulating? What's *in* that giant mountain of lag?

4 11