From tomasz.zielonka at gmail.com Fri Dec 1 00:30:41 2006 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Fri Dec 1 00:28:59 2006 Subject: bang patterns give fundamentally new capabilities? In-Reply-To: <20061201041313.GF6726@momenergy.repetae.net> References: <20061201041313.GF6726@momenergy.repetae.net> Message-ID: <20061201053041.GA5918@lambda> On Thu, Nov 30, 2006 at 08:13:13PM -0800, John Meacham wrote: > I was recently presented with the problem of writing a function like so > > seqInt__ :: forall a . a -> Int# -> Int# > seqInt__ x y = x `seq` y > > which seems fine, except 'seq' of type forall a b . a -> b -> b cannot > be applied to an unboxed value. > > I could not think of a way to actually get the behavior How about something like this: seqInt__ :: forall a . a -> Int# -> Int# seqInt__ x y = case x `seq` (I# y) of (I# y') -> y' The question is: will GHC optimize out the unneccesary boxing and unboxing? Looking at the output from "ghc -O2 -ddump-simpl" makes me think the answer is "yes". Best regards Tomasz From catamorphism at gmail.com Fri Dec 1 07:52:43 2006 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Fri Dec 1 07:50:55 2006 Subject: RULES and strictness Message-ID: <4683d9370612010452r3611fc01o999c4b188720cdc@mail.gmail.com> > > when performing strictness/abscence/one-shot analysis, are rule bodies > taken into account? No. > like, would the following cause trouble making const > no longer absent in its second argument? > > const x y = x > > {-# RULE "const/seq" forall a b . const a b = seq b a #-} > > by trouble I mean the compiler failing or producing bad code in some > way, rather than the obvious trouble of changing the meaning of const. > No, because of the worker/wrapper transform. You can think of strictness analysis as doing something like this in this case: const x y = x => const x y = constW x constW x = let y = error "entered absent argument!" in x (of course, strictness analysis only does the work of determining that const is absent in its second argument, and the worker/wrapper transform phase is a separate pass that happens later.) So, from then on, GHC will inline const wherever possible, and the rule "const/seq" will no longer be applicable, because it applies to const, not constW. Note that even if const doesn't end up getting inlined for some reason, the presence of the rule doesn't cause any problems. It's perfectly valid to replace (const a b) with (constW a) or with (seq b a). > it is noted in the deforestation papers that rules can change the > sharing properties of code and we are okay with that. I was wondering if > they could safely change the strictness or abscence properties of code > as well? > Given the example above, I think it's fairly safe to say that rules can safely change strictness and absence properties, or at least "safe" in the sense that it shouldn't cause the compiler to crash or to generate code that crashes. (Since even GHC's strictness analysis on its own, ignoring the presence of rules, hasn't been formally proven correct yet, I'm being rather hand-wavy in saying that.) But, it is kind of weird to have a rule that changes these properties. I realize the example you gave is just for the sake of argument, but I can't think of a real situation where you'd want to have a rule that changed strictness properties (rather than expressing the strictness you wanted in the code), though I'm open to being convinced otherwise. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "I flip on the television and watch sad movies / And look for sad sick people like me" -- Tegan and Sara From sven.panne at aedion.de Fri Dec 1 07:54:40 2006 From: sven.panne at aedion.de (Sven Panne) Date: Fri Dec 1 07:52:51 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> Message-ID: <200612011354.40238.sven.panne@aedion.de> Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: > [...] Anyone know of any issues with the current HOpenGL on Intel? [...] The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I assume it is a problem with Mac + Intel. I don't have access to such a platform, so some help is needed. Do any of the examples from http://darcs.haskell.org/packages/GLUT/examples/ work on your platform? Cheers, S. From wolfgang.thaller at gmx.net Fri Dec 1 08:47:30 2006 From: wolfgang.thaller at gmx.net (Wolfgang Thaller) Date: Fri Dec 1 08:45:50 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: <200612011354.40238.sven.panne@aedion.de> References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> <200612011354.40238.sven.panne@aedion.de> Message-ID: The NeHe tutorials work for me with both GHC 6.6 and HEAD on my Intel Mac; however, I'm not using MacPorts. Is anyone else here who uses MacPorts on an Intel Mac, to confirm or deny the bug? Cheers, Wolfgang From mboes at tweag.net Fri Dec 1 11:17:30 2006 From: mboes at tweag.net (Mathieu Boespflug) Date: Fri Dec 1 11:15:50 2006 Subject: newtype deriving clause ceases to work in HEAD In-Reply-To: References: <63c0799b0611281625qee4dab2h1c7bc21265c92ef8@mail.gmail.com> Message-ID: <63c0799b0612010817k5358c932o641b5cf7e0b613ca@mail.gmail.com> > GHC 6.4.1 accepts your declaration but generates a useless insatance decl. GHC 6.6 will still let you generate the same instance, but only if you use another type variable, for instance > deriving (MonadReader x) > > GHC 6.6's behaviour is defined by the appropriate section of the user manual, which you got when you pulled the HEAD. > > In short, a false alarm, I believe, though it took me a few minutes to puzzle out! Ah! Well spotted! Sorry for the bother. Something I hadn't noticed after dozens of minutes staring blankly after some late night coding. I was rather puzzled given that I had written quite a bit of typechecked code on top of the erroneous CM monad declaration. Thanks for your help Simon, Mathieu > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Mathieu Boespflug > | Sent: 29 November 2006 00:25 > | To: glasgow-haskell-users@haskell.org > | Subject: newtype deriving clause ceases to work in HEAD > | > | Hi, > | > | The following code compiles with GHC 6.4.2, but does not typecheck > | with GHC HEAD pulled on Sunday. > | > | module CompilerMonad where > | > | import Control.Monad > | import Control.Monad.Reader > | import Control.Monad.Error > | > | newtype CompilerError = CE String deriving Error > | > | newtype CM r a = CM (ReaderT r (ErrorT CompilerError (Either > | CompilerError)) a) > | deriving (Monad, MonadReader a, MonadError CompilerError) > | > | Compiling the code gives: > | > | $ /home/mboes/src/ghc/compiler/stage2/ghc-inplace /tmp/CompilerMonad.hs > | > | /tmp/CompilerMonad.hs:10:8: > | Can't make a derived instance of `MonadReader a (CM r)' > | (even with cunning newtype deriving: > | the eta-reduction property does not hold) > | When deriving instances for `CM' > | > | whereas with 6.4.2 > | > | $ ghc-6.4.2 --make /tmp/CompilerMonad.hs > | Chasing modules from: /tmp/CompilerMonad.hs > | Compiling CompilerMonad ( /tmp/CompilerMonad.hs, /tmp/CompilerMonad.o ) > | > | As the above code seemed to be doing what I meant for it to do in > | 6.4.2, and the docs for HEAD don't seem to have changed, I'm curious > | as to why this doesn't work in HEAD anymore, and indeed, if this is > | perhaps a regression? > | > | Thanks, > | > | Mathieu > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From darkdescendant at gmail.com Fri Dec 1 13:19:27 2006 From: darkdescendant at gmail.com (Joe Jones) Date: Fri Dec 1 13:17:42 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: <200612011354.40238.sven.panne@aedion.de> References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> <200612011354.40238.sven.panne@aedion.de> Message-ID: <8bd57b240612011019r63ca0395j5c8a1eaf85344c23@mail.gmail.com> Well, it doesn't lock the whole machine but loading Alpha3D.hs int GHCi and typing main causes a window to be displayed with no content and ghc 6.6 locked up, requiring a hard kill. On 12/1/06, Sven Panne wrote: > Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: > > [...] Anyone know of any issues with the current HOpenGL on Intel? [...] > > The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1 > (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so > I guess that this is a Mac issue. Jason converted the tutorials on a G4, so I > assume it is a problem with Mac + Intel. I don't have access to such a > platform, so some help is needed. Do any of the examples from > > http://darcs.haskell.org/packages/GLUT/examples/ > > work on your platform? > > Cheers, > S. > From coffeemug at gmail.com Fri Dec 1 17:34:07 2006 From: coffeemug at gmail.com (Vyacheslav Akhmechet) Date: Fri Dec 1 17:32:20 2006 Subject: runghc -fglasgow-exts issues Message-ID: I need to pass -fglasgow-exts to runghc. It appears that if the first flag to runghc is -f, it treats it as a path to GHC itself. So, I cannot do the following: > runghc -fglasgow-exts Test.hs because runghc failes (it says it can't find glasgow-exts). However if I do this: > runghc -fc:/ghc/bin/ghc.exe -fglasgow-exts Test.hs it works. Is this the expected behavior? I really don't want to pass full path to GHC in order to simply specify -fglasgow-exts. I could fool runghc by doing this: > runghc -v -fc:/ghc/bin/ghc.exe -fglasgow-exts Test.hs and it'll work since the first argument isn't -f, but I really don't want to do this (if I have to, what's a good argument that does nothing?). Thanks, - Slava. From trevion at gmail.com Fri Dec 1 19:00:54 2006 From: trevion at gmail.com (J. Garrett Morris) Date: Fri Dec 1 18:59:07 2006 Subject: runghc -fglasgow-exts issues In-Reply-To: References: Message-ID: <6cf91caa0612011600i735e160eg7e05a60ca4de6e8@mail.gmail.com> This is not the exact answer to your question, but if the first line of your .hs file is {-# OPTIONS_GHC -fglasgow-exts #-} then GHC extensions will be enabled within the file, whether compiled, loaded in GHCi, or run with runghc. Other compilers should ignore the pragma (unlike the older {# OPTIONS #-}) /g On 12/1/06, Vyacheslav Akhmechet wrote: > I need to pass -fglasgow-exts to runghc. It appears that if the first > flag to runghc is -f, it treats it as a path to GHC itself. So, I > cannot do the following: > > > runghc -fglasgow-exts Test.hs > > because runghc failes (it says it can't find glasgow-exts). However if > I do this: > > > runghc -fc:/ghc/bin/ghc.exe -fglasgow-exts Test.hs > > it works. Is this the expected behavior? I really don't want to pass > full path to GHC in order to simply specify -fglasgow-exts. I could > fool runghc by doing this: > > > runghc -v -fc:/ghc/bin/ghc.exe -fglasgow-exts Test.hs > > and it'll work since the first argument isn't -f, but I really don't > want to do this (if I have to, what's a good argument that does > nothing?). > > Thanks, > - Slava. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- It is myself I have never met, whose face is pasted on the underside of my mind. From dgoldsmith at mac.com Fri Dec 1 20:13:31 2006 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Fri Dec 1 20:12:06 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: <8bd57b240612011019r63ca0395j5c8a1eaf85344c23@mail.gmail.com> References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> <200612011354.40238.sven.panne@aedion.de> <8bd57b240612011019r63ca0395j5c8a1eaf85344c23@mail.gmail.com> Message-ID: I can reproduce this with ghc-6.6 built from source as well. I sampled ghc while it was stuck like this, and it looks like it's trying to open a GUI event loop (not surprising if it's opening a window). It looks like something about that is not working. Unfortunately, the Intel binary distribution on the downloads page is missing some of the OpenGL C headers, and so won't work properly either. Deborah On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: > Well, it doesn't lock the whole machine but loading Alpha3D.hs int > GHCi and typing main causes a window to be displayed with no content > and ghc 6.6 locked up, requiring a hard kill. > > On 12/1/06, Sven Panne wrote: >> Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: >> > [...] Anyone know of any issues with the current HOpenGL on >> Intel? [...] >> >> The Haskell versions of the NeHe tutorials work for me on x86_64 >> openSUSE 10.1 >> (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few >> weeks old), so >> I guess that this is a Mac issue. Jason converted the tutorials on >> a G4, so I >> assume it is a problem with Mac + Intel. I don't have access to >> such a >> platform, so some help is needed. Do any of the examples from >> >> http://darcs.haskell.org/packages/GLUT/examples/ >> >> work on your platform? >> >> Cheers, >> S. >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dgoldsmith at mac.com Fri Dec 1 21:41:30 2006 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Fri Dec 1 21:39:53 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> <200612011354.40238.sven.panne@aedion.de> <8bd57b240612011019r63ca0395j5c8a1eaf85344c23@mail.gmail.com> Message-ID: <48C8BF10-7A8B-4C32-A295-A9F3F4E5DBBF@mac.com> This also fails in Hugs (crashes rather than hangs), so it looks like it's a problem with the GLUT binding on Mac OS X Intel rather than something specific to GHC. I'll see if I can find a PPC machine to try it on also. Deborah On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: > I can reproduce this with ghc-6.6 built from source as well. I > sampled ghc while it was stuck like this, and it looks like it's > trying to open a GUI event loop (not surprising if it's opening a > window). It looks like something about that is not working. > > Unfortunately, the Intel binary distribution on the downloads page > is missing some of the OpenGL C headers, and so won't work properly > either. > > Deborah > > On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: > >> Well, it doesn't lock the whole machine but loading Alpha3D.hs int >> GHCi and typing main causes a window to be displayed with no content >> and ghc 6.6 locked up, requiring a hard kill. >> >> On 12/1/06, Sven Panne wrote: >>> Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: >>> > [...] Anyone know of any issues with the current HOpenGL on >>> Intel? [...] >>> >>> The Haskell versions of the NeHe tutorials work for me on x86_64 >>> openSUSE 10.1 >>> (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few >>> weeks old), so >>> I guess that this is a Mac issue. Jason converted the tutorials >>> on a G4, so I >>> assume it is a problem with Mac + Intel. I don't have access to >>> such a >>> platform, so some help is needed. Do any of the examples from >>> >>> http://darcs.haskell.org/packages/GLUT/examples/ >>> >>> work on your platform? >>> >>> Cheers, >>> S. >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dgoldsmith at mac.com Fri Dec 1 21:49:16 2006 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Fri Dec 1 21:47:39 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: <48C8BF10-7A8B-4C32-A295-A9F3F4E5DBBF@mac.com> References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> <200612011354.40238.sven.panne@aedion.de> <8bd57b240612011019r63ca0395j5c8a1eaf85344c23@mail.gmail.com> <48C8BF10-7A8B-4C32-A295-A9F3F4E5DBBF@mac.com> Message-ID: It fails on PowerPC too, using the standard PPC distribution. Deborah On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote: > This also fails in Hugs (crashes rather than hangs), so it looks > like it's a problem with the GLUT binding on Mac OS X Intel rather > than something specific to GHC. I'll see if I can find a PPC > machine to try it on also. > > Deborah > > On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: > >> I can reproduce this with ghc-6.6 built from source as well. I >> sampled ghc while it was stuck like this, and it looks like it's >> trying to open a GUI event loop (not surprising if it's opening a >> window). It looks like something about that is not working. >> >> Unfortunately, the Intel binary distribution on the downloads page >> is missing some of the OpenGL C headers, and so won't work >> properly either. >> >> Deborah >> >> On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: >> >>> Well, it doesn't lock the whole machine but loading Alpha3D.hs int >>> GHCi and typing main causes a window to be displayed with no content >>> and ghc 6.6 locked up, requiring a hard kill. >>> >>> On 12/1/06, Sven Panne wrote: >>>> Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: >>>> > [...] Anyone know of any issues with the current HOpenGL on >>>> Intel? [...] >>>> >>>> The Haskell versions of the NeHe tutorials work for me on x86_64 >>>> openSUSE 10.1 >>>> (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few >>>> weeks old), so >>>> I guess that this is a Mac issue. Jason converted the tutorials >>>> on a G4, so I >>>> assume it is a problem with Mac + Intel. I don't have access to >>>> such a >>>> platform, so some help is needed. Do any of the examples from >>>> >>>> http://darcs.haskell.org/packages/GLUT/examples/ >>>> >>>> work on your platform? >>>> >>>> Cheers, >>>> S. >>>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dgoldsmith at mac.com Sat Dec 2 02:52:20 2006 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Sat Dec 2 02:51:09 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> <200612011354.40238.sven.panne@aedion.de> <8bd57b240612011019r63ca0395j5c8a1eaf85344c23@mail.gmail.com> <48C8BF10-7A8B-4C32-A295-A9F3F4E5DBBF@mac.com> Message-ID: I can get this to work if I compile it with ghc, rather than try to run it with ghci or hugs. ghc --make Alpha3D.hs ./Alpha3D works fine with no hangs. Deborah On Dec 1, 2006, at 6:49 PM, Deborah Goldsmith wrote: > It fails on PowerPC too, using the standard PPC distribution. > > Deborah > > On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote: > >> This also fails in Hugs (crashes rather than hangs), so it looks >> like it's a problem with the GLUT binding on Mac OS X Intel rather >> than something specific to GHC. I'll see if I can find a PPC >> machine to try it on also. >> >> Deborah >> >> On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: >> >>> I can reproduce this with ghc-6.6 built from source as well. I >>> sampled ghc while it was stuck like this, and it looks like it's >>> trying to open a GUI event loop (not surprising if it's opening a >>> window). It looks like something about that is not working. >>> >>> Unfortunately, the Intel binary distribution on the downloads >>> page is missing some of the OpenGL C headers, and so won't work >>> properly either. >>> >>> Deborah >>> >>> On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: >>> >>>> Well, it doesn't lock the whole machine but loading Alpha3D.hs int >>>> GHCi and typing main causes a window to be displayed with no >>>> content >>>> and ghc 6.6 locked up, requiring a hard kill. >>>> >>>> On 12/1/06, Sven Panne wrote: >>>>> Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: >>>>> > [...] Anyone know of any issues with the current HOpenGL on >>>>> Intel? [...] >>>>> >>>>> The Haskell versions of the NeHe tutorials work for me on >>>>> x86_64 openSUSE 10.1 >>>>> (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few >>>>> weeks old), so >>>>> I guess that this is a Mac issue. Jason converted the tutorials >>>>> on a G4, so I >>>>> assume it is a problem with Mac + Intel. I don't have access to >>>>> such a >>>>> platform, so some help is needed. Do any of the examples from >>>>> >>>>> http://darcs.haskell.org/packages/GLUT/examples/ >>>>> >>>>> work on your platform? >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users@haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mechvel at botik.ru Sat Dec 2 06:53:25 2006 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Dec 2 06:51:44 2006 Subject: OPTIONS_GHC -auto-all Message-ID: <20061202115325.GA1202@scico.botik.ru> Dear GHC developers, Can you, please tell me how to add -prof -auto-all as dynamic option for a chosen source module? This is in ghc-6.6. I `make' my large program (of many modules) via Cabal, under -prof. The Main module contains the test example main. `main' calls for LemmaSearch.searchLemmataInInitial. And I set {-# SCC ... #-} in several places in the module LemmaSearch.hs. `Main' is also built under -prof and run under +RTS -p -RTS. Still it occurs difficult to find from *.prof who namely takes most of time. So, I try to add -auto-all -- but only for the module LemmaSearch, because the cost centers of other modules will show a great inherited cost and thus, make a confusion. I am doing this by adding the line {-# OPTIONS_GHC -fglasgow-ext -prof -auto-all #-} (the syntax is by Users Guide) before the line module LemmaSearch in the source module, and command, again, make buld. It reports runhaskell Setup.hs build Preprocessing library dumatel-1.6... Building dumatel-1.6... LemmaSearch.hs: unknown flags in {-# OPTIONS #-} pragma: -fglasgow-ext -prof -auto-all make: *** [build] Error 1 Everything except -auto-all, is already inside `make'. But GHC rejects all variants of this my option, and with quoted "auto-all" too. Who can advice please? Thank you in advance for help, ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Sat Dec 2 10:27:50 2006 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Dec 2 10:26:29 2006 Subject: difficult profiling example Message-ID: <20061202152750.GA1964@scico.botik.ru> Dear GHC developers, dear users, I am starting to doubt in the GHC time profiling. Why can advise, please, on the following example? This is important for me: I need to find who eats time in this particular example. This is for ghc-6.6. I `make' my large program (of many modules) via Cabal, with -O -prof and -enable-profiling included. The Main module contains the test example main. `main' calls for LemmaSearch.searchLemmataInInitial. `Main' is also built under -prof and run under +RTS -p -RTS. I set the cost centers only inside LemmaSearch.hs. And I set {-# SCC ... #-} in all valuable places in the module LemmaSearch.hs, I skip only the places where a data field is extracted/set, or such. (I would like to set -auto-all for the module LemmaSearch.hs only, but GHC does not accept the pragma {-# OPTIONS_GHC auto-all #-}, I wonder, why ). The .prof file shows ---------------------------------------- ... COST CENTRE MODULE %time %alloc searchLemmata LemmaSearch 91.9 93.2 splitDisjunctScheme LemmaSearch 3.9 3.0 addEquationsWithReduction LemmaSearch 3.7 3.3 individual inherited COST CENTRE MODULE ... ---------------------------------------- searchLemmata is the main loop inside searchLemmataInInitial where everything happens, and splitDisjunctScheme, addEquationsWithReduction are called from this loop. It looks correct that searchLemmata costs 90%. I could believe that splitDisjunctScheme and addEquationsWithReduction take together about 8% of what searchLemma costs. But who inside the searchLemmata loop takes the rest of (90 - 8)% ? I do not see this, because all other parts (about 15 of centers) are shown in profiling as close to zero %. The centers for the imported functions are set before each their envocation in this module. The centers for the functions from this module are set before their first defining statement, and they are all defined in the style of ``f = ...'', with single equality at top. I append below the module LemmaSearch.hs (with comments skipped) and the .prof file. (Does this 770 line letter damage the ghc-users list? I am sorry, if it does). If the GHC team asks for the whole example source and provides me with a private address for this, then I would send the source archive of the project. Thank you in advance for help, ----------------- Serge Mechveliani mechvel@botik.ru -------------------------------------------------------------------- module LemmaSearch (searchLemmataInInitial) where import qualified Data.Set as Set ... import qualified Data.Map as Map ... import Char (isDigit) import List (genericLength, nub, (\\), insertBy) import Ratio (numerator, denominator) import Dumatel.Prelude ... ... import ... root :: Natural -> Natural -> Natural root n = {-# SCC "root" #-} fst . intRoot n type ExtLemmataSearchState = ((LemmataSearchState, [Disjunct]), Resource) searchLemmataInInitial :: ProverOptions -> -- proverOpts Resource -> -- rc Resource -> -- rcPerLemma PreferableOrOrdinary -> -- pref LemmataSearchState -> -- searchState ExtLemmataSearchState searchLemmataInInitial proverOpts rc rcPerLemma pref searchState = (let ((state', newProveds), rcRem) = searchLemmata ((searchState, []), rc) cost = lsisCost searchState in ((state' {lsisCost = cost + rc - rcRem}, newProveds), rcRem) ) where message0 = showString "\nsearchLemmataInInitial " . showString "(skolParam, superpty, jump, lsearchParams)\n " . shows rc . showChar ' ' . shows rcPerLemma . showChar ' ' . shows pref . showString " searchState,\n" . showString "lsisVariables = " . shows (lsisVariables searchState) . showChar '\n' . showString "lsisOperators =\n " . shows (map name ordOps) . showChar '\n' (superpty, jump, umrBounds, lsearchParams) = (provOptSupty proverOpts, provOptRdJump proverOpts, provOptUMRMemoBounds proverOpts, provOptLSIParams proverOpts ) (_, mBounds, rKeyBound) = umrBounds mrBounds = (mBounds, rKeyBound) rcForDisproof = quot rcPerLemma 2 rcForProof = 0 calculusEquationsSize = genericLength . equationList testRangePerVariable = lsipTestRangePerVariable lsearchParams depthBoundForGroundSubst = lsipDepthBoundForGroundSubst lsearchParams ordOps = lsisOperators searchState isFalseTerm t = case t of VarT _ -> False App o _ -> name o == "false" isTrivialFormula f = case f of VarT _ -> False App o _ -> name o == "true" || name o == "false" addFormula :: Calculus -> Formula -> Calculus addFormula calc f = {-# SCC "addFormula" #-} let memo = (Map.empty, Map.empty, Map.empty) in tuple41 $ addFormulae mrBounds memo jump calc SkolemizeNot Ordinary superpty [f] allSorts = Map.keys $ snd $ sortIdTabs $ lsisCalculus searchState ---------------------------------------------------------------------- searchLemmata extState@ ((searchState, newProveds), rc) = {-# SCC "searchLemmata" #-} let umMemo = lsisUnifMatchMemo searchState (uMemo, mMemo) = umMemo store = lsisStore searchState disproveds = lsiDisproved store passedCps = lsiPassedCompletion store sMulty = lsiMultiplicity store in (case splitCs of [] -> extState (((calc', lastName, newVars, preeqs), dj, _), djCost) : splitCs' -> if rc < minRc then extState else case (findMatchEquivalentIn2tables mBounds (uMemo, mMemo) (opTab calc') (fst passedCps) (fst disproveds) dj, {-# SCC "opVarMulKind" #-} opVarMulKind dj, -- djOVKind {-# SCC "nonSchemeOpVarMultisets" #-} nonSchemeOpVarMultisets isSchemeOperator dj -- djOVMS ) of ((mMemo2, Just dj', searchCost1), _, _) -> let state' = searchState {lsisDSplits = splitCs', lsisStore = sStore {lsiMultiplicity = succ sMulty}, lsisUnifMatchMemo = (uMemo, mMemo2) } rc' = rc - djCost - searchCost1 in searchLemmata ((state', newProveds), rc') ((mMemo2, _, searchCost1), djOVKind, djOVMS) -> case findSchemeEquivalentTermIn2tables mrBounds (uMemo, mMemo2) isSchemeOperator calc' (snd passedCps) (snd disproveds) dj djOVMS of (Just dj', searchCost2) -> let state' = searchState {lsisDSplits = splitCs', lsisStore = sStore {lsiMultiplicity = succ sMulty}, lsisUnifMatchMemo = (uMemo, mMemo2) } rc' = rc - djCost - searchCost1 - searchCost2 in searchLemmata ((state', newProveds), rc') (_, searchCost2) -> let (matchRes, matchCost) = {-# SCC "matchAnySubdisjunctSchemeInList" #-} matchAnySubdisjunctSchemeInList mrBounds (uMemo, mMemo2) isSchemeOperator calc' (filter hasScheme disprovedsL) dj rc' = rc - djCost - searchCost1 - searchCost2 - matchCost in case matchRes of Just (dj', litSubset, _rCalc) -> let state' = searchState {lsisDSplits = splitCs', lsisStore = sStore {lsiMultiplicity = succ sMulty}, lsisUnifMatchMemo = (uMemo, mMemo2)} in searchLemmata ((state', newProveds), rc') _ -> case {-# SCC "matchAnySubdisjunctInList" #-} matchAnySubdisjunctInList mBounds (uMemo, mMemo2) (opTab calc') disprovedsL dj of (mMemo3, Just (dj', subD, _), matchCost) -> let state' = searchState {lsisDSplits = splitCs', lsisStore = sStore {lsiMultiplicity = succ sMulty}, lsisUnifMatchMemo = (uMemo, mMemo3)} in searchLemmata ((state', newProveds), rc' - matchCost) (mMemo3, _, matchCost) -> let (disprovedByTilde, ukbbRes, rcRem) = -- {-# "disproveStatement" #-} disproveStatement calc' rcForDisproof dj rcAfterDispr = rc' - matchCost - rcForDisproof + rcRem disprovedByCompl = ukbbGoalRem ukbbRes == ([], []) (complEqs, _, complBTs) = ukbbCompl ukbbRes calc'1 = calc' (calc'', addCost) = let umrMemo = (uMemo, mMemo3, Map.empty) (_, cc, c1) = {-# SCC "addEquationsWithReduction" #-} addEquationsWithReduction mrBounds umrMemo jump calc'1 complEqs in mapTuple22 (+ c1) $ {-# SCC "addBTLawsWithReduction" #-} addBTLawsWithReduction mrBounds umrMemo jump cc complBTs calc''scTopOrNonSc = setEquations calc'' [e | e <- equationList calc'', not $ hasScheme e || isSchemeTopEq e ] [] (_, dj', djRdCost) = {-# SCC "reduceDisjunct" #-} reduceDisjunct mrBounds (uMemo, mMemo, Map.empty) jump calc''scTopOrNonSc dj rcAfterRd = rcAfterDispr - djRdCost - addCost djSchemeOps = Set.toList $ schemeOperators dj in if disprovedByTilde then let disps' = insertToMapListPair djOVKind djOVMS dj disproveds state' = searchState {lsisDSplits = splitCs', lsisStore = sStore {lsiDisproved = disps'}, lsisUnifMatchMemo = (uMemo, mMemo3)} in searchLemmata ((state', newProveds), rcAfterDispr) else if disprovedByCompl then let disps' = insertToMapListPair djOVKind djOVMS dj disproveds state' = searchState {lsisDSplits = splitCs', lsisUnifMatchMemo = (uMemo, mMemo3), lsisStore = sStore {lsiDisproved = disps', lsiPassedTilde = Set.insert dj passedTildes}} in searchLemmata ((state', newProveds), rcAfterDispr) else if (not $ null djSchemeOps) && dj /= dj' then let dj'sp = {-# SCC "dj'sp" #-} (((calc'', lastName, newVars, preeqs), dj', termSplitMeasure isSchemeOperator dj'), 0) splitCs'' = {-# SCC "splitCs''" #-} if isTrivialFormula dj' then splitCs' else insertBy (\ (s, _) (s', _) -> compareTermSplitsByMeasure s s' ) dj'sp splitCs' passedCps' = insertToMapListPair djOVKind djOVMS dj passedCps state' = searchState {lsisDSplits = splitCs'', lsisUnifMatchMemo = (uMemo, mMemo3), lsisStore = sStore {lsiPassedCompletion = passedCps', lsiPassedTilde = Set.insert dj passedTildes, lsiHasReduced = Set.insert dj reduceds} } in searchLemmata ((state', newProveds), rcAfterRd) else if not $ null djSchemeOps then let (splitCs0, _splitStatistic) = {-# SCC "splitDisjunctScheme" #-} splitDisjunctScheme mrBounds umMemo ordOps calc'' jump lastName dj djSchemeOps splitCs'' = {-# SCC "splitCs''" #-} map (\ ((osp, dis, meas), c) -> ((mapTuple44 (++ preeqs) osp, dis, meas), c) ) $ filter (\ ((_, d, _), _) -> d /= dj) splitCs0 passedCps' = insertToMapListPair djOVKind djOVMS dj passedCps state' = searchState {lsisUnifMatchMemo = (uMemo, mMemo3), lsisDSplits = {-# SCC "lsisDSplits = ..mergeBy.." #-} mergeBy (\ (s, _) (s', _) -> compareTermSplitsByMeasure s s' ) splitCs' splitCs'', lsisStore = sStore {lsiPassedCompletion = passedCps', lsiPassedTilde = Set.insert dj passedTildes}} in searchLemmata ((state', newProveds), rcAfterRd) else let lemParamsForProof = lsearchParams {lsipFactor = 0, lsipExponent = 0} opts' = proverOpts {provOptLSIParams = lemParamsForProof} (proved, _, rcRem) = proveStatementInInitial opts' rcForProof dj rc' = rcAfterDispr - rcForProof + rcRem in if not proved then let passedCps' = insertToMapListPair djOVKind djOVMS dj passedCps state' = searchState {lsisDSplits = splitCs', lsisUnifMatchMemo = (uMemo, mMemo3), lsisStore = sStore {lsiPassedCompletion = passedCps', lsiPassedTilde = Set.insert dj passedTildes} } in searchLemmata ((state', newProveds), rc') else let passedCps' = insertToMapListPair djOVKind djOVMS dj passedCps state' = searchState {lsisDSplits = map addStatement splitCs', lsisUnifMatchMemo = (uMemo, mMemo3), lsisStore = sStore {lsiPassedTilde = Set.insert dj passedTildes, lsiPassedCompletion = passedCps', lsiProved = Set.insert dj proveds} } addStatement ((osp, d, m), c) = {-# SCC "addStatement" #-} ((mapTuple41 (\ calc -> addF calc dj) osp, d, m), c) addF calc = addFormula calc . closeFormula calc in searchLemmata ((state', dj : newProveds), rc') ) where calc0 = lsisCalculus searchState sStore = lsisStore searchState splitCs = lsisDSplits searchState calc0ops = operators calc0 minRc = calculusEquationsSize calc0 isSchemeOperator f = {-# SCC "isSchemeOperator" #-} (not $ Set.member f calc0ops) && (isScName $ name f) isScName nm = case nm of 's': 'c': nm' -> all isDigit nm' _ -> False schemeOperators :: WithOperatorSet a => a -> Set.Set Operator schemeOperators = {-# SCC "schemeOperators" #-} Set.filter isSchemeOperator . operators hasScheme :: WithOperatorSet a => a -> Bool hasScheme = {-# SCC "hasScheme" #-} not . Set.null . schemeOperators isSchemeTopEq e = {-# SCC "isSchemeTopEq" #-} any isSTop [l, r] where (l, r) = sides e isSTop t = (not $ isVariable t) && (not $ Set.member (topOperator t) calc0ops) disproveds = lsiDisproved sStore passedTildes = lsiPassedTilde sStore passedCps = lsiPassedCompletion sStore reduceds = lsiHasReduced sStore proveds = lsiProved sStore disprovedsL = {-# SCC "disprovedsL" #-} concat $ Map.elems $ fst disproveds opsForSubst = {-# SCC "opsForSubst" #-} (extraRelatedConstants calc0 ordOps) ++ ordOps where extraRelatedConstants calc ops = (concat $ map contantsOfSort relatedSorts) \\ ops where calcConsts = filter isConstantOperator $ Set.toList $ operators calc relatedSorts = Set.toList $ sUnion $ map sortageUnion ops contantsOfSort s = filter ((s ==) . coarity) calcConsts sortageUnion f = let ((lsorts, rsorts), cosort) = sortage f in Set.insert cosort $ sUnion [Set.fromList lsorts, Set.fromList rsorts] -------------------------------------------------------------------- disproveStatement :: Calculus -> Resource -> Disjunct -> (Bool, UKBBResult, Resource) disproveStatement calcExt rc dj = {-# SCC "disproveStatement" #-} (if disprovedByTilde then (True, dummy "dummy complRes in disproveStatement", rcAfterTilde) else (False, ukbbRes, rcAfterCompl) ) where testingSubsts = groundSubstsForTest $ Set.toList $ vars dj (tildePairsPassed, tildePairsRest) = let memo = (Map.empty, Map.empty, Map.empty) in span (not . isFalseTerm . fst) [(dj', c) | sb <- testingSubsts, let (_, dj', c) = reduceDisjunct mrBounds memo jump calcExt $ substitute sb dj] disprovedByTilde = not $ null tildePairsRest tildeCost = succ $ sum $ map snd tildePairsPassed rcAfterTilde = rc - tildeCost rcCompl = 0 refutRes = let uMtMemo = (Map.empty, Map.empty) in refuteFormulaSetByCompletion TraceNot umrBounds uMtMemo jump (Fin rcCompl) (Fin rcCompl) 0 SkolemizeNot Preferable superpty calcExt [closeFormula calcExt dj] ukbbRes = cpRefInitialCompletion refutRes Fin complRcRem = cpRefRcRem refutRes rcAfterCompl = rcAfterTilde - rcCompl + complRcRem groundSubstsForTest xs = (if null opsForSubst || null xs then [identitySubstitution] else gsubsForTest xs testRangePerVariable ) where varSorts = nub $ map sort xs varDomains = Map.fromList [(s, varDomain calc0 s) | s <- varSorts] gsubsForTest xs range = case xs of [] -> [] [x] -> map (Map.singleton x) $ takeTermsFromTermsOfSort range depthBoundForGroundSubst (varDomain calc0 $ sort x) x: ys -> case Map.lookup (sort x) varDomains of Nothing -> error $ concat ["\ndisproveStatement calcExt ", shows rc "\n ", shows dj "\n...", "gsubsForTest ", shows xs " ", shows range "\n...Impossible happened:\n", "Map.lookup (sort x) varDomains failed for x = ", shows x ".\n" ] Just vd -> case takeTermsFromTermsOfSort range depthBoundForGroundSubst vd of [] -> [] vals -> [Map.insert x v sb | sb <- sbs', v <- vals] where cardVals = genericLength vals sbs' = gsubsForTest ys (2*range - cardVals) varDomain :: Calculus -> Sort -> TermsOfSort varDomain calc s = (case Map.lookup s nts of Just v -> v _ -> Map.empty ) where nts = let umMemo = (Map.empty, Map.empty) in termSetUpToLevel (not . reducesAtTop mBounds umMemo calc) allSorts [] opsForGround depthBoundForGroundSubst opsForGround = sgens ++ (opsForSubst \\ sgens) -- move generators of s ahead sgens = concat $ sortGeneratorLists (sortGenTab calc) s -------------------------------------------------------------------- proveStatementInInitial :: ProverOptions-> Resource-> Disjunct-> (Bool, Inference, Resource) proveStatementInInitial proverOpts rc dj = {-# SCC "proveStatementInInitial" #-} (isProved $ psStateTree inferState, reduceInference inference, rc - inferenceCost) where goal = Prove {goalCalculus = calc0, goalFormula = closeFormula calc0 dj, goalMode = InInitial } state0 = proofSearchStateFromGoal umrBounds superpty jump rc goal p = lsipExponent lsearchParams (n, m) = (numerator p, denominator p) rcPerStepInLemma = if p == 0 then 1 else if p == 1 then rc else (root m rc)^n inferenceBound = rc inference = takeUpToBound inferenceBound $ prove proverOpts rcPerStepInLemma state0 inferState = last inference inferenceCost = rcPerStepInLemma * (genericLength inference) takeUpToBound :: Natural -> Inference -> Inference takeUpToBound bound inference = tk 0 inference where tk _ [] = [] tk volume (state: states) = if volume > bound then [] else state : (tk (volume + (inferenceVolume [state])) states) ------------------------------------------------------------------------ insertToMapListPair :: -- local (Ord key1, Ord key2) => key1 -> key2 -> v -> (Map.Map key1 [v], Map.Map key2 [v]) -> (Map.Map key1 [v], Map.Map key2 [v]) insertToMapListPair key1 key2 v (map1, map2) = {-# SCC "insertToMapListPair" #-} (Map.insertWith (++) key1 [v] map1, Map.insertWith (++) key2 [v] map2) findMatchEquivalentIn2tables mBounds (uMemo, mMemo) otab tab1 tab2 dj = -- local {-# SCC "findMatchEquivalentIn2tables" #-} (case find1 0 mMemo tab1 of (mMemo', Nothing, cost) -> find1 cost mMemo' tab2 triple -> triple ) where ovKind = opVarMulKind dj find1 cost mMemo tab = case Map.lookup ovKind tab of Nothing -> (mMemo, Nothing, cost) Just listOfKey -> mapTuple33 (+ cost) $ findMatchEquivalent mBounds (uMemo, mMemo) otab listOfKey dj findSchemeEquivalentTermIn2tables -- local mrBounds umMemo isSchemeOperator calc tab1 tab2 t key = {-# SCC "findSchemeEquivalentTermIn2tables" #-} (case find1 0 tab1 of (Nothing, cost) -> find1 cost tab2 pair -> pair ) where find1 cost tab = case Map.lookup key tab of Nothing -> (Nothing, cost) Just ts -> mapTuple22 (+ cost) $ findSchemeEquivalentTerm mrBounds umMemo isSchemeOperator calc ts t -------------------------------------------------------------------------- Sat Dec 2 17:18 2006 Time and Allocation Profiling Report (Final) LemSearchList +RTS -M200m -p -RTS total time = 268.25 secs (5365 ticks @ 50 ms) total alloc = 9,796,199,364 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc searchLemmata LemmaSearch 91.9 93.2 splitDisjunctScheme LemmaSearch 3.9 3.0 addEquationsWithReduction LemmaSearch 3.7 3.3 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 1 0 0.0 0.0 100.0 100.0 CAF Main 280 66 0.0 0.0 100.0 100.0 disprovedsL LemmaSearch 295 1 0.0 0.0 0.0 0.0 opsForSubst LemmaSearch 290 1 0.0 0.0 0.0 0.0 hasScheme LemmaSearch 289 0 0.0 0.0 0.0 0.0 isSchemeOperator LemmaSearch 288 0 0.0 0.0 0.0 0.0 addFormula LemmaSearch 287 0 0.0 0.0 0.0 0.0 searchLemmata LemmaSearch 286 3143 91.9 93.2 100.0 99.9 root LemmaSearch 315 8 0.0 0.0 0.0 0.0 disprovedsL LemmaSearch 314 303 0.0 0.0 0.0 0.0 opVarMulKind LemmaSearch 312 128 0.0 0.0 0.0 0.0 opsForSubst LemmaSearch 311 128 0.1 0.0 0.1 0.0 isSchemeOperator LemmaSearch 310 23738 0.0 0.0 0.0 0.0 lsisDSplits = ..mergeBy.. LemmaSearch 309 89 0.0 0.0 0.0 0.0 splitCs'' LemmaSearch 308 841 0.0 0.0 0.0 0.0 splitDisjunctScheme LemmaSearch 307 89 3.9 3.0 3.9 3.0 isSchemeTopEq LemmaSearch 306 2670 0.0 0.0 0.0 0.0 hasScheme LemmaSearch 303 7275 0.0 0.0 0.0 0.0 schemeOperators LemmaSearch 304 7275 0.0 0.0 0.0 0.0 isSchemeOperator LemmaSearch 305 82 0.0 0.0 0.0 0.0 addBTLawsWithReduction LemmaSearch 302 89 0.0 0.0 0.0 0.0 addEquationsWithReduction LemmaSearch 301 89 3.7 3.3 3.7 3.3 schemeOperators LemmaSearch 299 97 0.0 0.0 0.0 0.0 isSchemeOperator LemmaSearch 300 3 0.0 0.0 0.0 0.0 reduceDisjunct LemmaSearch 298 267 0.1 0.1 0.1 0.1 disproveStatement LemmaSearch 297 129 0.0 0.0 0.0 0.0 matchAnySubdisjunctInList LemmaSearch 296 190 0.2 0.2 0.2 0.2 matchAnySubdisjunctSchemeInList LemmaSearch 294 304 0.0 0.0 0.0 0.0 findSchemeEquivalentTermIn2tables LemmaSearch 293 343 0.0 0.0 0.0 0.0 nonSchemeOpVarMultisets LemmaSearch 292 343 0.0 0.0 0.0 0.0 isSchemeOperator LemmaSearch 313 3 0.0 0.0 0.0 0.0 findMatchEquivalentIn2tables LemmaSearch 291 664 0.0 0.1 0.0 0.1 CAF Text.Read.Lex 257 14 0.0 0.0 0.0 0.0 CAF GHC.Real 254 1 0.0 0.0 0.0 0.0 CAF GHC.Read 251 2 0.0 0.0 0.0 0.0 CAF GHC.Handle 233 3 0.0 0.0 0.0 0.0 CAF BTerm0 192 1 0.0 0.0 0.0 0.0 CAF Unify 191 5 0.0 0.0 0.0 0.0 CAF Parse1 190 4 0.0 0.0 0.0 0.0 CAF Prelude4 189 5 0.0 0.0 0.0 0.0 CAF Prelude3_1 188 7 0.0 0.0 0.0 0.0 CAF Prelude3_0 187 2 0.0 0.0 0.0 0.0 CAF Prelude3 186 8 0.0 0.0 0.0 0.0 CAF Prelude2_0 185 6 0.0 0.0 0.0 0.0 CAF Prelude2 184 1 0.0 0.0 0.0 0.0 CAF Prelude1 183 2 0.0 0.0 0.0 0.0 CAF Prelude00 168 1 0.0 0.0 0.0 0.0 CAF Dumatel.Reduce 166 1 0.0 0.0 0.0 0.0 CAF Split 165 7 0.0 0.0 0.0 0.0 CAF Bool0 163 55 0.0 0.0 0.0 0.0 CAF Parse2 162 5 0.0 0.0 0.0 0.0 CAF LemmaSearch 156 1 0.0 0.0 0.0 0.0 CAF Prover1 154 1 0.0 0.0 0.0 0.0 CAF Prover00 153 6 0.0 0.0 0.0 0.0 CAF Dumatel.Prelude5 152 1 0.0 0.0 0.0 0.0 CAF Dumatel.BTerm 151 2 0.0 0.0 0.0 0.0 CAF UKBB0 147 1 0.0 0.0 0.0 0.0 From darkdescendant at gmail.com Sat Dec 2 12:23:09 2006 From: darkdescendant at gmail.com (Joe Jones) Date: Sat Dec 2 12:21:21 2006 Subject: OpengGL lockup using GHC 6.6 on Intel Mac In-Reply-To: References: <8bd57b240611291029r65093fa7nf9299310874365ff@mail.gmail.com> <200612011354.40238.sven.panne@aedion.de> <8bd57b240612011019r63ca0395j5c8a1eaf85344c23@mail.gmail.com> <48C8BF10-7A8B-4C32-A295-A9F3F4E5DBBF@mac.com> Message-ID: <8bd57b240612020923ie67ddb7obbd6bb5ca9c53ba2@mail.gmail.com> Yep, that works well. Thanx! On 12/1/06, Deborah Goldsmith wrote: > I can get this to work if I compile it with ghc, rather than try to > run it with ghci or hugs. > > ghc --make Alpha3D.hs > ./Alpha3D > > works fine with no hangs. > > Deborah > > On Dec 1, 2006, at 6:49 PM, Deborah Goldsmith wrote: > > > It fails on PowerPC too, using the standard PPC distribution. > > > > Deborah > > > > On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote: > > > >> This also fails in Hugs (crashes rather than hangs), so it looks > >> like it's a problem with the GLUT binding on Mac OS X Intel rather > >> than something specific to GHC. I'll see if I can find a PPC > >> machine to try it on also. > >> > >> Deborah > >> > >> On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote: > >> > >>> I can reproduce this with ghc-6.6 built from source as well. I > >>> sampled ghc while it was stuck like this, and it looks like it's > >>> trying to open a GUI event loop (not surprising if it's opening a > >>> window). It looks like something about that is not working. > >>> > >>> Unfortunately, the Intel binary distribution on the downloads > >>> page is missing some of the OpenGL C headers, and so won't work > >>> properly either. > >>> > >>> Deborah > >>> > >>> On Dec 1, 2006, at 10:19 AM, Joe Jones wrote: > >>> > >>>> Well, it doesn't lock the whole machine but loading Alpha3D.hs int > >>>> GHCi and typing main causes a window to be displayed with no > >>>> content > >>>> and ghc 6.6 locked up, requiring a hard kill. > >>>> > >>>> On 12/1/06, Sven Panne wrote: > >>>>> Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones: > >>>>> > [...] Anyone know of any issues with the current HOpenGL on > >>>>> Intel? [...] > >>>>> > >>>>> The Haskell versions of the NeHe tutorials work for me on > >>>>> x86_64 openSUSE 10.1 > >>>>> (GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few > >>>>> weeks old), so > >>>>> I guess that this is a Mac issue. Jason converted the tutorials > >>>>> on a G4, so I > >>>>> assume it is a problem with Mac + Intel. I don't have access to > >>>>> such a > >>>>> platform, so some help is needed. Do any of the examples from > >>>>> > >>>>> http://darcs.haskell.org/packages/GLUT/examples/ > >>>>> > >>>>> work on your platform? > >>>>> > >>>>> Cheers, > >>>>> S. > >>>>> > >>>> _______________________________________________ > >>>> Glasgow-haskell-users mailing list > >>>> Glasgow-haskell-users@haskell.org > >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >>> > >>> _______________________________________________ > >>> Glasgow-haskell-users mailing list > >>> Glasgow-haskell-users@haskell.org > >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >> > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users@haskell.org > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From simonpj at microsoft.com Sat Dec 2 18:02:28 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sat Dec 2 18:01:43 2006 Subject: bang patterns give fundamentally new capabilities? In-Reply-To: <20061201041313.GF6726@momenergy.repetae.net> Message-ID: | I was recently presented with the problem of writing a function like so | | seqInt__ :: forall a . a -> Int# -> Int# | seqInt__ x y = x `seq` y | | which seems fine, except 'seq' of type forall a b . a -> b -> b cannot | be applied to an unboxed value. Actually it works fine. Did you try it? Seq is special because its second type argument can be instantiated to an unboxed type. I see that is not documented in the user manual; it should be. GHC has a kinding system that looks quite similar to the one you described for jhc. Here's teh comment from compiler/Type.lhs ? / \ / \ ?? (#) / \ * # where * [LiftedTypeKind] means boxed type # [UnliftedTypeKind] means unboxed type (#) [UbxTupleKind] means unboxed tuple ?? [ArgTypeKind] is the lub of *,# ? [OpenTypeKind] means any type at all | Also, is there a way to do something similar but for 'lazy' rather than | 'seq'? I want something of type | | type World__ = State# RealWorld | | {-# NOINLINE newWorld__ #-} | newWorld__ :: a -> World__ | newWorld__ x = realWord# -- ??? | | except that I need newWorld__ to be lazy in its first argument. I need | to convince the opimizer that the World__ newWorld__ is returning | depends on the argument passed to newWorld__. I don't understand what you meant here. The definition of newWorld__ that you give is, of course, lazy in x. Simon From dons at cse.unsw.edu.au Sun Dec 3 02:52:03 2006 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sun Dec 3 02:50:16 2006 Subject: Building GHC quickly Message-ID: <20061203075203.GA9731@cse.unsw.EDU.AU> Had a go today building GHC on a multcore linux box, with -j, just to see how fast it would go. Summary: you can build GHC from scratch in less than 10 minutes these days! More details here: http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/03#build_ghc_fast -- Don From john at repetae.net Sun Dec 3 18:00:23 2006 From: john at repetae.net (John Meacham) Date: Sun Dec 3 17:58:03 2006 Subject: bang patterns give fundamentally new capabilities? In-Reply-To: References: <20061201041313.GF6726@momenergy.repetae.net> Message-ID: <20061203230023.GD8493@momenergy.repetae.net> On Sat, Dec 02, 2006 at 11:02:28PM +0000, Simon Peyton-Jones wrote: > | I was recently presented with the problem of writing a function like so > | > | seqInt__ :: forall a . a -> Int# -> Int# > | seqInt__ x y = x `seq` y > | > | which seems fine, except 'seq' of type forall a b . a -> b -> b cannot > | be applied to an unboxed value. > > Actually it works fine. Did you try it? Seq is special because its second type argument can be instantiated to an unboxed type. I see that is not documented in the user manual; it should be. I was getting this problem, http://hackage.haskell.org/trac/ghc/ticket/1031 I assumed it was because I was passing an unboxed value to seq because when I switched them all to bang patterns, it started to work. but I guess it was a different issue alltogether. > > GHC has a kinding system that looks quite similar to the one you described for jhc. Here's teh > comment from compiler/Type.lhs > > ? > / \ > / \ > ?? (#) > / \ > * # > > where * [LiftedTypeKind] means boxed type > # [UnliftedTypeKind] means unboxed type > (#) [UbxTupleKind] means unboxed tuple > ?? [ArgTypeKind] is the lub of *,# > ? [OpenTypeKind] means any type at all yup. certainly not an accident. :) incidentally, (tangent) the more I think about it after writing my other mail, my rule ((#),?,!) seems to be not very useful, the only reason it makes a difference is because of the existence of 'seq' which lets me tell the difference between _|_ and \_ -> _|_. replacing it wich ((#),?,#->) where #-> is the kind of unboxed functions. with no rule of the form (#->,?,?) means that it is statically guarenteed things that take unboxed tuples are always fully applied to their arguments. i.e. exactly what we want for join points or other functions we wish to ensure become loops. Seems much more useful than functions of kind '!'. (end tangent) > > | Also, is there a way to do something similar but for 'lazy' rather than > | 'seq'? I want something of type > | > | type World__ = State# RealWorld > | > | {-# NOINLINE newWorld__ #-} > | newWorld__ :: a -> World__ > | newWorld__ x = realWord# -- ??? > | > | except that I need newWorld__ to be lazy in its first argument. I need > | to convince the opimizer that the World__ newWorld__ is returning > | depends on the argument passed to newWorld__. > > I don't understand what you meant here. The definition of newWorld__ that you give is, of course, lazy in x. it is getting type 'Absent' assigned to it by the demand analysis, I want it to be lazy (and not strict) 3 newWorld__ :: a -> World__ {- Arity: 1 HasNoCafRefs Strictness: A -} John -- John Meacham - ?repetae.net?john? From ravi at bluespec.com Sun Dec 3 20:19:45 2006 From: ravi at bluespec.com (Ravi Nanavati) Date: Sun Dec 3 20:17:58 2006 Subject: % of memory "unit" to heap-controlling RTS flags Message-ID: <457377B1.6090301@bluespec.com> If you're trying to produce ghc executables that will work well without tweaking on machines with different configurations, it would handy to be able to control the heap requested based on the size of physical RAM. For instance, you might want to set -M to 100% or 80% of physical RAM and -H to (say) 25% of physical RAM. I was wondering what people would think if we had a new sort of "unit" for the various memory options that actually specified that the memory amount requested was as a percentage of physical RAM. So you could do something like: prog +RTS -M80% -H25% -RTS to start your heap at 25% of physical RAM and cap it at 80% of of physical RAM. You'd also be able to intermix % with the other memory units so you could do something like: prog +RTS -H256m -M95% -RTS to start your heap at 256m and cap it at 95% of physical RAM. How does that sound? - Ravi From bulat.ziganshin at gmail.com Mon Dec 4 05:15:16 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Dec 4 05:16:51 2006 Subject: % of memory "unit" to heap-controlling RTS flags In-Reply-To: <457377B1.6090301@bluespec.com> References: <457377B1.6090301@bluespec.com> Message-ID: <845566110.20061204131516@gmail.com> Hello Ravi, Monday, December 4, 2006, 4:19:45 AM, you wrote: > and -H to (say) 25% of physical RAM. i had exactly the same idea. in particular, i want to setup -c value as percentage of available RAM -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Mon Dec 4 06:55:26 2006 From: igloo at earth.li (Ian Lynagh) Date: Mon Dec 4 06:53:30 2006 Subject: raw foregin imports - new backend for jhc: ghc In-Reply-To: <20061128042634.GD6726@momenergy.repetae.net> References: <20061114073043.GB16668@momenergy.repetae.net> <20061128042634.GD6726@momenergy.repetae.net> Message-ID: <20061204115526.GA9477@matrix.chaos.earth.li> Hi John, On Mon, Nov 27, 2006 at 08:26:34PM -0800, John Meacham wrote: > > At the moment, I don't think I need anything, I was just misreading > certain features. the ghc backend seems to be working fine with the > following caveats: > > * all integral types (even Integer) are flattened to Int#. I'm not sure I follow this - if I do foreign import ccall "static foo.h foo" foo :: Integer -> Integer then GHC tells me Unacceptable argument type in foreign declaration: Integer Unacceptable result type in foreign declaration: Integer Can you explain what you are doing that makes Integer get flattened, please? > * ghc -O on my generated programs crashes with the following: > > ghc-6.6: panic! (the 'impossible' happened) > (GHC version 6.6 for i386-unknown-linux): > primRepHint:VoidRep Another bug, thanks! Again, this isn't something we claim should work, but it should definitely either work or give a nice error message. I've filed it in trac: #1037. Thanks Ian From john at repetae.net Mon Dec 4 07:25:21 2006 From: john at repetae.net (John Meacham) Date: Mon Dec 4 07:22:58 2006 Subject: raw foregin imports - new backend for jhc: ghc In-Reply-To: <20061204115526.GA9477@matrix.chaos.earth.li> References: <20061114073043.GB16668@momenergy.repetae.net> <20061128042634.GD6726@momenergy.repetae.net> <20061204115526.GA9477@matrix.chaos.earth.li> Message-ID: <20061204122521.GF8493@momenergy.repetae.net> On Mon, Dec 04, 2006 at 11:55:26AM +0000, Ian Lynagh wrote: > Can you explain what you are doing that makes Integer get flattened, > please? oh, I meant that was a limitation of my backend, not ghc. jhc has primitive types for all possible c types, like uint32_t and uint16_t etc are distinct unboxed types. ghc seems to work mostly by boxing Int# and doing the appropriate bit narrowing in the library. My current solution is just to map all primitive types to Int#. even though it gives incorrect results it seems to work well enough for testing the back end. I am not sure what my long term solution will be, probably to auto-generate some ghc code to simulate all the appropriate primitives the jhc front end expects to exist. John -- John Meacham - ?repetae.net?john? From igloo at earth.li Mon Dec 4 07:24:57 2006 From: igloo at earth.li (Ian Lynagh) Date: Mon Dec 4 07:23:04 2006 Subject: TH - splicing with functions defined in the same source file In-Reply-To: References: <87wt5fzhvg.wl%clemens@endorphin.org> Message-ID: <20061204122457.GB9477@matrix.chaos.earth.li> On Thu, Nov 30, 2006 at 02:12:48AM +0000, Simon Peyton-Jones wrote: > > 2. You have to compile all the code before your cut-point to byte-code, just in case it's invoked by a splice afterwards. This is in addition to compiling it to machine code (assuming that's what the main compilation does). > > Concerning (2), the thought of compiling all of every module to bytecode, on the off chance that a later splice might need it, seems unattractive to me (although it might work fine). To predict, instead, which definitions will be needed means looking at the free variables of later splices, and taking a kind of transitive closure. Possible but sounds like real work. This is probably the main reason I've never attempted it. I don't know if the code is currently structured in a way that would make this easy, but in principle laziness could take care of only byte-code compiling bits we need couldn't it? It would probably need an unsafeInterleaveIO for loading the compiled objects of imports used, but it doesn't seem like it should be impossible. Also, we'd only need to do the bytecode compilation when -fth is on, so it shouldn't be a performance hit for normal usage even if we did the bytecode compilation whether the splices need it or not. Thanks Ian From Malcolm.Wallace at cs.york.ac.uk Mon Dec 4 08:25:55 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Dec 4 08:28:37 2006 Subject: OPTIONS_GHC -auto-all In-Reply-To: <20061202115325.GA1202@scico.botik.ru> References: <20061202115325.GA1202@scico.botik.ru> Message-ID: <20061204132555.10358c3e.Malcolm.Wallace@cs.york.ac.uk> "Serge D. Mechveliani" wrote: > {-# OPTIONS_GHC -fglasgow-ext -prof -auto-all #-} > > LemmaSearch.hs: > unknown flags in {-# OPTIONS #-} pragma: -fglasgow-ext -prof -auto-all You have spelled the first option wrongly: should be -fglasgow-exts. Regards, Malcolm From mechvel at botik.ru Mon Dec 4 09:34:06 2006 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Dec 4 09:32:23 2006 Subject: OPTIONS_GHC -auto-all Message-ID: <20061204143406.GA2675@scico.botik.ru> In my previous letter I wrote about {-# OPTIONS_GHC -fglasgow-ext -prof -auto-all #-} in ghc-6.6. Now, I improve the typo and enter {-# OPTIONS_GHC -fglasgow-exts -prof -auto-all #-} in order to force -auto-all for a certain particular module. It still reports make build runhaskell Setup.hs build Preprocessing library dumatel-1.6... Building dumatel-1.6... LemmaSearch.hs: unknown flags in {-# OPTIONS #-} pragma: -prof -auto-all Who knows, please, what is the matter? ----------------- Serge Mechveliani mechvel@botik.ru From Alistair_Bayley at invescoperpetual.co.uk Mon Dec 4 09:41:14 2006 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Mon Dec 4 09:39:17 2006 Subject: OPTIONS_GHC -auto-all In-Reply-To: <20061204143406.GA2675@scico.botik.ru> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9891A0F@GBLONXMB02.corp.amvescap.net> > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Serge D. Mechveliani > > Now, I improve the typo and enter > > {-# OPTIONS_GHC -fglasgow-exts -prof -auto-all #-} > > in order to force -auto-all for a certain particular module. > It still reports > LemmaSearch.hs: > unknown flags in {-# OPTIONS #-} pragma: -prof -auto-all > > Who knows, please, what is the matter? This page explains the difference between static and dynamic flags: http://www.haskell.org/ghc/docs/latest/html/users_guide/static-dynamic-f lags.html And this page tells you that the profiler options are static only, which means you can only tell GHC about them on the command line: http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.h tml#id3155578 Alistair ***************************************************************** 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. ***************************************************************** From lemmih at gmail.com Mon Dec 4 09:41:16 2006 From: lemmih at gmail.com (Lemmih) Date: Mon Dec 4 09:39:19 2006 Subject: OPTIONS_GHC -auto-all In-Reply-To: <20061204143406.GA2675@scico.botik.ru> References: <20061204143406.GA2675@scico.botik.ru> Message-ID: On 12/4/06, Serge D. Mechveliani wrote: > In my previous letter I wrote about > > {-# OPTIONS_GHC -fglasgow-ext -prof -auto-all #-} > > in ghc-6.6. > > Now, I improve the typo and enter > > {-# OPTIONS_GHC -fglasgow-exts -prof -auto-all #-} > > in order to force -auto-all for a certain particular module. > It still reports > > make build > runhaskell Setup.hs build > Preprocessing library dumatel-1.6... > Building dumatel-1.6... > LemmaSearch.hs: > unknown flags in {-# OPTIONS #-} pragma: -prof -auto-all > > Who knows, please, what is the matter? -prof and -auto-all are static flags. They cannot be turned on after GHC starts processing the file. See http://www.haskell.org/ghc/docs/latest/html/users_guide/static-dynamic-flags.html -- Cheers, Lemmih From mechvel at botik.ru Mon Dec 4 09:47:56 2006 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Dec 4 09:46:22 2006 Subject: OPTIONS_GHC -auto-all In-Reply-To: References: <20061204143406.GA2675@scico.botik.ru> Message-ID: <20061204144756.GA2734@scico.botik.ru> I see, thank you. > > {-# OPTIONS_GHC -fglasgow-exts -prof -auto-all #-} > > > >in order to force -auto-all for a certain particular module. > >It still reports > > unknown flags in {-# OPTIONS #-} pragma: -prof -auto-all > -prof and -auto-all are static flags. They cannot be turned on after > GHC starts processing the file. > See > http://www.haskell.org/ghc/docs/latest/html/users_guide/static-dynamic-flags.html > > -- > Cheers, > Lemmih > From catamorphism at gmail.com Mon Dec 4 10:15:10 2006 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Mon Dec 4 10:13:13 2006 Subject: bang patterns give fundamentally new capabilities? In-Reply-To: <20061203230023.GD8493@momenergy.repetae.net> References: <20061201041313.GF6726@momenergy.repetae.net> <20061203230023.GD8493@momenergy.repetae.net> Message-ID: <4683d9370612040715r300abc78s94d98475ddc47699@mail.gmail.com> On 12/3/06, John Meacham wrote: > On Sat, Dec 02, 2006 at 11:02:28PM +0000, Simon Peyton-Jones wrote: [snip] > > | Also, is there a way to do something similar but for 'lazy' rather than > > | 'seq'? I want something of type > > | > > | type World__ = State# RealWorld > > | > > | {-# NOINLINE newWorld__ #-} > > | newWorld__ :: a -> World__ > > | newWorld__ x = realWord# -- ??? > > | > > | except that I need newWorld__ to be lazy in its first argument. I need > > | to convince the opimizer that the World__ newWorld__ is returning > > | depends on the argument passed to newWorld__. > > > > I don't understand what you meant here. The definition of newWorld__ that you give is, of course, lazy in x. > > it is getting type 'Absent' assigned to it by the demand analysis, I > want it to be lazy (and not strict) > > 3 newWorld__ :: a -> World__ {- Arity: 1 HasNoCafRefs Strictness: A -} > Well, yeah, that's because it *is* absent. If you want to convince the demand analyzer that it isn't, then use x somewhere on the right-hand side of the definition of newWorld__. Maybe I could be more helpful if I knew what you were really trying to do here? (My best guess is that you're trying to implement your own IO monad, which really shouldn't be possible AFAIK unless there's something seriously wrong with GHC that I don't know about. Unless you use The Function That Shall Not Be Named.) Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt From simonmarhaskell at gmail.com Mon Dec 4 10:15:15 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Dec 4 10:13:23 2006 Subject: Building GHC quickly In-Reply-To: <20061203075203.GA9731@cse.unsw.EDU.AU> References: <20061203075203.GA9731@cse.unsw.EDU.AU> Message-ID: <45743B83.8080203@microsoft.com> Donald Bruce Stewart wrote: > Had a go today building GHC on a multcore linux box, with -j, just to > see how fast it would go. > > Summary: you can build GHC from scratch in less than 10 minutes these days! > > More details here: > http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/03#build_ghc_fast I'd be interested in how long it takes if you turn on -O for the stage 1 compiler only. The point being that it'll be slower to compile stage 1, but that compiler is then used to build all the libraries and stage 2, so the benefit of having an optimised stage 1 might outweigh the time it takes to build it. Cheers, Simon From catamorphism at gmail.com Mon Dec 4 10:47:32 2006 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Mon Dec 4 10:45:35 2006 Subject: difficult profiling example In-Reply-To: <20061202152750.GA1964@scico.botik.ru> References: <20061202152750.GA1964@scico.botik.ru> Message-ID: <4683d9370612040747l479c6cebr5d9326f30fccf317@mail.gmail.com> On 12/2/06, Serge D. Mechveliani wrote: > It looks correct that searchLemmata costs 90%. > I could believe that splitDisjunctScheme and addEquationsWithReduction > take together about 8% of what searchLemma costs. > > But who inside the searchLemmata loop takes the rest of (90 - 8)% ? > I didn't look at your code all that carefully, but did you build the GHC libraries with "-prof -auto-all"? (Not just "-prof".) If you don't build the libraries with "-auto-all", then cost centres won't get inserted for library functions, and if it's really a standard library function that's taking all of that time, the profiling report won't indicate that. On the other hand, one thing to watch out for with GHC's cost-centre profiling is that a lot of optimizations get effectively disabled when you build with "-auto-all" (or insert your own cost centres liberally), so if you're profiling optimized codes, the results can sometimes be misleading (especially if you build libraries with "-auto-all" too). Using ticky-ticky profiling instead could be helpful, but I don't think it works in 6.6. (I've gotten a limited form of it working again and I'm hoping to check it into the HEAD soon.) Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt From dons at cse.unsw.edu.au Mon Dec 4 19:28:03 2006 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Mon Dec 4 19:26:25 2006 Subject: Building GHC quickly In-Reply-To: <45743B83.8080203@microsoft.com> References: <20061203075203.GA9731@cse.unsw.EDU.AU> <45743B83.8080203@microsoft.com> Message-ID: <20061205002803.GA11279@cse.unsw.EDU.AU> simonmarhaskell: > Donald Bruce Stewart wrote: > >Had a go today building GHC on a multcore linux box, with -j, just to > >see how fast it would go. > > > >Summary: you can build GHC from scratch in less than 10 minutes these days! > > > >More details here: > > http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/03#build_ghc_fast > > I'd be interested in how long it takes if you turn on -O for the stage 1 > compiler only. The point being that it'll be slower to compile stage 1, > but that compiler is then used to build all the libraries and stage 2, so > the benefit of having an optimised stage 1 might outweigh the time it takes > to build it. Yes! 7 mins 49 seconds, with: SRC_HC_OPTS = -H64m -Onot -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -Onot -fasm GhcLibHcOpts = -Onot -fasm GhcLibWays = SplitObjs = NO and -j10, on a 4 core linux machine. When the new 16 core box arrives, I'll set up a nightly build to ensure the -jN building keeps working. -- Don From john at repetae.net Mon Dec 4 23:08:32 2006 From: john at repetae.net (John Meacham) Date: Mon Dec 4 23:06:08 2006 Subject: [Haskell] Expecting more inlining for bit shifting In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D411606E89FA4@EUR-MSG-21.europe.corp.microsoft.com> References: <20061018053647.GC4996@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D411606E89FA4@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20061205040832.GI6726@momenergy.repetae.net> On Wed, Oct 18, 2006 at 09:48:31AM +0100, Simon Peyton-Jones wrote: > | I would think the easiest way to go about this would be to extend the > | rules pragma. > | > | {-# RULES "shift/const-inline" forall x y# . shift x y# = ... #-} > | > | where variables ending in # will only match constants known at compile time > > Interesting idea. GHC can do that *internally* using a "BuiltinRule", and it's internal precisely because there's no obvious way to say "match only a literal". > > I suppose that you might also want to say "match only a constructor"? To have a rule for 'f' that would fire only when you saw > f (Just x) > or f Nothing > but not f (g y) > > For that, a # would not really be appropriate. > > > Would this be valuable? If so, think of a nice syntax. It's not trivial to implement, but not hard either. heh. thinking of a nice syntax is what has kept me from exposing this behavior to the user in jhc so far. :) I am thinking something like the following: {-# RULES "shift/const-inline" forall x y | is_constant y . shift x y = ... #-} which uses '|' like in pattern matching, where it specifies a condition the variable has to meet. so 'is_constant' will say whether y is completely known at compile time. the nice thing about this syntax is that it is extendable pretty easily {-# RULES "foo/known" forall x y | is_whnf y . foo x y = ... #-} where is_whnf will test whether y is bound directly to a constructor or a lambda expression. John -- John Meacham - ?repetae.net?john? From simonmarhaskell at gmail.com Tue Dec 5 04:23:35 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Dec 5 04:21:52 2006 Subject: Building GHC quickly In-Reply-To: <20061205002803.GA11279@cse.unsw.EDU.AU> References: <20061203075203.GA9731@cse.unsw.EDU.AU> <45743B83.8080203@microsoft.com> <20061205002803.GA11279@cse.unsw.EDU.AU> Message-ID: <45753A97.205@microsoft.com> Donald Bruce Stewart wrote: > simonmarhaskell: > >>Donald Bruce Stewart wrote: >> >>>Had a go today building GHC on a multcore linux box, with -j, just to >>>see how fast it would go. >>> >>>Summary: you can build GHC from scratch in less than 10 minutes these days! >>> >>>More details here: >>> http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/03#build_ghc_fast >> >>I'd be interested in how long it takes if you turn on -O for the stage 1 >>compiler only. The point being that it'll be slower to compile stage 1, >>but that compiler is then used to build all the libraries and stage 2, so >>the benefit of having an optimised stage 1 might outweigh the time it takes >>to build it. > > > Yes! > > 7 mins 49 seconds, with: > > SRC_HC_OPTS = -H64m -Onot -fasm > GhcStage1HcOpts = -O -fasm > GhcStage2HcOpts = -Onot -fasm > GhcLibHcOpts = -Onot -fasm > GhcLibWays = > SplitObjs = NO > > and -j10, on a 4 core linux machine. Great - although with unoptimised libraries this build isn't really much use except as a sanity check. How much extra time does it take if you optimise the libraries? > When the new 16 core box arrives, I'll set up a nightly build to ensure > the -jN building keeps working. Nice :) Hopefully we'll have BuildBot set up soon, so adding new nightly builds will be easy. Cheers, Simon From maeder at tzi.de Tue Dec 5 08:04:51 2006 From: maeder at tzi.de (Christian Maeder) Date: Tue Dec 5 08:03:11 2006 Subject: generic ghc binary Linux (x86_64) misses libHSghc Message-ID: <45756E73.2060805@tzi.de> having just installed http://www.haskell.org/ghc/dist/6.6/ghc-6.6-x86_64-unknown-linux.tar.bz2 it occurs that libHSghc.a is missing, but ghc-pkg lists (ghc-6.6). Christian maeder@castor:~/haskell/linux64> ghci -package ghc ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.6 ... ghc-6.6: can't load .so/.DLL for: HSghc (libHSghc.so: cannot open shared object file: No such file or directory) From simonmar at microsoft.com Tue Dec 5 09:42:32 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Dec 5 09:40:35 2006 Subject: Safepoint does not work as documented in paper In-Reply-To: <45758212.7060707@list.mightyreason.com> Message-ID: Chris Kuklewicz wrote: > One odd problem: The paper on async exception defines: > > safePoint = unblock (return ()) > > but this simply does not work in my testing. Ever. Even using > {-# NOINLINE safePoint #-} or "-Onot" > > By comparision, this does work: safepoint = unblock (print "safe") > > So how can such a safePoint be written? The window in 'unblock (return ())' is tiny, I'm not really surprised if nothing ever gets through it. You might have more luck with 'unblock yield'. (BTW, I think glasgow-haskell-users@haskell.org is a more appropriate list, so I'm replying there instead). Cheers, Simon From haskell at list.mightyreason.com Tue Dec 5 11:25:04 2006 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Dec 5 11:23:05 2006 Subject: Safepoint does not work as documented in paper In-Reply-To: References: Message-ID: <45759D60.3040407@list.mightyreason.com> Simon Marlow wrote: > Chris Kuklewicz wrote: >> One odd problem: The paper on async exception defines: >> >> safePoint = unblock (return ()) >> >> but this simply does not work in my testing. Ever. Even using >> {-# NOINLINE safePoint #-} or "-Onot" >> >> By comparision, this does work: safepoint = unblock (print "safe") >> >> So how can such a safePoint be written? > > The window in 'unblock (return ())' is tiny, I'm not really surprised if nothing ever gets through it. You might have more luck with 'unblock yield'. > > (BTW, I think glasgow-haskell-users@haskell.org is a more appropriate list, so I'm replying there instead). > > Cheers, > Simon That works, thanks. It is funny, the killThread thread is halted and waiting for the async signal to be delivered, and the running thread got through eleven (unblock (print "sleeper")) statements before noticing that it had been told to die. Using your (unblock yield) worked I had thought that "unblock" would always check the queue of incoming async signals but this is obviously not the case. The "Asynchronous Exceptions in Haskell" paper says: "As soon as a thread exits the scope of a block, and at regular intervals during execution inside unblock, its pending exceptions queue must be checked. If there are pending exceptions, the first one is removed from the queue and delivered to the thread." ...which is why I have the wrong expectation. Is there a better resource for how GHC actually implements block/unblock/throwTo ? Searching for throwTo on the wiki gets me nothing. -- Chris From simonmarhaskell at gmail.com Tue Dec 5 11:36:20 2006 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Dec 5 11:34:25 2006 Subject: Safepoint does not work as documented in paper In-Reply-To: <45759D60.3040407@list.mightyreason.com> References: <45759D60.3040407@list.mightyreason.com> Message-ID: <4575A004.5040309@microsoft.com> Chris Kuklewicz wrote: > Simon Marlow wrote: > >>Chris Kuklewicz wrote: >> >>>One odd problem: The paper on async exception defines: >>> >>>safePoint = unblock (return ()) >>> >>>but this simply does not work in my testing. Ever. Even using >>>{-# NOINLINE safePoint #-} or "-Onot" >>> >>>By comparision, this does work: safepoint = unblock (print "safe") >>> >>>So how can such a safePoint be written? >> >>The window in 'unblock (return ())' is tiny, I'm not really surprised if nothing ever gets through it. You might have more luck with 'unblock yield'. >> >>(BTW, I think glasgow-haskell-users@haskell.org is a more appropriate list, so I'm replying there instead). >> >>Cheers, >> Simon > > > That works, thanks. > > It is funny, the killThread thread is halted and waiting for the async signal to > be delivered, and the running thread got through eleven (unblock (print > "sleeper")) statements before noticing that it had been told to die. Using > your (unblock yield) worked > > I had thought that "unblock" would always check the queue of incoming async > signals but this is obviously not the case. The "Asynchronous Exceptions in > Haskell" paper says: > > "As soon as a thread exits the scope of a block, and at regular intervals during > execution inside unblock, its pending exceptions queue must be checked. If there > are pending exceptions, the first one is removed from the queue and delivered to > the thread." There's one major difference between what's described in that paper and what's actually implemented: GHC's throwTo is synchronous; it doesn't return until the exception has been delivered. We went to-and-fro on this issue several times during the design, and I forget the reason we finally went with the asynchronous version of throwTo for the paper; maybe we were thinking about distributed applications where a synchronous throwTo would be more difficult to implement. The synchronous version is often easier to program with, so that's what we've got in GHC, and you can get the asynchronous version by adding a forkIO around it. Now, this leads to the reason why 'unblock (return ())' doesn't work as you expected. When a thread executes throwTo and the target thread is inside a block, the source thread blocks. when the target thread hits an unblock, it wakes up the source thread, but unless it context switches before entering a blocked state again, when the source thread finally runs it'll find the target thread in a blocked state and have to go back to sleep. > ...which is why I have the wrong expectation. Is there a better resource for > how GHC actually implements block/unblock/throwTo ? Searching for throwTo on > the wiki gets me nothing. I should write something in the commentary sometime... Cheers, Simon From simonpj at microsoft.com Tue Dec 5 18:12:26 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Dec 5 18:10:26 2006 Subject: [Haskell] GHC Error question In-Reply-To: <20061205212041.120D512F40F4@curlycoat> Message-ID: [redirecting to ghc users] It looks like a splendid error to me. The call of compile1 is obliged to pass to compile1 a dictionary of type (Builder b box), *for any type box*. There are no further constraints on box, so compile1 can make no assumptions about how the caller chooses to instantiate 'box'. But in the body you'll need a dictionary of type (Builder b box1), but there is nothing to ensure that the caller chooses the "right" box. Maybe you want the Builder class to have a functional dependency (b -> box), so that fixing b fixes box. I can't say more without seeing the code. can you give a small repo case? Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Norman | Ramsey | Sent: 05 December 2006 21:21 | To: haskell@haskell.org | Cc: nr@eecs.harvard.edu | Subject: [Haskell] GHC Error question | | Without going too deep into the details of my type classes, I have | written the following code (focusing on compile1): | | {-# OPTIONS -fglasgow-exts #-} | | compile1 :: (Builder b box) => t -> Name -> Ir.ANF -> b t | compile1 f x body = do env <- compile body empty | wire (Arg W) (env x) | return f | | compile :: (Builder b box) => Ir.ANF -> Env box -> b (Env box) | | class (Monad b) => Builder b box where | wire :: Source box -> Sink box -> b () | ... | | type Env box = Name -> Sink box | | This program is rejected by GHC with the following message: | | Ccomp.hs:54:23: | Could not deduce (Builder b box1) from the context (Builder b box) | arising from use of `wire' at Ccomp.hs:54:23-42 | Possible fix: | add (Builder b box1) to the type signature(s) for `compile1' | In the expression: wire (Arg W) (env x) | In a 'do' expression: wire (Arg W) (env x) | In the expression: | do env <- compile body empty | wire (Arg W) (env x) | return f | | Note that compile1 has an explicit type signature much along the lines | suggested by GHC. If I *remove* this type signature, the function | compiles successfully, and ghci reporets this type for compile1: | | compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 | | I believe this signature is isomorphic to the explicit signature I had | attempted to use. | | Am I misusing the type-class system in some way, or should I be | reporting a bug in GHC? | | | Norman | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From nr at eecs.harvard.edu Tue Dec 5 20:40:32 2006 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Tue Dec 5 20:38:29 2006 Subject: [Haskell] GHC Error question In-Reply-To: References: Message-ID: <20061206014032.3CBED788212@labrador.eecs.harvard.edu> > [redirecting to ghc users] > > It looks like a splendid error to me. I'm not sure if you meant the error or the message was splendid :-) I yelled for help because my usual strategy failed. That strategy is 1. Remove the type annotation. 2. Get ghci to tell me what the 'right type' is. 3. Put the 'right type' in the type annotation. I find it a bit depressing that the most general type inferred by ghci does not work as a type signature. > I can't say more without seeing the code. can you give a small repo case? Yes, here's a case that fits in one screen of emacs :-) {-# OPTIONS -fglasgow-exts #-} module Ccomp where type Name = String data Inface = N | W data Outface = S | E data Sink box = Boxin Inface box | Result data Source box = Boxout Outface box | Arg Inface data Command = Send0 class (Monad b) => Builder b box where box :: Command -> b box wire :: Source box -> Sink box -> b () type Env box = Name -> Sink box empty = \x -> error (x ++ " not connected or multiply connected in circuit") -- either of these explicit signatures causes the compiler to fail -- although the inferred signature is the second. --compile1 :: (Builder b box) => Name -> Name -> ANF -> b Name compile1 :: (Builder t box) => t1 -> Name -> ANF -> t t1 -- generated by ghci compile1 f x body = do env <- compile body empty wire (Arg W) (env x) return f data ANF = ANF () compile :: (Builder b box) => ANF -> Env box -> b (Env box) compile (ANF m) out = undefined > | This program is rejected by GHC with the following message: > | > | Ccomp.hs:54:23: > | Could not deduce (Builder b box1) from the context (Builder b box) > | arising from use of `wire' at Ccomp.hs:54:23-42 > | Possible fix: > | add (Builder b box1) to the type signature(s) for `compile1' > | In the expression: wire (Arg W) (env x) > | In a 'do' expression: wire (Arg W) (env x) > | In the expression: > | do env <- compile body empty > | wire (Arg W) (env x) > | return f > | > | Note that compile1 has an explicit type signature much along the lines > | suggested by GHC. If I *remove* this type signature, the function > | compiles successfully, and ghci reporets this type for compile1: > | > | compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 > | > | I believe this signature is isomorphic to the explicit signature I had > | attempted to use. From simonpj at microsoft.com Wed Dec 6 02:46:15 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Dec 6 02:44:13 2006 Subject: [Haskell] GHC Error question In-Reply-To: <20061206014032.3CBED788212@labrador.eecs.harvard.edu> Message-ID: I agree that this is confusing. Here is a cut-down example: class C a b where op :: a -> a -- f :: C a b => a -> a f x = op x It doesn't get much simpler than that! With the type sig, GHC can't see that the (C a b) provided can satisfy the (C a b1) which arises from the call to op. However, without the constraint, GHC simply abstracts over the constrains arising in the RHS, namely (C a b1), and hence infers the type f :: C a b1 => a -> a It is extremely undesirable that the inferred type does not work as a type signature, but I don't see how to fix it Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Norman Ramsey | Sent: 06 December 2006 01:41 | To: Simon Peyton-Jones | Cc: GHC users | Subject: Re: [Haskell] GHC Error question | | > [redirecting to ghc users] | > | > It looks like a splendid error to me. | | I'm not sure if you meant the error or the message was splendid :-) | I yelled for help because my usual strategy failed. That strategy is | | 1. Remove the type annotation. | 2. Get ghci to tell me what the 'right type' is. | 3. Put the 'right type' in the type annotation. | | I find it a bit depressing that the most general type inferred by ghci | does not work as a type signature. | | > I can't say more without seeing the code. can you give a small repo case? | | Yes, here's a case that fits in one screen of emacs :-) | | | {-# OPTIONS -fglasgow-exts #-} | module Ccomp where | | type Name = String | | data Inface = N | W | data Outface = S | E | | data Sink box = Boxin Inface box | Result | data Source box = Boxout Outface box | Arg Inface | | data Command = Send0 | | class (Monad b) => Builder b box where | box :: Command -> b box | wire :: Source box -> Sink box -> b () | | type Env box = Name -> Sink box | | empty = \x -> error (x ++ " not connected or multiply connected in circuit") | | -- either of these explicit signatures causes the compiler to fail | -- although the inferred signature is the second. | --compile1 :: (Builder b box) => Name -> Name -> ANF -> b Name | compile1 :: (Builder t box) => t1 -> Name -> ANF -> t t1 -- generated by ghci | compile1 f x body = do env <- compile body empty | wire (Arg W) (env x) | return f | | data ANF = ANF () | | compile :: (Builder b box) => ANF -> Env box -> b (Env box) | compile (ANF m) out = undefined | | > | This program is rejected by GHC with the following message: | > | | > | Ccomp.hs:54:23: | > | Could not deduce (Builder b box1) from the context (Builder b box) | > | arising from use of `wire' at Ccomp.hs:54:23-42 | > | Possible fix: | > | add (Builder b box1) to the type signature(s) for `compile1' | > | In the expression: wire (Arg W) (env x) | > | In a 'do' expression: wire (Arg W) (env x) | > | In the expression: | > | do env <- compile body empty | > | wire (Arg W) (env x) | > | return f | > | | > | Note that compile1 has an explicit type signature much along the lines | > | suggested by GHC. If I *remove* this type signature, the function | > | compiles successfully, and ghci reporets this type for compile1: | > | | > | compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 | > | | > | I believe this signature is isomorphic to the explicit signature I had | > | attempted to use. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mechvel at botik.ru Wed Dec 6 05:21:18 2006 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Dec 6 05:19:30 2006 Subject: profiling experience Message-ID: <20061206102118.GA675@scico.botik.ru> People, I describe below my small experience with the time profiling in ghc-6.6. To make sure, consider first the following simple example: ------------------------------------------------------- import List (sort) main = {-# SCC "main" #-} let n = 5*10^4 :: Int in putStr (shows (f [1 .. n]) "\n") f :: [Int] -> Int f xs = {-# SCC "f" #-} case xs of [] -> 0 x: ys -> (g x) + (h x) + (f ys) where g x = {-# SCC "g" #-} last $ sort [0 .. (rem x 10)] h x = {-# SCC "h" #-} last $ sort [0 .. (rem x 20)] ------------------------------------------------------- Making: ghc -O -prof --make Main Running: ./Main +RTS -p -M100m -RTS This produces the report (its indentation shows which center is called from which): -------------------------------------------------------------------- total time = 3.00 secs (60 ticks @ 50 ms) total alloc = 130,608,300 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc h Main 65.0 67.3 g Main 33.3 30.9 main Main 1.7 1.5 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 162 1 0.0 0.0 0.0 0.0 CAF Main 156 3 0.0 0.0 100.0 100.0 main Main 163 0 1.7 1.5 100.0 100.0 f Main 164 50001 0.0 0.3 98.3 98.5 h Main 166 50000 65.0 67.3 65.0 67.3 g Main 165 50000 33.3 30.9 33.3 30.9 CAF GHC.Handle 109 3 0.0 0.0 0.0 0.0 -------------------------------------------------------------------- To my mind, these numbers look all right: like I expected. Only I do not so firmly understand what is CAF, a "constant application form", a data which has cost, is assigned cost, but is out of the stack of calls. Is this profiling all right? Then, I need to find the main time eater in a certain concrete (and complex) example. Its profiling looks strange. I set SCC in all valuable inner loops in the modules Main.hs and LemmaSearch.hs. It shows --------------------------------------------- LemSearchList +RTS -p -M200m -RTS total time = 112.00 secs (2240 ticks @ 50 ms) total alloc = 3,813,365,740 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc CAF Main 95.5 96.1 splitDisjunctScheme LemmaSearch 2.5 2.2 addEquationsWithReduction LemmaSearch 1.3 1.4 --------------------------------------------- My idea was that some of the loops inside LemmaSearch must take almost all time. Instead, it shows that some CAF (anonymous, to me) in Main takes almost everything, and among places which I marked with SCC, the two are shown as 2.5% and 1.4%, and all the rest shown as zero: --------------------------------------------------- MAIN MAIN \ 1 0 0.0 0.0 100.0 100.0 CAF Main 2 80 57 96.0 96.1 99.9 99.9 ... --------------------------------------------------- The whole user project is build under -prof ("auto-all" skipped). The test Main.hs is built also under -prof. SCC are set only inside the functions Main.main and LemmaSearch.searchLemmataInInitial. What may consitute this strange CAF cost of 96% ? Kirsten Chevalier wrote > I didn't look at your code all that carefully, but did you build the > GHC libraries with "-prof -auto-all"? (Not just "-prof".) If you don't > build the libraries with "-auto-all", then cost centres won't get > inserted for library functions, and if it's really a standard library > function that's taking all of that time, the profiling report won't > indicate that. I made ghc-6.6 from the official source in a standard way: ./configure ...; make; make install Does this presume that this also generates the .p.o GHC library versions for -prof -auto-all ? Generally, I do not guess, so far, what is happening. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Wed Dec 6 05:33:45 2006 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Dec 6 05:31:59 2006 Subject: large source for `bugs' e-list Message-ID: <20061206103345.GA696@scico.botik.ru> Dear GHC lists administrators, Is this appropriate to send to glasgow-haskell-bugs@haskell.org a large source archive of 800 Kb to build an example ? The code has several SCC marks, and maybe someone could look into why ghc-6.6 profiling reports such strange numbers, or explain why they are not strange. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From maeder at tzi.de Wed Dec 6 06:15:30 2006 From: maeder at tzi.de (Christian Maeder) Date: Wed Dec 6 06:13:56 2006 Subject: large source for `bugs' e-list In-Reply-To: <20061206103345.GA696@scico.botik.ru> References: <20061206103345.GA696@scico.botik.ru> Message-ID: <4576A652.4020602@tzi.de> goto http://hackage.haskell.org/trac/ghc login with guest/guest and add a "New Ticket". There you can upload a large archive. Christian (a non-list administrator) Serge D. Mechveliani schrieb: > Dear GHC lists administrators, > > Is this appropriate to send to glasgow-haskell-bugs@haskell.org > a large source archive of 800 Kb to build an example > ? > The code has several SCC marks, and maybe someone could look into > why ghc-6.6 profiling reports such strange numbers, or explain why > they are not strange. > > Regards, > > ----------------- > Serge Mechveliani > mechvel@botik.ru From igloo at earth.li Wed Dec 6 06:52:07 2006 From: igloo at earth.li (Ian Lynagh) Date: Wed Dec 6 06:50:06 2006 Subject: % of memory "unit" to heap-controlling RTS flags In-Reply-To: <845566110.20061204131516@gmail.com> References: <457377B1.6090301@bluespec.com> <845566110.20061204131516@gmail.com> Message-ID: <20061206115207.GA30029@matrix.chaos.earth.li> On Mon, Dec 04, 2006 at 01:15:16PM +0300, Bulat Ziganshin wrote: > Monday, December 4, 2006, 4:19:45 AM, you wrote: > > > and -H to (say) 25% of physical RAM. > > i had exactly the same idea. in particular, i want to setup -c value > as percentage of available RAM I've added these suggestions to trac #750: http://hackage.haskell.org/trac/ghc/ticket/750 Thanks Ian From catamorphism at gmail.com Wed Dec 6 10:21:23 2006 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Wed Dec 6 10:19:39 2006 Subject: profiling experience In-Reply-To: <20061206102118.GA675@scico.botik.ru> References: <20061206102118.GA675@scico.botik.ru> Message-ID: <4683d9370612060721v7803ff79y6a6d31b52ec868d0@mail.gmail.com> On 12/6/06, Serge D. Mechveliani wrote: > What may consitute this strange CAF cost of 96% ? > > Kirsten Chevalier > wrote > > I didn't look at your code all that carefully, but did you build the > > GHC libraries with "-prof -auto-all"? (Not just "-prof".) If you don't > > build the libraries with "-auto-all", then cost centres won't get > > inserted for library functions, and if it's really a standard library > > function that's taking all of that time, the profiling report won't > > indicate that. > > I made ghc-6.6 from the official source in a standard way: > > ./configure ...; make; make install > > Does this presume that this also generates the .p.o GHC library versions > for -prof -auto-all ? > No; you must have built the profiling libraries (i.e., building the libraries with -prof), otherwise you wouldn't have been able to compile your code for profiling. But, building the profiling libraries in the standard way doesn't add "-auto-all" to the compile flags. So if you want to build the libraries with "-auto-all", do: make EXTRA_HC_OPTS=-auto-all but be careful! As I said in my previous message, adding cost centres disables some optimizations, so the profiling results you get from this may not be accurate with respect to what would happen if you ran your code after building it with -O and no profiling. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "I cannot remember a time when I did not take it as understood that everybody has at least two, if not twenty-two, sides to him."--Robertson Davies From maeder at tzi.de Wed Dec 6 11:37:55 2006 From: maeder at tzi.de (Christian Maeder) Date: Wed Dec 6 11:36:00 2006 Subject: generic ghc binary Linux (x86_64) misses libHSghc In-Reply-To: <45756E73.2060805@tzi.de> References: <45756E73.2060805@tzi.de> Message-ID: <4576F1E3.5070500@tzi.de> Christian Maeder schrieb: > having just installed > http://www.haskell.org/ghc/dist/6.6/ghc-6.6-x86_64-unknown-linux.tar.bz2 > > it occurs that libHSghc.a is missing, but ghc-pkg lists > (ghc-6.6). I've rebuilt this binary distribution (having 38 MB now). It can be obtained from: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/versions/ghc-6.6-x86_64-unknown-linux.tar.bz2 From ghc-users at catdancer.ws Wed Dec 6 19:40:30 2006 From: ghc-users at catdancer.ws (Cat Dancer) Date: Wed Dec 6 19:38:26 2006 Subject: 'accept' behavior with an asynchronous exception inside of a 'block' Message-ID: <145dae260612061640o4c99c3bdge7159a05c477264d@mail.gmail.com> Chris Kuklewicz suggested I direct this question to the developers ^_^ If I use a network accept inside a block: block ( ... (clientSocket, sockAddr) <- accept serverSocket ... ) and the 'accept' unblocks a pending asynchronous exception and the exception gets thrown, does this mean that the 'accept' won't have accepted a network connection? Certainly this seems like desirable behavior, since if the 'accept' call might accept a network connection and *then* raise the asynchronous exception, the reference to the accepted connection would be lost. However I couldn't tell from the library documentation whether this was intended to be a guarantee of the 'accept' function or not. From nr at eecs.harvard.edu Thu Dec 7 00:02:37 2006 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Thu Dec 7 00:00:32 2006 Subject: [Haskell] GHC Error question In-Reply-To: References: Message-ID: <20061207050237.C8FD5788212@labrador.eecs.harvard.edu> > I agree that this is confusing. Here is a cut-down example: > > class C a b where > op :: a -> a > > -- f :: C a b => a -> a > f x = op x > > It doesn't get much simpler than that! Indeed not. I salaam in your general direction. > With the type sig, GHC can't see that the (C a b) provided can > satisfy the (C a b1) which arises from the call to op. However, > without the constraint, GHC simply abstracts over the constrains > arising in the RHS, namely (C a b1), and hence infers the type > > f :: C a b1 => a -> a > > It is extremely undesirable that the inferred type does not work as a type > signature, but I don't see how to fix it Pity. Do you see a way for the error message to avoid suggesting the 'possible fix', and indeed instead suggesting 'possible fix: remove the type signature from f'? > > Simon > > | -----Original Message----- From: > | glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Norman Ramsey Sent: 06 December 2006 > | 01:41 To: Simon Peyton-Jones Cc: GHC users Subject: Re: [Haskell] GHC > | Error question > | > | > [redirecting to ghc users] > | > > | > It looks like a splendid error to me. > | > | I'm not sure if you meant the error or the message was splendid :-) > | I yelled for help because my usual strategy failed. That strategy is > | > | 1. Remove the type annotation. > | 2. Get ghci to tell me what the 'right type' is. > | 3. Put the 'right type' in the type annotation. > | > | I find it a bit depressing that the most general type inferred by ghci > | does not work as a type signature. > | > | > I can't say more without seeing the code. can you give a small repo > | > case? > | > | Yes, here's a case that fits in one screen of emacs :-) > | > | > | {-# OPTIONS -fglasgow-exts #-} > | module Ccomp where > | > | type Name = String > | > | data Inface = N | W > | data Outface = S | E > | > | data Sink box = Boxin Inface box | Result > | data Source box = Boxout Outface box | Arg Inface > | > | data Command = Send0 > | > | class (Monad b) => Builder b box where > | box :: Command -> b box > | wire :: Source box -> Sink box -> b () > | > | type Env box = Name -> Sink box > | > | empty = \x -> error (x ++ " not connected or multiply connected in > | circuit") > | > | -- either of these explicit signatures causes the compiler to fail -- > | although the inferred signature is the second. --compile1 :: (Builder b > | box) => Name -> Name -> ANF -> b Name compile1 :: (Builder t box) => t1 > | -> Name -> ANF -> t t1 -- generated by ghci compile1 f x body = do env <- > | compile body empty > | wire (Arg W) (env x) > | return f > | > | data ANF = ANF () > | > | compile :: (Builder b box) => ANF -> Env box -> b (Env box) > | compile (ANF m) out = undefined > | > | > | This program is rejected by GHC with the following message: > | > | > | > | Ccomp.hs:54:23: > | > | Could not deduce (Builder b box1) from the context (Builder b > | > | box) > | > | arising from use of `wire' at Ccomp.hs:54:23-42 > | > | Possible fix: > | > | add (Builder b box1) to the type signature(s) for `compile1' > | > | In the expression: wire (Arg W) (env x) > | > | In a 'do' expression: wire (Arg W) (env x) > | > | In the expression: > | > | do env <- compile body empty > | > | wire (Arg W) (env x) > | > | return f > | > | > | > | Note that compile1 has an explicit type signature much along the > | > | lines suggested by GHC. If I *remove* this type signature, the > | > | function compiles successfully, and ghci reporets this type for > | > | compile1: > | > | > | > | compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 > | > | > | > | I believe this signature is isomorphic to the explicit signature I > | > | had attempted to use. > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From maeder at tzi.de Thu Dec 7 05:37:37 2006 From: maeder at tzi.de (Christian Maeder) Date: Thu Dec 7 05:35:24 2006 Subject: ghc-6.6-src-extralibs.tar.bz2 Message-ID: <4577EEF1.6090900@tzi.de> The archive http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2 does not contain the files ControlPoint.hs and Domain.hs from directory libraries/OpenGL/Graphics/Rendering/OpenGL/GL/ These files are listed by the binary distribution http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2 Personally I don't miss these files, but they are of course missing from distributions I (and possibly others) made. How imported are these files? They are also not listed in libraries/OpenGL/openGL.cabal. Cheers Christian From lennart at augustsson.net Thu Dec 7 06:33:23 2006 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Dec 7 06:31:36 2006 Subject: [Haskell] GHC Error question In-Reply-To: References: Message-ID: And why isn't C a b equivalent to C a b1? forall a b . C a b => a -> a and forall a b1 . C a b1 => a -> a look alpha convertible to me. Or is the inferred type forall a . C a b1 => a -> a Btw, this reminds me again that I'd like to be able to use _ in type signatures. With the meaning of _ being, "there's a type here, but I can't be bothered to write it out in full." -- Lennart On Dec 6, 2006, at 02:46 , Simon Peyton-Jones wrote: > I agree that this is confusing. Here is a cut-down example: > > class C a b where > op :: a -> a > > -- f :: C a b => a -> a > f x = op x > > It doesn't get much simpler than that! With the type sig, GHC > can't see that the (C a b) provided can satisfy the (C a b1) which > arises from the call to op. However, without the constraint, GHC > simply abstracts over the constrains arising in the RHS, namely (C > a b1), and hence infers the type > f :: C a b1 => a -> a > > It is extremely undesirable that the inferred type does not work as > a type signature, but I don't see how to fix it > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- > haskell-users- > | bounces@haskell.org] On Behalf Of Norman Ramsey > | Sent: 06 December 2006 01:41 > | To: Simon Peyton-Jones > | Cc: GHC users > | Subject: Re: [Haskell] GHC Error question > | > | > [redirecting to ghc users] > | > > | > It looks like a splendid error to me. > | > | I'm not sure if you meant the error or the message was splendid :-) > | I yelled for help because my usual strategy failed. That > strategy is > | > | 1. Remove the type annotation. > | 2. Get ghci to tell me what the 'right type' is. > | 3. Put the 'right type' in the type annotation. > | > | I find it a bit depressing that the most general type inferred by > ghci > | does not work as a type signature. > | > | > I can't say more without seeing the code. can you give a > small repo case? > | > | Yes, here's a case that fits in one screen of emacs :-) > | > | > | {-# OPTIONS -fglasgow-exts #-} > | module Ccomp where > | > | type Name = String > | > | data Inface = N | W > | data Outface = S | E > | > | data Sink box = Boxin Inface box | Result > | data Source box = Boxout Outface box | Arg Inface > | > | data Command = Send0 > | > | class (Monad b) => Builder b box where > | box :: Command -> b box > | wire :: Source box -> Sink box -> b () > | > | type Env box = Name -> Sink box > | > | empty = \x -> error (x ++ " not connected or multiply connected > in circuit") > | > | -- either of these explicit signatures causes the compiler to fail > | -- although the inferred signature is the second. > | --compile1 :: (Builder b box) => Name -> Name -> ANF -> b Name > | compile1 :: (Builder t box) => t1 -> Name -> ANF -> t t1 -- > generated by ghci > | compile1 f x body = do env <- compile body empty > | wire (Arg W) (env x) > | return f > | > | data ANF = ANF () > | > | compile :: (Builder b box) => ANF -> Env box -> b (Env box) > | compile (ANF m) out = undefined > | > | > | This program is rejected by GHC with the following message: > | > | > | > | Ccomp.hs:54:23: > | > | Could not deduce (Builder b box1) from the context > (Builder b box) > | > | arising from use of `wire' at Ccomp.hs:54:23-42 > | > | Possible fix: > | > | add (Builder b box1) to the type signature(s) for > `compile1' > | > | In the expression: wire (Arg W) (env x) > | > | In a 'do' expression: wire (Arg W) (env x) > | > | In the expression: > | > | do env <- compile body empty > | > | wire (Arg W) (env x) > | > | return f > | > | > | > | Note that compile1 has an explicit type signature much along > the lines > | > | suggested by GHC. If I *remove* this type signature, the > function > | > | compiles successfully, and ghci reporets this type for > compile1: > | > | > | > | compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 > | > | > | > | I believe this signature is isomorphic to the explicit > signature I had > | > | attempted to use. > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From waldmann at imn.htwk-leipzig.de Thu Dec 7 07:20:11 2006 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Dec 7 07:18:44 2006 Subject: Type wildcards, was: Re: [Haskell] GHC Error question In-Reply-To: