Changes between Version 13 and Version 14 of DataParallel/Vectorisation


Ignore:
Timestamp:
May 29, 2007 6:58:36 AM (8 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/Vectorisation

    v13 v14  
    4949==== Vectorised functions ====
    5050
    51 Vectorised functions use an explicit closure representation:
    52 {{{
    53 data a :-> b
    54   = forall e.
    55       Cls { clsFun  :: !(e -> a -> b)
    56           , clsAFun :: !(PArr e -> PArr a -> PArr b)
    57           , clsEnv  :: e
    58           }
    59 }}}
    60 with basic closure construction and application as
    61 {{{
    62 lam :: (a -> b) -> (a :-> b)
    63 lam f = Cls (const f) (const (mapP f)) ()
     51For the moment, I am assuming that we only need to closure-convert lifted code, but not scalar code.  The rationale is that the closure representation is only needed to pack, merge, etc. array closures, which represent arrays of functions.
    6452
    65 ($:) :: (a :-> b) -> a -> b
    66 (Cls f _ e) $: x = f e x
    67 }}}
    68 
    69 ----
    70 '''TODO:''' Can't we actually omit the explicit closure representation for ''scalar'' closures?  We need it for array closures, so that we can, e.g., pack them, but I think we don't really need it for scalar closures given that we combine closure-conversion and vectorisation into one pass.  If that is correct, we can represent vectorised functions as
    71 {{{
    72 data a ->> b = Fun { fun  :: !(     a ->      b)
    73                    , afun :: !(PArr a -> PArr b)
    74                    }
    75 
    76 vect :: (a -> b) -> (a ->> b)
    77 vect f = Fun f (mapP f)
    78 }}}
    79 
    80 Hmm, thinking about this, a data type will get us into trouble with unboxed types, but we also can't use a type synonym, as we can have partial applications of function arrows.  So, we have to split this up.
    81 
    82 A data type to combine the scalar and lifted version of  a function:
     53A data type to combine the scalar and lifted version of  a function (i.e., a glorified strict pair):
    8354{{{
    8455data fS :|| fP = !fS :|| !fP
     
    9364}}}
    9465So, we have `(->_v) = (:->)`.  Note that the type arguments to `(:->)` will be vectorised types (not vanilla types).  Consequently, instances of `PA` and `PArr` need to be defined for vectorised types.
    95 ----
     66
     67Three questions may arise at this point:
     68 * Why don't we combine `(:||)` and `(:->)` into one data type?  Answer: This won't work for functions involving unboxed types; in particular, we cannot write `Int# :-> Int#` (this would lead to a kind error).
     69 * Do we really define the `PA` instances over the unvectorised types?  Answer: As `(->)` may be partially applied in the original program, we can have partial applications of `(->_v)`, and hence, of `(:->)`.  These may then be used to instantiate type constructor variables in converted types, where the type arguments will be vectorised.
     70 * Why don't we closure convert scalar code (to keeps things more orthogonal)?  Answers: (1) I think the transformations are simpler like this, as only lifting has to perform on-the-fly closure conversion; (2) the generated Core code is smaller; (3) flattening and the ndp library place considerable stress on the simplifier, so reducing this a bit seems a good strategy; and (4) I am far from sure that the current approach to handling functions manipulating unboxed types would work if we closure-converted scalar code.
    9671
    9772==== Lifted functions ====
     
    12095 * [wiki:DataParallel/Vectorisation/CodeLifting Code lifting] (`e^`): This converts operations on types `t` into operations on types `[:t:]`.
    12196
     97
    12298----
    12399
    124 ==== TODO ====
     100=== TODO ===
    125101
    126102Items that need to be addressed on the page:
    127  * Mixed use of the CC isomorphism strategy and a `PA` class for arrays.
    128103 * Introduction of `PA` dictionary arguments right after each big lambda in vectorised code.
    129  * Treatment of unboxed values and functions from `GHC.Prim`.
    130104 * Transformation schemata
    131105 * Examples
     106
     107
     108----
     109
     110=== Old Material ===
     111
     112==== Vectorised functions ====
     113
     114Vectorised functions use an explicit closure representation:
     115{{{
     116data a :-> b
     117  = forall e.
     118      Cls { clsFun  :: !(e -> a -> b)
     119          , clsAFun :: !(PArr e -> PArr a -> PArr b)
     120          , clsEnv  :: e
     121          }
     122}}}
     123with basic closure construction and application as
     124{{{
     125lam :: (a -> b) -> (a :-> b)
     126lam f = Cls (const f) (const (mapP f)) ()
     127
     128($:) :: (a :-> b) -> a -> b
     129(Cls f _ e) $: x = f e x
     130}}}