Changes between Version 9 and Version 10 of Frisby2013Q1

Timestamp:

02/12/13 06:24:06 (3 months ago)

Author:

nfrisby

Comment:

--

Frisby2013Q1

@@ -12 +12 @@
   * document ticky profiling
   * Core -> STG -> CMM and _what you can learn by looking at each one_
+  * let-no-escape (LNE)
 
 == Late Lambda Float ==
@@ -80 +81 @@
   * 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.
   * 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.
-  * Floating a binding in which a let-no-escape binder occurs abstracts over the let-no-escape binder, rendering it a normal let!
+  * Abstracting over a let-no-escape binder renders it a normal let, which increases allocation.
 
 ==== Mitigating PAP Creation ====
@@ -124 +125 @@
 Roughly, we expect that more floating means (barely) less allocation but worse runtime (by how much?) because some known calls become unknown calls.
 
-==== Abstracting over let-no-escapes ====
+==== Mitigating LNE Abstraction ====
 
 We 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.
 
-TODO: Mitigate it. First step: only make fast preservation apply to free variables that are known functions... duh!
+NB 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.
 
 In 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).
@@ -163 +164 @@
 13*60,000 ~ 750,000. I suspect the rest of sphere's increase is due to a similar issue in `GHC.IO.Handle`.
 
-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.
+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.
 
 === Discovered Benefits of LLF ===