Changes between Version 9 and Version 10 of Frisby2013Q1


Ignore:
Timestamp:
Feb 12, 2013 2:24:06 PM (14 months ago)
Author:
nfrisby
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Frisby2013Q1

    v9 v10  
    1212  * document ticky profiling 
    1313  * Core -> STG -> CMM and _what you can learn by looking at each one_ 
     14  * let-no-escape (LNE) 
    1415 
    1516== Late Lambda Float == 
     
    8081  * Abstracting over a known function might change a fast entry call in RHS to a slow entry call. For example, if CTX binds `a` to a lambda, that information is lost in the right-hand side of poly_f. This can increase runtime. 
    8182  * Replacing a floated binder's occurrence (ie `f` becomes `poly_f a b c`) can add free variables to a thunk's closure, which increases allocation. 
    82   * Floating a binding in which a let-no-escape binder occurs abstracts over the let-no-escape binder, rendering it a normal let! 
     83  * Abstracting over a let-no-escape binder renders it a normal let, which increases allocation. 
    8384 
    8485==== Mitigating PAP Creation ==== 
     
    124125Roughly, we expect that more floating means (barely) less allocation but worse runtime (by how much?) because some known calls become unknown calls. 
    125126 
    126 ==== Abstracting over let-no-escapes ==== 
     127==== Mitigating LNE Abstraction ==== 
    127128 
    128129We had actually already seen this for a non-lambda join point in knights, but we were preoccupied with the unintentional existence of non-lambda join points and moved on after fixing those. I re-discovered this while experimenting with the fast preservation variants above. 
    129130 
    130 TODO: Mitigate it. First step: only make fast preservation apply to free variables that are known functions... duh! 
     131NB I think this will be mitigated "for free", since I'm predicting that we will never abstract over saturated and oversaturated functions, which is all LNEs. If that's not the case, we may want to consider mitigating this separately. 
    131132 
    132133In fish (1.6%), hpg (~4.5%), and sphere (10.4%), allocation gets worse for ny and yy compared to nn and yn. The nn and ny do not change the allocation compared to the baseline library (ie no LLF). 
     
    16316413*60,000 ~ 750,000. I suspect the rest of sphere's increase is due to a similar issue in `GHC.IO.Handle`. 
    164165 
    165 In hpg, it's principally due to GHC`.IO.Encoding.UTF8` again, with a second place contributor of `GHC.IO.FD`, where the function `$wa17` is again like the `outer` example above, but with fewer free variables and thus less effect. 
     166In hpg, it's principally due to `GHC.IO.Encoding.UTF8` again, with a second place contributor of `GHC.IO.FD`, where the function `$wa17` is again like the `outer` example above, but with fewer free variables and thus less effect. 
    166167 
    167168=== Discovered Benefits of LLF ===