Changes between Version 7 and Version 8 of DataParallel/Vectorisation


Ignore:
Timestamp:
May 28, 2007 3:16:37 AM (8 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/Vectorisation

    v7 v8  
    1212NB: This is a significant departure from our earlier plan, where the original definition of a function `f` would be modified to call its vectorised variant `f_v` to do the actual work.  We changed our mind on this, as the new configuration appears to be simpler to implement. 
    1313 
    14 From the policy of unvectorised code never directly calling vectorised code, it follows that the `Main` module of a program needs to be compiled with vectorisation enabled if the program is to make any use of vectorised code at all.  Moreover, as `Main.main` is an `IO` function and we certainly don't want to vectorise the `IO` monad, vectorisation will need to ''partially vectorise'' expressions by vectorising any subexpressions it can vectorise in any expression that cannot be vectorised in its entirety.  Consider the following example: 
     14From the policy of unvectorised code never directly calling vectorised code, it follows that the `Main` module of a program needs to be compiled with vectorisation enabled if the program is to make any use of vectorised code at all.  Moreover, as `Main.main` is an `IO` function and we certainly don't want to vectorise the `IO` monad, vectorisation will need to ''partially vectorise'' expressions by vectorising any subexpressions it can vectorise in an expression that cannot be vectorised in its entirety.  Consider the following example: 
    1515{{{ 
    1616main :: IO () 
     
    2828We have to different array libraries: 
    2929 1. The library in `GHC.PArr`, which defines the wired in array constructor `[:.:]`.  It implements `[:.:]` as a parametric data type represented by vanilla boxed arrays.  It does not involve any type class and also no indexed types.  This code is used whenever arrays are mentioned in unvectorised code (i.e., in both all code of unvectorised modules and in the original versions of functions in vectorised modules). 
    30  2. The library in package ndp, which defines a type class `PA` and its associated data type `PArr`.   The type `PArr` implements a flattened array representation for all types `t` for which there is a `PA t` instance. 
     30 2. The library in package ndp, which defines a type class `PA` and its associated data type `PArr`.   The type family `PArr` implements a flattened array representation for all types `t` for which there is a `PA t` instance. 
    3131Vectorisation transforms all uses of functions from `GHC.PArr` into uses of package ndp.  It can obviously only do that for computations manipulating values for whose type we have `PA` instances. 
    3232 
     
    3434=== Basic data types === 
    3535 
    36 The following data types are the basis for our representation of arrays and closure in vectorised code. 
     36The following data types are the basis for our representation of arrays and closures in vectorised code. 
    3737 
    3838==== Indexed array family ==== 
     
    6868 
    6969---- 
    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 when we combine closure-conversion and vectorisation into one pass.  If that is correct, we can represent vectorised functions as 
     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 
    7171{{{ 
    7272data a ->> b = Fun { fun  :: !(     a ->      b)