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}}}