[commit: ghc] master: SpecConstr: seed specialisation of top-level bindings, as with letrecs. (8a58851)

[Amos Robinson]

I did, though I didn't include the nofib details (I imagine it'll go out of
date anyway)
I also remembered to add the note about limiting recursive specialising
that I'd had sitting in my repo for a while but had forgotten to commit


On Wed, May 15, 2013 at 11:03 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

> Cool!  Did you comment the change with a Note [Seed specialisation of
> top-level bindings] inside SpecContr itself?  (You could use more or less
> the text below.)
>
> Simon
>
> | -----Original Message-----
> | From: ghc-commits-bounces at haskell.org [mailto:ghc-commits-
> | bounces at haskell.org] On Behalf Of Amos Robinson
> | Sent: 15 May 2013 13:47
> | To: ghc-commits at haskell.org
> | Subject: [commit: ghc] master: SpecConstr: seed specialisation of top-
> | level bindings, as with letrecs. (8a58851)
> |
> | Repository : http://darcs.haskell.org/ghc.git/
> |
> | On branch  : master
> |
> | https://github.com/ghc/ghc/commit/8a58851150af11020140256bbd7c6d5359e020
> | ee
> |
> | >---------------------------------------------------------------
> |
> | commit 8a58851150af11020140256bbd7c6d5359e020ee
> | Author: Amos Robinson <amos.robinson at gmail.com>
> | Date:   Wed May 15 22:15:56 2013 +1000
> |
> |     SpecConstr: seed specialisation of top-level bindings, as with
> | letrecs.
> |
> |     When specialising a top-level recursive group, if none of the
> | binders
> |     are exported then we can start specialising based on the later calls
> | to
> |     the functions.
> |     This is instead of creating specialisations based on the RHS of the
> |     bindings.
> |     The main benefit of this is that only specialisations that will
> | actually
> |     be used are created. This saves quite a bit of memory when compiling
> |     stream-fusion and ForceSpecConstr sort of code.
> |
> |     Nofib has an average allocation and runtime of -0.7%, maximum 2%.
> |     There are a few with significant decreases in allocation (10 - 20%)
> |     but, interestingly, those ones seem to have similar runtimes.
> |     One of these does have a significantly reduced total elapsed time
> |     though: -38%.
> |
> |     On average the nofib compilation times are the same, but they do
> | vary
> |     with s.d. of -4 to 4%.
> |     I think this is acceptable because of the fairly major code blowup
> | fixes
> |     this has for fusion-style code.
> |     (In one example, a SpecConstr was previously producing 122,000 term
> | size,
> |     now only produces 28,000 with the same object code)
> |
> |  compiler/specialise/SpecConstr.lhs | 142 +++++++++++++++++++++++++++++-
> | -------
> |  1 file changed, 113 insertions(+), 29 deletions(-)
> |
> |
> | Diff suppressed because of size. To see it, use:
> |
> |     git show 8a58851150af11020140256bbd7c6d5359e020ee
> |
> | _______________________________________________
> | ghc-commits mailing list
> | ghc-commits at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-commits
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130515/3da0a16a/attachment.htm>