GHC Performance Tsar

[Tim Watson]

Could we not configure travis-ci to run the benchmarks for us or something like that? A simple (free) ci setup would be easier than finding a pair of hands to do this regularly I would've thought.

On 30 Nov 2012, at 14:42, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> | > While writing a new nofib benchmark today I found myself wondering
> | > whether all the nofib benchmarks are run just before each release,
> 
> I think we could do with a GHC Performance Tsar.  Especially now that Simon has changed jobs, we need to try even harder to broaden the base of people who help with GHC.  It would be amazing to have someone who was willing to:
> 
> * Run nofib benchmarks regularly, and publish the results
> 
> * Keep baseline figures for GHC 7.6, 7.4, etc so we can keep
>   track of regressions
> 
> * Investigate regressions to see where they come from; ideally
>   propose fixes.
> 
> * Extend nofib to contain more representative programs (as Johan is
>   currently doing).
> 
> That would help keep us on the straight and narrow.  
> 
> Any offers?  It could be more than one person.
>    
> Simon
> 
> | -----Original Message-----
> | From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-
> | users-bounces at haskell.org] On Behalf Of Simon Marlow
> | Sent: 30 November 2012 12:11
> | To: Johan Tibell
> | Cc: glasgow-haskell-users
> | Subject: Re: Is the GHC release process documented?
> | 
> | On 30/11/12 03:54, Johan Tibell wrote:
> | > While writing a new nofib benchmark today I found myself wondering
> | > whether all the nofib benchmarks are run just before each release,
> | > which the drove me to go look for a document describing the release
> | > process. A quick search didn't turn up anything, so I thought I'd ask
> | > instead. Is there a documented GHC release process? Does it include
> | > running nofib? If not, may I propose that we do so before each release
> | > and compare the result to the previous release*.
> | >
> | > * This likely means that nofib has to be run for the upcoming release
> | > and the prior release each time a release is made, as numbers don't
> | > translate well between machines so storing the results somewhere is
> | > likely not that useful.
> | 
> | I used to do this on an ad-hoc basis: the nightly builds at MSR spit out
> | nofib results that I compared against previous releases.
> | 
> | In practice you want to do this much earlier than just before a release,
> | because it can take time to investigate and squash any discrepancies.
> | 
> | On the subject of the release process, I believe Ian has a checklist
> | that he keeps promising to put on the wiki (nudge :)).
> | 
> | Cheers,
> |    Simon
> | 
> | 
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users