lambda mining

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

lambda mining

Simon Peyton Jones
(devs: this thread is about adding useful new benchmarks to nofib.)

Oh bother. I'd forgotten about dependencies. I don't want to make building nofib depend on libraries other those in GHC anyway (bytestring, unix ok, asynch perhaps not).  If that makes it tricky, maybe we should give up on the idea.

S

From: Jos? Pedro Magalh?es [mailto:jose.pedro.magalhaes at cs.ox.ac.uk]
Sent: 05 August 2013 08:41
To: Simon Peyton-Jones
Subject: Re: lambda mining

I'm not entirely sure how to do that, though. Do I just add it to the "real" subset?
How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >= 2.0.0.0, ...)


Cheers,
Pedro
On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
great!  Just add it :-)

simon

From: Jos? Pedro Magalh?es [mailto:jpm at cs.ox.ac.uk<mailto:jpm at cs.ox.ac.uk>]
Sent: 30 July 2013 07:48
To: Simon Peyton-Jones
Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen
Subject: Re: lambda mining

Hi Simon,

(CC-ing co-authors)

Yes, I think it might work fine. Its running time can also be adjusted easily, depending on the maps
given as input and some internal parameters. How would we go about adding it to nofib?


Thanks,
Pedro
On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Pedro

Wandering past your home page I took a look at your "lambda mining" paper.  Would it be suitable as a nofib benchmark? Moderate size, authentic code...  Would you be interested?

Simon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130816/21786d0d/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

lambda mining

Austin Seipp-4
IMO, it's reasonable to allow this, but there's one minor sticky bit.

async's only dependency is stm, and it's also part of the platform, so I
expect it will be relatively stable. In this case, perhaps we should just
add 'async' to the set of 'extra' libraries for ./sync-all, which can be
built with the compiler. Then, it should be easy to add tests for nofib
(and even testsuite, if people find bugs.) stm is already one of the
'extra' libraries, and there are a few smp benchmarks that use it too, so
this doesn't really change anything in that regard.

The main thing is that async isn't under our normal package structure, so
we'll either need to A) mirror it, or B) we need to add support for
./sync-all to sync with an arbitrary HTTP url or something, and point it to
Simon's repository as an extra package.

I'm in favor of 2 since then we don't have to maintain an unnecessary
mirror, and also, because it might be useful later for similar things.

Thoughts?

On Fri, Aug 16, 2013 at 6:58 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  (devs: this thread is about adding useful new benchmarks to nofib.)****
>
> ** **
>
> Oh bother. I?d forgotten about dependencies. I don?t want to make building
> nofib depend on libraries other those in GHC anyway (bytestring, unix ok,
> asynch perhaps not).  If that makes it tricky, maybe we should give up on
> the idea.****
>
> ** **
>
> S****
>
> ** **
>
> *From:* Jos? Pedro Magalh?es [mailto:jose.pedro.magalhaes at cs.ox.ac.uk]
> *Sent:* 05 August 2013 08:41
> *To:* Simon Peyton-Jones
> *Subject:* Re: lambda mining****
>
> ** **
>
> I'm not entirely sure how to do that, though. Do I just add it to the
> "real" subset?
> How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >=
> 2.0.0.0, ...)
>
>
> Cheers,
> Pedro****
>
> On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:****
>
>  great!  Just add it :-)****
>
>
> simon****
>
>  ****
>
> *From:* Jos? Pedro Magalh?es [mailto:jpm at cs.ox.ac.uk]
> *Sent:* 30 July 2013 07:48
> *To:* Simon Peyton-Jones
> *Cc:* Nicolas Wu; Wouter Swierstra; Jeroen Bransen
> *Subject:* Re: lambda mining****
>
>  ****
>
> Hi Simon,
>
> (CC-ing co-authors)
>
> Yes, I think it might work fine. Its running time can also be adjusted
> easily, depending on the maps
> given as input and some internal parameters. How would we go about adding
> it to nofib?
>
>
> Thanks,
> Pedro****
>
> On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:****
>
> Pedro****
>
>  ****
>
> Wandering past your home page I took a look at your ?lambda mining?
> paper.  Would it be suitable as a nofib benchmark? Moderate size, authentic
> code...  Would you be interested?****
>
>  ****
>
> Simon****
>
>  ****
>
>  ** **
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>


--
Regards,
Austin - PGP: 4096R/0x91384671
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130816/872d7191/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

lambda mining

Austin Seipp-4
I just pushed support for external repositories in ./sync-all, but
didn't add async. It makes it easy to do so, however (and the patch is
small and lightweight.)

Jos?, if async is all you're missing, I can add it to the 'extra'
repositories, and then it should be reasonably straightforward to add
it to nofib as an extra benchmark, I think.

On Fri, Aug 16, 2013 at 1:26 PM, Austin Seipp <aseipp at pobox.com> wrote:

> IMO, it's reasonable to allow this, but there's one minor sticky bit.
>
> async's only dependency is stm, and it's also part of the platform, so I
> expect it will be relatively stable. In this case, perhaps we should just
> add 'async' to the set of 'extra' libraries for ./sync-all, which can be
> built with the compiler. Then, it should be easy to add tests for nofib (and
> even testsuite, if people find bugs.) stm is already one of the 'extra'
> libraries, and there are a few smp benchmarks that use it too, so this
> doesn't really change anything in that regard.
>
> The main thing is that async isn't under our normal package structure, so
> we'll either need to A) mirror it, or B) we need to add support for
> ./sync-all to sync with an arbitrary HTTP url or something, and point it to
> Simon's repository as an extra package.
>
> I'm in favor of 2 since then we don't have to maintain an unnecessary
> mirror, and also, because it might be useful later for similar things.
>
> Thoughts?
>
> On Fri, Aug 16, 2013 at 6:58 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>>
>> (devs: this thread is about adding useful new benchmarks to nofib.)
>>
>>
>>
>> Oh bother. I?d forgotten about dependencies. I don?t want to make building
>> nofib depend on libraries other those in GHC anyway (bytestring, unix ok,
>> asynch perhaps not).  If that makes it tricky, maybe we should give up on
>> the idea.
>>
>>
>>
>> S
>>
>>
>>
>> From: Jos? Pedro Magalh?es [mailto:jose.pedro.magalhaes at cs.ox.ac.uk]
>> Sent: 05 August 2013 08:41
>> To: Simon Peyton-Jones
>> Subject: Re: lambda mining
>>
>>
>>
>> I'm not entirely sure how to do that, though. Do I just add it to the
>> "real" subset?
>> How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >=
>> 2.0.0.0, ...)
>>
>>
>> Cheers,
>> Pedro
>>
>> On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj at microsoft.com>
>> wrote:
>>
>> great!  Just add it :-)
>>
>>
>> simon
>>
>>
>>
>> From: Jos? Pedro Magalh?es [mailto:jpm at cs.ox.ac.uk]
>> Sent: 30 July 2013 07:48
>> To: Simon Peyton-Jones
>> Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen
>> Subject: Re: lambda mining
>>
>>
>>
>> Hi Simon,
>>
>> (CC-ing co-authors)
>>
>> Yes, I think it might work fine. Its running time can also be adjusted
>> easily, depending on the maps
>> given as input and some internal parameters. How would we go about adding
>> it to nofib?
>>
>>
>> Thanks,
>> Pedro
>>
>> On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones
>> <simonpj at microsoft.com> wrote:
>>
>> Pedro
>>
>>
>>
>> Wandering past your home page I took a look at your ?lambda mining? paper.
>> Would it be suitable as a nofib benchmark? Moderate size, authentic code...
>> Would you be interested?
>>
>>
>>
>> Simon
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671



--
Regards,
Austin - PGP: 4096R/0x91384671



Reply | Threaded
Open this post in threaded view
|

lambda mining

José Pedro Magalhães
Hi,

Here are the complete dependencies:

  Build-depends: base >= 4 && < 5,
                 array >= 0.4,
                 mtl >= 2.0.0.0,
                 ansi-terminal,
                 containers,
                 old-time >= 1.1,
                 directory >= 1.1,
                 filepath >= 1.3,
                 attoparsec >= 0.10,
                 bytestring >= 0.9,
                 parallel-io >= 0.3.2,
                 hashable >= 1.1,
                 unordered-containers >= 0.2,
                 pqueue >= 1.2.0,
                 unix >= 2.5.0,
                 async >= 2.0.0.0,
                 deepseq >= 1.1.0.0

Anything too problematic?


Thanks,
Pedro



On Sun, Aug 18, 2013 at 6:48 PM, Austin Seipp <aseipp at pobox.com> wrote:

> I just pushed support for external repositories in ./sync-all, but
> didn't add async. It makes it easy to do so, however (and the patch is
> small and lightweight.)
>
> Jos?, if async is all you're missing, I can add it to the 'extra'
> repositories, and then it should be reasonably straightforward to add
> it to nofib as an extra benchmark, I think.
>
> On Fri, Aug 16, 2013 at 1:26 PM, Austin Seipp <aseipp at pobox.com> wrote:
> > IMO, it's reasonable to allow this, but there's one minor sticky bit.
> >
> > async's only dependency is stm, and it's also part of the platform, so I
> > expect it will be relatively stable. In this case, perhaps we should just
> > add 'async' to the set of 'extra' libraries for ./sync-all, which can be
> > built with the compiler. Then, it should be easy to add tests for nofib
> (and
> > even testsuite, if people find bugs.) stm is already one of the 'extra'
> > libraries, and there are a few smp benchmarks that use it too, so this
> > doesn't really change anything in that regard.
> >
> > The main thing is that async isn't under our normal package structure, so
> > we'll either need to A) mirror it, or B) we need to add support for
> > ./sync-all to sync with an arbitrary HTTP url or something, and point it
> to
> > Simon's repository as an extra package.
> >
> > I'm in favor of 2 since then we don't have to maintain an unnecessary
> > mirror, and also, because it might be useful later for similar things.
> >
> > Thoughts?
> >
> > On Fri, Aug 16, 2013 at 6:58 AM, Simon Peyton-Jones <
> simonpj at microsoft.com>
> > wrote:
> >>
> >> (devs: this thread is about adding useful new benchmarks to nofib.)
> >>
> >>
> >>
> >> Oh bother. I?d forgotten about dependencies. I don?t want to make
> building
> >> nofib depend on libraries other those in GHC anyway (bytestring, unix
> ok,
> >> asynch perhaps not).  If that makes it tricky, maybe we should give up
> on
> >> the idea.
> >>
> >>
> >>
> >> S
> >>
> >>
> >>
> >> From: Jos? Pedro Magalh?es [mailto:jose.pedro.magalhaes at cs.ox.ac.uk]
> >> Sent: 05 August 2013 08:41
> >> To: Simon Peyton-Jones
> >> Subject: Re: lambda mining
> >>
> >>
> >>
> >> I'm not entirely sure how to do that, though. Do I just add it to the
> >> "real" subset?
> >> How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >=
> >> 2.0.0.0, ...)
> >>
> >>
> >> Cheers,
> >> Pedro
> >>
> >> On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <
> simonpj at microsoft.com>
> >> wrote:
> >>
> >> great!  Just add it :-)
> >>
> >>
> >> simon
> >>
> >>
> >>
> >> From: Jos? Pedro Magalh?es [mailto:jpm at cs.ox.ac.uk]
> >> Sent: 30 July 2013 07:48
> >> To: Simon Peyton-Jones
> >> Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen
> >> Subject: Re: lambda mining
> >>
> >>
> >>
> >> Hi Simon,
> >>
> >> (CC-ing co-authors)
> >>
> >> Yes, I think it might work fine. Its running time can also be adjusted
> >> easily, depending on the maps
> >> given as input and some internal parameters. How would we go about
> adding
> >> it to nofib?
> >>
> >>
> >> Thanks,
> >> Pedro
> >>
> >> On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones
> >> <simonpj at microsoft.com> wrote:
> >>
> >> Pedro
> >>
> >>
> >>
> >> Wandering past your home page I took a look at your ?lambda mining?
> paper.
> >> Would it be suitable as a nofib benchmark? Moderate size, authentic
> code...
> >> Would you be interested?
> >>
> >>
> >>
> >> Simon
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >
> >
> >
> > --
> > Regards,
> > Austin - PGP: 4096R/0x91384671
>
>
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130819/491ade40/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

lambda mining

Simon Peyton Jones
I don't think it's worth dragging all that in for one benchmark.

That said, Nofib is our main performance regression suite, so the more representative it is the better, and the less likely we are to accidently optimise for the wrong thing.

If we had a bunch of new benchmark programs (which I would love) then it might well make sense to install more libraries with them -- if anyone feels like helping with that.

Simon

From: josepedromagalhaes at gmail.com [mailto:josepedromagalhaes at gmail.com] On Behalf Of Jos? Pedro Magalh?es
Sent: 19 August 2013 14:17
To: Austin Seipp
Cc: Simon Peyton-Jones; ghc-devs
Subject: Re: lambda mining

Hi,
Here are the complete dependencies:

  Build-depends: base >= 4 && < 5,
                 array >= 0.4,
                 mtl >= 2.0.0.0,
                 ansi-terminal,
                 containers,
                 old-time >= 1.1,
                 directory >= 1.1,
                 filepath >= 1.3,
                 attoparsec >= 0.10,
                 bytestring >= 0.9,
                 parallel-io >= 0.3.2,
                 hashable >= 1.1,
                 unordered-containers >= 0.2,
                 pqueue >= 1.2.0,
                 unix >= 2.5.0,
                 async >= 2.0.0.0,
                 deepseq >= 1.1.0.0
Anything too problematic?


Thanks,
Pedro

On Sun, Aug 18, 2013 at 6:48 PM, Austin Seipp <aseipp at pobox.com<mailto:aseipp at pobox.com>> wrote:
I just pushed support for external repositories in ./sync-all, but
didn't add async. It makes it easy to do so, however (and the patch is
small and lightweight.)

Jos?, if async is all you're missing, I can add it to the 'extra'
repositories, and then it should be reasonably straightforward to add
it to nofib as an extra benchmark, I think.

On Fri, Aug 16, 2013 at 1:26 PM, Austin Seipp <aseipp at pobox.com<mailto:aseipp at pobox.com>> wrote:

> IMO, it's reasonable to allow this, but there's one minor sticky bit.
>
> async's only dependency is stm, and it's also part of the platform, so I
> expect it will be relatively stable. In this case, perhaps we should just
> add 'async' to the set of 'extra' libraries for ./sync-all, which can be
> built with the compiler. Then, it should be easy to add tests for nofib (and
> even testsuite, if people find bugs.) stm is already one of the 'extra'
> libraries, and there are a few smp benchmarks that use it too, so this
> doesn't really change anything in that regard.
>
> The main thing is that async isn't under our normal package structure, so
> we'll either need to A) mirror it, or B) we need to add support for
> ./sync-all to sync with an arbitrary HTTP url or something, and point it to
> Simon's repository as an extra package.
>
> I'm in favor of 2 since then we don't have to maintain an unnecessary
> mirror, and also, because it might be useful later for similar things.
>
> Thoughts?
>
> On Fri, Aug 16, 2013 at 6:58 AM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> wrote:
>>
>> (devs: this thread is about adding useful new benchmarks to nofib.)
>>
>>
>>
>> Oh bother. I'd forgotten about dependencies. I don't want to make building
>> nofib depend on libraries other those in GHC anyway (bytestring, unix ok,
>> asynch perhaps not).  If that makes it tricky, maybe we should give up on
>> the idea.
>>
>>
>>
>> S
>>
>>
>>
>> From: Jos? Pedro Magalh?es [mailto:jose.pedro.magalhaes at cs.ox.ac.uk<mailto:jose.pedro.magalhaes at cs.ox.ac.uk>]
>> Sent: 05 August 2013 08:41
>> To: Simon Peyton-Jones
>> Subject: Re: lambda mining
>>
>>
>>
>> I'm not entirely sure how to do that, though. Do I just add it to the
>> "real" subset?
>> How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >=
>> 2.0.0.0, ...)
>>
>>
>> Cheers,
>> Pedro
>>
>> On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
>> wrote:
>>
>> great!  Just add it :-)
>>
>>
>> simon
>>
>>
>>
>> From: Jos? Pedro Magalh?es [mailto:jpm at cs.ox.ac.uk<mailto:jpm at cs.ox.ac.uk>]
>> Sent: 30 July 2013 07:48
>> To: Simon Peyton-Jones
>> Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen
>> Subject: Re: lambda mining
>>
>>
>>
>> Hi Simon,
>>
>> (CC-ing co-authors)
>>
>> Yes, I think it might work fine. Its running time can also be adjusted
>> easily, depending on the maps
>> given as input and some internal parameters. How would we go about adding
>> it to nofib?
>>
>>
>> Thanks,
>> Pedro
>>
>> On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones
>> <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
>>
>> Pedro
>>
>>
>>
>> Wandering past your home page I took a look at your "lambda mining" paper.
>> Would it be suitable as a nofib benchmark? Moderate size, authentic code...
>> Would you be interested?
>>
>>
>>
>> Simon
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671



--
Regards,
Austin - PGP: 4096R/0x91384671

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130819/8f134924/attachment.htm>