[GHC] #7520: Implement cardinality analysis

GHC ghc-devs at haskell.org
Fri Aug 23 10:50:59 UTC 2013


#7520: Implement cardinality analysis
-------------------------------------+------------------------------------
        Reporter:  simonpj           |            Owner:
            Type:  bug               |           Status:  closed
        Priority:  normal            |        Milestone:  7.8.1
       Component:  Compiler          |          Version:  7.6.1
      Resolution:  fixed             |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------
Changes (by thoughtpolice):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This was merged back in May.

 {{{
 commit 99d4e5b4a0bd32813ff8c74e91d2dcf6b3555176
 Author: Simon Peyton Jones <simonpj at microsoft.com>
 Date:   Fri May 3 14:50:58 2013 +0100

     Implement cardinality analysis

     This major patch implements the cardinality analysis described
     in our paper "Higher order cardinality analysis". It is joint
     work with Ilya Sergey and Dimitrios Vytiniotis.

     The basic is augment the absence-analysis part of the demand
     analyser so that it can tell when something is used
          never
          at most once
          some other way

     The "at most once" information is used
         a) to enable transformations, and
            in particular to identify one-shot lambdas
         b) to allow updates on thunks to be omitted.

     There are two new flags, mainly there so you can do performance
     comparisons:
         -fkill-absence   stops GHC doing absence analysis at all
         -fkill-one-shot  stops GHC spotting one-shot lambdas
                          and single-entry thunks

     The big changes are:

     * The Demand type is substantially refactored.  In particular
       the UseDmd is factored as follows
           data UseDmd
             = UCall Count UseDmd
             | UProd [MaybeUsed]
             | UHead
             | Used

           data MaybeUsed = Abs | Use Count UseDmd

           data Count = One | Many

       Notice that UCall recurses straight to UseDmd, whereas
       UProd goes via MaybeUsed.

       The "Count" embodies the "at most once" or "many" idea.

     * The demand analyser itself was refactored a lot

     * The previously ad-hoc stuff in the occurrence analyser for foldr and
       build goes away entirely.  Before if we had build (\cn -> ...x... )
       then the "\cn" was hackily made one-shot (by spotting 'build' as
       special.  That's essential to allow x to be inlined.  Now the
       occurrence analyser propagates info gotten from 'build's stricness
       signature (so build isn't special); and that strictness sig is
       in turn derived entirely automatically.  Much nicer!

     * The ticky stuff is improved to count single-entry thunks separately.

     One shortcoming is that there is no DEBUG way to spot if an
     allegedly-single-entry thunk is acually entered more than once.  It
     would not be hard to generate a bit of code to check for this, and it
     would be reassuring.  But it's fiddly and I have not done it.

     Despite all this fuss, the performance numbers are rather under-
 whelming.
     See the paper for more discussion.

            nucleic2          -0.8%    -10.9%      0.10      0.10     +0.0%
              sphere          -0.7%     -1.5%      0.08      0.08     +0.0%
 --------------------------------------------------------------------------------
                 Min          -4.7%    -10.9%     -9.3%     -9.3%    -50.0%
                 Max          -0.4%     +0.5%     +2.2%     +2.3%     +7.4%
      Geometric Mean          -0.8%     -0.2%     -1.3%     -1.3%     -1.8%

     I don't quite know how much credence to place in the runtime changes,
     but movement seems generally in the right direction.
 }}}

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7520#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler




More information about the ghc-tickets mailing list