Changes between Version 15 and Version 16 of NestedCPR


Ignore:
Timestamp:
Jan 8, 2014 12:17:03 PM (16 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 ===