... | ... | @@ -27,7 +27,7 @@ In general, fusion in GHC relies on the rewrite rules and the inliner. |
|
|
The problem with this scheme is that it involves two phases of heuristics (rules and inliner), and in practice programmers have difficulties to predict the performance of any given program.
|
|
|
|
|
|
|
|
|
A partial remedy to this solution is to stop relying on rewrite rules, and use directly non-recursive representations. For example the following representation from Lippmeier et al.:
|
|
|
A partial remedy to this solution is to stop relying on rewrite rules, and use directly non-recursive representations. For example the following representation from Lippmeier et al. [ http://benl.ouroborus.net/papers/2016-polarized/dpdf-FHPC2016-preprint.pdf](http://benl.ouroborus.net/papers/2016-polarized/dpdf-FHPC2016-preprint.pdf):
|
|
|
|
|
|
```
|
|
|
dataSources i m e =Sources-- 'i' is the array's index type, 'e' the type of elements and 'm' the effects{ arity :: i
|
... | ... | @@ -36,7 +36,7 @@ dataSources i m e =Sources-- 'i' is the array's index type, 'e' the type of elem |
|
|
```
|
|
|
|
|
|
|
|
|
Such representations are typically functionals, and thus do not consume memory. One eventually gets code which is guaranteed to be 'fused'. For instance, in the following example from Lippmeier et al. [ http://benl.ouroborus.net/papers/2016-polarized/dpdf-FHPC2016-preprint.pdf](http://benl.ouroborus.net/papers/2016-polarized/dpdf-FHPC2016-preprint.pdf), neither the source nor the sink represent data in memory.
|
|
|
Such representations are typically functionals, and thus do not consume memory. One eventually gets code which is guaranteed to be 'fused'. For instance, in the following example from Lippmeier et al., neither the source nor the sink represent data in memory.
|
|
|
|
|
|
```
|
|
|
copySetP::[FilePath]->[FilePath]->IO()copySetP srcs dsts =do
|
... | ... | |