1. 23 Sep, 2013 1 commit
  2. 16 Sep, 2013 1 commit
  3. 15 Sep, 2013 1 commit
  4. 08 Sep, 2013 2 commits
  5. 04 Sep, 2013 1 commit
  6. 21 Aug, 2013 5 commits
  7. 06 Aug, 2013 1 commit
  8. 16 Jul, 2013 1 commit
  9. 13 Jul, 2013 1 commit
  10. 10 Jul, 2013 2 commits
  11. 09 Jul, 2013 1 commit
  12. 22 Jun, 2013 2 commits
  13. 17 Jun, 2013 1 commit
  14. 15 Jun, 2013 3 commits
  15. 14 Jun, 2013 1 commit
  16. 08 Jun, 2013 1 commit
  17. 06 Jun, 2013 1 commit
    • Simon Peyton Jones's avatar
      Implement cardinality analysis · 99d4e5b4
      Simon Peyton Jones authored
      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.
      99d4e5b4
  18. 21 May, 2013 1 commit
  19. 19 May, 2013 1 commit
  20. 17 May, 2013 1 commit
  21. 10 May, 2013 1 commit
  22. 19 Apr, 2013 1 commit
  23. 11 Apr, 2013 1 commit
  24. 29 Mar, 2013 1 commit
    • nfrisby's avatar
      ticky enhancements · 460abd75
      nfrisby authored
        * the new StgCmmArgRep module breaks a dependency cycle; I also
          untabified it, but made no real changes
      
        * updated the documentation in the wiki and change the user guide to
          point there
      
        * moved the allocation enters for ticky and CCS to after the heap check
      
          * I left LDV where it was, which was before the heap check at least
            once, since I have no idea what it is
      
        * standardized all (active?) ticky alloc totals to bytes
      
        * in order to avoid double counting StgCmmLayout.adjustHpBackwards
          no longer bumps ALLOC_HEAP_ctr
      
        * I resurrected the SLOW_CALL counters
      
          * the new module StgCmmArgRep breaks cyclic dependency between
            Layout and Ticky (which the SLOW_CALL counters cause)
      
          * renamed them SLOW_CALL_fast_<pattern> and VERY_SLOW_CALL
      
        * added ALLOC_RTS_ctr and _tot ticky counters
      
          * eg allocation by Storage.c:allocate or a BUILD_PAP in stg_ap_*_info
      
          * resurrected ticky counters for ALLOC_THK, ALLOC_PAP, and
            ALLOC_PRIM
      
          * added -ticky and -DTICKY_TICKY in ways.mk for debug ways
      
        * added a ticky counter for total LNE entries
      
        * new flags for ticky: -ticky-allocd -ticky-dyn-thunk -ticky-LNE
      
          * all off by default
      
          * -ticky-allocd: tracks allocation *of* closure in addition to
             allocation *by* that closure
      
          * -ticky-dyn-thunk tracks dynamic thunks as if they were functions
      
          * -ticky-LNE tracks LNEs as if they were functions
      
        * updated the ticky report format, including making the argument
          categories (more?) accurate again
      
        * the printed name for things in the report include the unique of
          their ticky parent as well as if they are not top-level
      460abd75
  25. 07 Mar, 2013 1 commit
  26. 03 Mar, 2013 1 commit
  27. 26 Feb, 2013 1 commit
  28. 18 Feb, 2013 1 commit
  29. 14 Feb, 2013 2 commits
    • Simon Marlow's avatar
      Separate StablePtr and StableName tables (#7674) · 7e7a4e4d
      Simon Marlow authored
      To improve performance of StablePtr.
      7e7a4e4d
    • Simon Marlow's avatar
      Simplify the allocation stats accounting · 65a0e1eb
      Simon Marlow authored
      We were doing it in two different ways and asserting that the results
      were the same.  In most cases they were, but I found one case where
      they weren't: the GC itself allocates some memory for running
      finalizers, and this memory was accounted for one way but not the
      other.
      
      It was simpler to remove the old way of counting allocation that to
      try to fix it up, so I did that.
      65a0e1eb
  30. 12 Feb, 2013 1 commit