Changes between Version 4 and Version 5 of Frisby2013Q1


Ignore:
Timestamp:
Feb 7, 2013 6:30:13 PM (2 years ago)
Author:
nfrisby
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Frisby2013Q1

    v4 v5  
    117117We discovered that the worker-wrapper was removing the void argument from join points (eg knights and mandel2). This ultimately resulted in LLF *increasing* allocation. A thunk was let-no-escape before LLF but not after, since it occurred free in the right-hand side of a floated binding and hence now occurred (escapingly) as an argument. 
    118118 
    119 SPJ was expecting no such non-lambda join points to exist. We identified where it was happening (WwLib.mkWorkerArgs) and switched it off. 
     119SPJ was expecting no such non-lambda join points to exist. We identified where it was happening (WwLib.mkWorkerArgs) and switched it off. Here are the programs that with affected allocation. 
    120120 
    121121{{{ 
     
    125125protect-yes = protect the last value argument from being removed 
    126126              (ie the experimental behavior) 
     127 
     128Both are applied to both the libraries and the program. 
    127129 
    128130Allocations 
     
    135137            scs           1029909256           -0.1% 
    136138      transform            738757608           -0.1% 
    137       cacheprof            479313187           -0.1% 
     139      cacheprof            478120432           +0.3% 
    138140       listcopy            334710912           -0.4% 
    139141  comp_lab_zift            330889440           -5.0% 
     
    144146         parser             32406448           +0.2% 
    145147             gg              8970344           -0.2% 
     148 
    146149        -1 s.d.                -----           -0.6% 
    147150        +1 s.d.                -----           +0.5% 
    148151        Average                -----           -0.1% 
    149  
    150 Run Time 
    151  
    152 ------------------------------------------------------------------------------- 
    153         Program           protect-no     protect-yes 
    154 ------------------------------------------------------------------------------- 
    155     constraints                 5.23           -9.6% 
    156         integer                 2.63           +1.8% 
    157         circsim                 1.73           +1.2% 
    158           power                 1.18           +1.0% 
    159        maillist                 0.49          -16.9% 
    160    wheel-sieve2                 0.37          +11.5% 
    161       integrate                 0.35          +26.0% 
    162  
    163         -1 s.d.                -----           -6.5% 
    164         +1 s.d.                -----           +6.8% 
    165         Average                -----           -0.1% 
    166152}}} 
    167153 
    168 I'm now investigating further. 
     154In circsim, put gets 1,000,000 better and Text.Read.Lex gets a tiny bit better. 
     155 
     156In hidden, it's Text.Read.Lex, Text.ParserCombinators.ReadP, and GHC.Read. 
     157 
     158In cacheprof, $wpreparseline gets a bit worse. 
     159 
     160In comp_lab_zift: f_make_tree gets 2,060,000 better and f_union_br gets 1,500 better. 
     161 
     162In anna, StrictAn6.$wsa, SmallerLattice.$w$sslDijkstra_aux, SmallerLattice.$w$sslDijkstra_unlink get worse (10,000, 400, 400). 
     163 
     164In parser, Main.leLex gets worse (5000). 
     165 
     166In gg, Graph.$wprintFloat gets worse (12 -> 84). 
     167 
     168Bigger swings in allocation (mostly good) took place in the programs themselves (eg transform.f_prmdef ~130,000 better, listcopy.f_se ~150,000 better). 
     169 
     170Many of the Core differences were of the following form. For example, see circsim's `put` function. When protecting the last argument from being removed by `WwLib.mkWorkerArgs`, the Core looks like this: 
     171 
     172{{{ 
     173let x :: RealWorld# -> ... 
     174    x = \_void -> let d = ... in Ctor(... d ...) (... d ...) ... 
     175in CTX[x] 
     176}}} 
     177 
     178Without protection, it looks like: 
     179 
     180{{{ 
     181let d = ... 
     182in CTX[Ctor(... d ...) (... d ...) ...] 
     183}}} 
     184 
     185Simon explained that it is probably the simplifier floating d out of the unprotected `x` binding *in order to reveal `x` as let-bound to a constructor*. Thus revealed, `x` is immediately inlined. Because of the `\_void`, this doesn't happen when the last argument is protected. 
     186 
     187With protection, `d` isn't allocated unless `x` is entered, which might not always happen in `CTX`. This is a potential win because `x` might be let-no-escape. 
     188 
     189A potential detriment of protection is that `x` is not exposed as a let-bound constructor. Simon conjectures that's not actually harmful because ... I CANNOT REMEMBER. 
    169190 
    170191===== Continuation =====