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: ilyas239@gmail.com [mailto:ilyas239@gmail.com] 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 <simonpj@microsoft.com> wrote:

no, I don’t.  That’s odd.  How does it manifest for you?

 

S

 

From: ilyas239@gmail.com [mailto:ilyas239@gmail.com] 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 <simonpj@microsoft.com> wrote:

fixed thanks.

 

I’m doing another nofib run now.

 

S

 

From: ilyas239@gmail.com [mailto:ilyas239@gmail.com] 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 <simonpj@microsoft.com> wrote:

ok. busy working on it now. 

 

From: ilyas239@gmail.com [mailto:ilyas239@gmail.com] 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 <simonpj@microsoft.com> wrote:

I’ve been working on the code.  Will commit shortly.  Integrate seems ok, happily.


SImon

 

From: ilyas239@gmail.com [mailto:ilyas239@gmail.com] 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 <simonpj@microsoft.com> 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: ilyas239@gmail.com [mailto:ilyas239@gmail.com] 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 <ilya.sergey@gmail.com> 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 <simonpj@microsoft.com> 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