Skip to content
Snippets Groups Projects
  1. Jun 05, 2012
  2. Jun 01, 2012
  3. May 30, 2012
    • Ian Lynagh's avatar
      MERGE: Be less aggressive about the result discount · 46949a12
      Ian Lynagh authored
      Merge of:
          commit 4fa3f16d
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Mon May 28 17:33:42 2012 +0100
      
      Be less aggressive about the result discount
      
      This patch fixes Trac #6099 by reducing the result discount in CoreUnfold.conSize.
      See Note [Constructor size and result discount] in CoreUnfold.
      
      The existing version is definitely too aggressive. Simon M found it an
      "unambiguous win" but it is definitely what led to the bloat. In a function
      with a lot of case branches, all returning a constructor, the discount could
      grow arbitrarily large.
      
      I also had to increase the -funfolding-creation-threshold from 450 to 750,
      otherwise some functions that should inline simply never get an unfolding.
      (The massive result discount was allow the unfolding to appear before.)
      
      The nofib results are these, picking a handful of outliers to show.
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
               fulsom          -0.5%     -1.6%     -2.8%     -2.6%    +31.1%
             maillist          -0.2%     -0.0%      0.09      0.09     -3.7%
               mandel          -0.4%     +6.6%      0.12      0.12     +0.0%
             nucleic2          -0.2%    +18.5%      0.11      0.11     +0.0%
              parstof          -0.4%     +4.0%      0.00      0.00     +0.0%
      --------------------------------------------------------------------------------
                  Min          -0.9%     -1.6%    -19.7%    -19.7%     -3.7%
                  Max          +0.3%    +18.5%     +2.7%     +2.7%    +31.1%
       Geometric Mean          -0.3%     +0.4%     -3.0%     -3.0%     +0.2%
      
      Turns out that nucleic2 has a function
        Main.$wabsolute_pos =
          \ (ww_s4oj :: Types.Tfo) (ww1_s4oo :: Types.FloatT)
            (ww2_s4op :: Types.FloatT) (ww3_s4oq :: Types.FloatT) ->
            case ww_s4oj
            of _
            { Types.Tfo a_a1sS b_a1sT c_a1sU d_a1sV e_a1sW f_a1sX g_a1sY h_a1sZ i_a1t0 tx_a1t1 ty_a1t2 tz_a1t3 ->
            (# case ww1_s4oo of _ { GHC.Types.F# x_a2sO ->
               case a_a1sS of _ { GHC.Types.F# y_a2sS ->
               case ww2_s4op of _ { GHC.Types.F# x1_X2y9 ->
               case d_a1sV of _ { GHC.Types.F# y1_X2yh ->
               case ww3_s4oq of _ { GHC.Types.F# x2_X2yj ->
               case g_a1sY of _ { GHC.Types.F# y2_X2yr ->
               case tx_a1t1 of _ { GHC.Types.F# y3_X2yn ->
               GHC.Types.F#
                 (GHC.Prim.plusFloat#
                    (GHC.Prim.plusFloat#
                       (GHC.Prim.plusFloat#
                          (GHC.Prim.timesFloat# x_a2sO y_a2sS)
                          (GHC.Prim.timesFloat# x1_X2y9 y1_X2yh))
                       (GHC.Prim.timesFloat# x2_X2yj y2_X2yr))
                    y3_X2yn)
               } } }}}}},
      
              <similar>,
              <similar> )
      
      This is pretty big, but inlining it does get rid of that F# allocation.
      But we'll also get rid of it with deep CPR: Trac #2289. For now we just
      accept the change.
      46949a12
  4. May 16, 2012
  5. May 08, 2012
  6. May 03, 2012
  7. Apr 27, 2012
  8. Apr 26, 2012
    • Simon Peyton Jones's avatar
      Fix worker/wrapper for CPR functions · adc47ae7
      Simon Peyton Jones authored and pcapriotti's avatar pcapriotti committed
      A long-standing and egregious bug in the worker/wrapper code meant
      that some functions with the CPR property weren't getting a CPR
      w/w. And that had the effect of making a tail-recursive function not
      tail recursive.  As well as increasing allocation.
      
      Fixes Trac #5920, and #5997.
      
      Nofib results (highlights):
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
               boyer2          -0.1%    -15.3%      0.01      0.01     +0.0%
              mandel2          -0.0%     -8.1%      0.01      0.01     +0.0%
                 para          -0.1%    -11.8%     -7.9%     -7.8%     +0.0%
      --------------------------------------------------------------------------------
                  Min          -0.1%    -15.3%     -7.9%     -7.8%    -33.3%
                  Max          +0.0%     +0.2%     +6.3%     +6.3%     +3.7%
       Geometric Mean          -0.0%     -0.4%     +0.1%     +0.1%     -0.5%
      
      Looks like a clear win.  And I have not even recompiled the libraries, so
      it'll probably be a bit better in the ed.
      
      MERGED from commit b8ff4448
      adc47ae7
  9. Apr 16, 2012
  10. Apr 12, 2012
  11. Apr 06, 2012
  12. Apr 02, 2012
  13. Apr 01, 2012
    • Simon Marlow's avatar
      Fix a bug in threadStackOverflow() (maybe #5214) · 20906163
      Simon Marlow authored and pcapriotti's avatar pcapriotti committed
      If we overflow the current stack chunk and copy its entire contents
      into the next stack chunk, we could end up with two UNDERFLOW_FRAMEs.
      We had a special case to catch this in the case when the old stack
      chunk was the last one (ending in STOP_FRAME), but it went wrong for
      other chunks.
      
      I found this bug while poking around in the core dump attached to
      options and running the nofib suite: imaginary/wheel_sieve2 crashed
      with +RTS -kc600 -kb300.
      
      I don't know if this is the cause of all the symptoms reported in
      
      MERGED from commit 734f1d48
      20906163
  14. Mar 31, 2012
  15. Mar 30, 2012
    • pcapriotti's avatar
      Update documentation of DatatypeContexts (#5964) · e21fada0
      pcapriotti authored
      MERGED from commit ac2fbb4f
      e21fada0
    • Ben Gamari's avatar
      Add linker support for ELF on ARM · 27302c90
      Ben Gamari authored and pcapriotti's avatar pcapriotti committed
      
      Add support for ELF objects on ARM to the runtime linker. While the list of
      relocation types in the "ELF for the ARM Architecture" specification spans four
      pages, we thankfully only see a handful of these in the wild. Thus, at the
      moment we only support the following .rel relocation types,
      
       * R_ARM_ABS32
       * R_ARM_TARGET1
       * R_ARM_REL32
       * R_ARM_CALL
       * R_ARM_JUMP24
       * R_ARM_MOVT_ABS
       * R_ARM_MOVW_ABS_NC
       * R_ARM_THM_CALL
       * R_ARM_THM_JUMP24
       * R_ARM_THM_MOVT_ABS
       * R_ARM_THM_MOVW_ABS_NC
       * R_ARM_THM_JUMP8
       * R_ARM_THM_JUMP11
      
      Signed-off-by: default avatarBen Gamari <bgamari.foss@gmail.com>
      
      MERGED from commit b22501b4
      27302c90
  16. Mar 28, 2012
  17. Mar 26, 2012
  18. Mar 23, 2012
Loading