Changes between Version 20 and Version 21 of DataParallel/WorkPlan
- Mar 27, 2009 11:11:33 AM (8 years ago)
v20 v21 18 18 19 19 ''Roman'':: 20 '''Code blow up''', '''Generate boilerplate with TH''' & '''Recycling for joinD''' 20 '''Code blow up''', '''Generate boilerplate with TH''' & '''Recycling for joinD''' 21 21 – status: partly implemented, but still needs serious work 22 22 * We still don't have the code blow up under control. … … 41 41 * #2984 42 42 43 Category: ''Efficiency '' (improve scalability and/or baseline performance of generated code): 43 Category: ''Efficiency'' (improve scalability and/or baseline performance of generated code): 44 44 45 45 * '''Recycling for joinD:''' Use Roman's recycling optimisation (PADL'09) to avoid copying in `joinD`. … … 51 51 * '''Regular multi-dimensional arrays:''' Representing regular arrays by nested arrays is generally not efficient, but due to the current lack of fusion for segmented arrays that produce multiple arrays of different length (e.g., `filterSU :: (a -> Bool) -> SUArr a -> SUArr a`), matters are worse than one might think (e.g., when using a hierarchical matrix representation). Hence, we need direct support for regular, multi-dimensional arrays. 52 52 53 54 55 56 53 57 * '''Unlifted functions:''' For some scalar functions (especially numeric functions and functions operating on enumerations), it is easier to not lift them at all; rather than to lift them and then attempt to recover the original form with fusion and other optimisations. An example is the `SumSq` benchmark, where we have `sumP (mapP (\x -> x * x) [:1..n:]`. Here, we would rather not lift `\x -> x * x` at all. Roman implemented a very simple form of this idea (which works for `SumSq`). However, we would like this in a more general form, where named functions that remain unlifted are marked suitably, as clients of a function can only be unlifted if all functions it calls are already unlifted. How much does that tie in with '''Selective vectorisation'''? 58 59 60 61 54 62 55 63 * '''Replicate:''' Implement an extended array representation that uses an optimised representation for arrays that are the result of common forms of replication (i.e., due to free variables in lifted expressions). The optimised representation stores the data to be replicated and the replication count(s) instead of actually replicating the data. This also requires all functions consuming arrays to be adapted. ''Update:'' Since we have `INLINE CONLIKE`, we can handle `replicate` using rules as long as it gets close to its consumer during simplification. This makes the use of an extended array representation less important. We will delay it until we run into examples where its lack bites us significantly.