Changes between Version 15 and Version 16 of NestedCPR


Ignore:
Timestamp:
Jan 8, 2014 12:17:03 PM (19 months ago)
Author:
nomeata
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NestedCPR

    v15 v16  
    2929=== Degradation explanation ===
    3030
    31 At one point, I thought that a major contributor to increased allocations is nested-CPR’ing things returning `String`, causing them to return `(# Char#, String #)`. But removing the `CPR` information from `C#` calls has zero effect on the allocations, both on `master` and on `nested-cpr`. It had very small (positive) effect on code size. Will have to look at Core...
     31At one point, I thought that a major contributor to increased allocations is nested-CPR’ing things returning `String`, causing them to return `(# Char#, String #)`. But removing the `CPR` information from `C#` calls has zero effect on the allocations, both on `master` and on `nested-cpr`. It had very small (positive) effect on code size. Will have to look at Core... Here are some case studies:
     32
     33==== wave4main ====
     34
     35Baseline: [0e2fd3/ghc], Tested: nested-cpr (without nesting inside sum-types, without join-point detection).
     36
     37Found a 11% increase in allocation, around `9000000` bytes.
     38
     39The most obvious change in ticky-ticky-number are:
     40 * `FUNCTION ENTRIES` and `ENTERS` increasing by ~100000
     41 * `RETURNS` doubling from 140745 to 280795
     42 *  `ALLOC_FUN_ctr` and `ALLOC_FUN_gds` almost doubling, by ~18000 resp. 9000000
     43So we are allocating more function closures. First guess: Join point property destroyed somewhere.
     44
     45The ticky output shows a `$wgo{v s60k} (main:Main)` appearing that was not there before, with `140016` enters and `23522688` allocations. This appears in `$wtabulate`, and indeed corresponds to a `go1` that is a join-point before. So what is happening? We are changing
     46{{{
     47go1 [Occ=LoopBreaker]                                     
     48  :: GHC.Prim.Int#                                         
     49     -> GHC.Prim.State# s                                 
     50     -> (# GHC.Prim.State# s, GHC.Arr.Array GHC.Types.Int x #)
     51}}}
     52to
     53{{{
     54$wgo [Occ=LoopBreaker]         
     55  :: GHC.Prim.Int#
     56     -> GHC.Prim.State# s
     57     -> (# GHC.Prim.State# s,   
     58           GHC.Prim.Int#,       
     59           GHC.Prim.Int#,       
     60           GHC.Prim.Int#,       
     61           GHC.Prim.Array# x #)
     62}}}
     63
     64`go1` is recursive, but tail-recursive, so the worker and wrapper indeed cancel for the recursive call. But where it is being used, we simply apply the `Array` constructor to the second component. So nothing is gained, but a join-point is lost.
     65
    3266
    3367=== join points ===