I don't know how to account for that. Make sure you are compiling everything with -dcore-lint. I guess you are on a Mac? I'm using 64-bit Linux. Is it definitely ok with the old demand analyser?
Note for others: this is nofib/imaginary/integrate. Simon From: [email protected] [mailto:[email protected]] On Behalf Of Ilya Sergey Sent: 16 January 2013 17:25 To: Simon Peyton-Jones Subject: Re: Cardinality I run nofib and at some point I get the following output: ==nofib== integrate: time to run integrate follows... ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; ../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -K20m -H100m -RTS 50000; /bin/sh: line 1: 33635 Bus error: 10 ././integrate +RTS -s/var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//stats33626 -RTS +RTS -K20m -H100m -RTS 50000 < /dev/null > /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.1.raw 2> /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.2.raw 3> /var/folders/c1/pbj77lbx6fnc3qkj984xp44h0000gn/T//runtest33626.3.raw real 0m0.922s user 0m0.004s sys 0m0.009s ././integrate +RTS -K20m -H100m -RTS 50000 < /dev/null **** expected exit status 0 not seen ; got 138 /bin/sh: line 1: 33651 Bus error: 10 If I remove integrate from the nofib Makefile, the rest of the benchmarks works just fine. Ilya On Wed, Jan 16, 2013 at 9:19 PM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: no, I don't. That's odd. How does it manifest for you? S From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ilya Sergey Sent: 16 January 2013 17:13 To: Simon Peyton-Jones Subject: Re: Cardinality Thank you. I ran nofib myself too, and it seems to be fine, except that issue with imaginary/integrate. Did you have that error when running nofib as well? Ilya On Wed, Jan 16, 2013 at 5:39 PM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: fixed thanks. I'm doing another nofib run now. S From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ilya Sergey Sent: 16 January 2013 12:38 To: Simon Peyton-Jones Subject: Re: Cardinality Hi Simon. I tried to build from the `new-demand-to-merge` branch recently, and I got the following Lint error when building libraries/base/GHC/Event/Array.hs by a stage-1 compiler: *** Core Lint errors : in result of Common sub-expression *** <no location info>: Warning: In a case alternative: (GHC.ForeignPtr.ForeignPtr fo_s3mr :: GHC.Prim.Addr#, ds1_s3mq :: GHC.ForeignPtr.ForeignPtrContents) Occurrence of a dead Id wild_s3ms Any ideas, how it could be fixed, so I could integrate your changes into the cardinality branch and run the experiments? Kind regards, Ilya On Tue, Jan 8, 2013 at 11:22 PM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: ok. busy working on it now. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ilya Sergey Sent: 07 January 2013 11:53 To: Simon Peyton-Jones Subject: Re: Cardinality Great, thank you. Please, let me know when it's in the stable state, so I could implement the optimisation making use of single-used thunks (and it would not interfere with your changes). Kind regards, Ilya On Fri, Jan 4, 2013 at 3:11 PM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: I've been working on the code. Will commit shortly. Integrate seems ok, happily. SImon From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ilya Sergey Sent: 23 December 2012 16:57 To: Simon Peyton-Jones Subject: Re: Cardinality Hi Simon. >From what I can observe, after the trivial merge the new-demand compiled >'integrate' fails (exit code 138), whereas the trunk-compiled one does not. The last time I merged before was November 8, and everything was fine, just as I left it in September. So far, the only difference I can see in the W/W code is that the new-demand compiler makes more aggressive split for the arguments of `integrate1D` (see ww-new.log in the attachment), which seems to be correct to me, as these arguments are used strictly. The compiler from the trunk, however, keeps these arguments boxed, which surprises me (ww-trunk.log). I'm not entirely sure, but it might affect the unpacking strategy on later stages of the simplifier. It would be helpful to know what else I can do to debug this inconsistency. Thanks. Best regards, Ilya On Sun, Dec 23, 2012 at 8:10 PM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: However, now we have a problem: for one test from nofib, namely imaginary/integrate, the optimizer changes the semantics, so the program fails. Can you be more specific? How does the semantics change? How do you know it is changed? Is this a recent change? Simon From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ilya Sergey Sent: 22 December 2012 19:04 To: Simon Peyton-Jones Subject: Re: Cardinality Dear Simon. Today I spent some time merging 'master' into the 'new-demand-to-merge' branch. It went fine, and I managed to compile it and run the nofib, and results *almost* didn't change: the new strictness analyzer still does better in most of the cases than the old one. However, now we have a problem: for one test from nofib, namely imaginary/integrate, the optimizer changes the semantics, so the program fails. It is quite strange, as from the perspective of the demand analyser the results are similar. As I haven't changed anything in the analysis or the worker/wrapper split, I tend to think it might be the refactoring of the unpacking strategy that clashed with the current logic of W/W. Shall I merge the 'master' into 'new-demand' branch ignoring this issue, or should I keep things as they are, so you could take a look on it and merge it yourself? Kind regards, Ilya On Sat, Dec 22, 2012 at 2:30 AM, Ilya Sergey <[email protected]<mailto:[email protected]>> wrote: Dear Simon. Thank you for the example. I will definitely compile something like this and check the memory consumption. I also have to implement the changes suggested by you and Dimitrios for single-used thunks. The cardinality branch was up-to date with the trunk (and the new demand branch) by mid-November. Yesterday I tried to update it, but by some mysterious reasons I could not compile the current trunk (getting seg-fault). I suspect it might be because of some outdated cabal packages. So once I get the trunk compiled, I will bring both new demand and cardinality branch up to date. I'm still in Saint Petersburg, and will be here until mid-January, waiting for my Spanish visa. Next week I have a deadline for our SCP invited paper, and then for a few weeks I will be focusing exclusively on the cardinality and demand work. Merry Christmas and happy holidays to you and your family! With best regards, Ilya On Fri, Dec 21, 2012 at 9:51 PM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: Ilya I've found an example where cardinality will really help: CPS code. For example, deriving( Read ) generates code (in HEAD, soon) like this expectP x (\v1 -> expectP y (\v2 -> expectP z (\v3 -> ...))) Then the full-laziness (float-out) pass tries to float out lets from those lambdas, because it thinks they may be called many times. But actually they are only called once ... they are continuations ... and the cardinality analysis will discover that I think. I hope to get to this in the new year. What is the state of the cardinality branch? I hope you are enjoying Madrid Simon
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
