|Version 7 (modified by simonpj, 6 years ago) (diff)|
Regular, Multi-dimensional parallel Arrays
The nested parallel arrays of DPH could be used to model regular arrays, as we could simply either create segment information using replicate, or define regular arrays in terms of flat parallel arrays and separately stored dimensionality information, and define operations on these arrays in a library in terms of the nested operations. However, there are two main reasons why this is unsatisfactory: convenience and efficiency.
Languages like SAC, which provide high-level support for operations on multi-dimensional arrays, offer shape invariant operations. If we want to model this on a library level, we either have to give up type safety to a large extend (for example, by encoding the shape as a list of integer values whose length is proportionate to its dimensionality) or use sophisticated language features like GADTs, which may impede the usability of the library for inexperienced users.
When encoding multidimensional arrays using segment descriptors or by storing the dimensions separately. In the first case, this would mean significant memory overhead proportionate to the number of subarrays on each level. But even in the second case, segment descriptors have to be generated to call functions like segmented fold and scan. It is hard to predict the exact overhead for this step, as fusion might prevent the segment descriptor array to be actually built in many cases. More significant in terms of overhead is that, when using segment descriptors, parallel splits become significantly more complicated, as they require communication in the irregular case to determine the distribution, whereas the distributions of a regularly segmented array can be determined locally on each processor.
The remainder of this document is a first design draft for SAC style language support of multidimensional arrays in the context of DPH. The implementation is not completed yet, and there are several open questions.
SLPJ: perhaps early give some SAC examples and the corresponding code for us.
The regular array type
Regular parallel arrays are similar to arrays in SAC, with one major difference: array operations in DPH are fully typed, and consequently, what is called 'shape invariant programming' in SAC works differently in DPH. In particular, the dimensionality of an array (not its size, however) are encoded in its type. SLPJ: unlike SAC, where functions can be polymorphic even in the dimensionality of the array?
An multidimensional array is parametrised with its dimensionality and its element type:
(Ix (Shape dim), Elt a) => Array dim a
where IX is the standard Haskell index class, Shape is a type family defined on tuples of integers, including nullary tuples - arrays of which correspond to scalar values. So, for example
Array () Double -- scalar double precision floating point value Array (3,2) Double -- two dimensional array (matrix) of three rows, two columns
SLPJ: urk. Is (2,3) a type?! Or did you mean Array (Int,Int) Double?
Internally, shapes are represented as nested pairs
type family Shape dim type instance Shape () = () type instance Shape (Int) = ((),Int) type instance Shape (Int, Int) = (((),Int), Int)
Elements types are restricted to the element type of flat parallel arrays, that it, primitive types like integers, boolean and floating point numbers, and tuples. SLPJ: so what is in class Elt?
A new array can be created from a flat parallel array
fromNArray:: U.Elt r => U.Array r -> Array DIM1 r
SLPJ: what is U? What is U.Array? and from scalar values:
fromScalar:: U.Elt r => r -> Array DIM0 r
SLPJ: whoa! What are DIM1, DIM0? Presumably you mean 1-dimensional etc. But indexed by what? Always Int? Maybe that's ok; but say so. and bpermuteR, which creates a new array of new shape, using values of the argument array.
bpermuteR:: Array dim e -> Shape dim' -> (Shape dim' -> Shape dim) -> Array dim'
For example, transposition of a two dimensional array can be defined in terms of mkArray as follows SLPJ: in terms of bpermuteR perhaps?:
transpose:: Array DIM2 a -> Array DIM2 a transpose arr = bpermuteR arr (n,m) (\(i,j) -> (j,i)) where (n,m) = shape arr
SLPJ: presumably shape :: Array dim a -> Shape dim? Or perhaps rather shape :: Array dim a -> dim?. SLPJ: did you mean bpermuteR arr (m,n)? Or cutting a 3 x 3 tile starting at indices (0,0) out of a two dimensional matrix:
tile:: Array DIM2 a -> Array DIM2 a tile arr = bpermuteR arr (3,3) id
SLPJ: Does the Shape stuff need to be exposed at this level. Could we not work just in terms of the (Int,Int) indices the programmer expects, and hide the shapery?
Manipulating array values
All the shape invariant operations available on parallel arrays are also defined on regular arrays:
map :: (Elt a, Elt b) => (a -> b) -> Array dim a -> Array dim b zipWith :: (Elt a, Elt b, Elt c) => (a -> b -> c) -> Array dim a -> Array dim b -> Array dim c
Parallel array operations which can change the shape are restricted to one dimensional arrays, to make sure that the result is still a regular array.
filter :: Elt a => (a -> Bool) -> Array DIM1 a -> Array DIM1 a scan :: Elt a => ((a, a) -> a) -- combination function -> a -- default value -> Array (dim, Int) a -- linear array -> (Array dim a, Array (dim, Int) a)
SLPJ: didn't understand scan. Manipulating the shape of arrays:
-- size of both shapes have to be the same, otherwise runtime error reshape ::(Ix (Shape dim), Ix (Shape dim')) => (Shape dim) -- new shape -> Array dim' a -- array to be reshaped -> Array dim a
SLPJ: why doesn't reshape need the size of the result array, as bpermuteR did.
Changing the dimensionality of an array
The index type
Two operations we provide change the dimensionality of an argument array, namely the generalised indexing function, which extracts subarrays from an multidimensional array, and generalised replicate, which expands the array along specified axes. To encode the relationship between the argument's dimensionality and the result's dimensionality, we use the Index type:
(!) :: Elt e => Arr dim e -> Index dim dim' -> Arr dim' e replicate :: Index dim' dim -- ^specifies new dimensions -> Array dim a -- ^data to be replicated -> Array dim' a
where Index is defined as
data Index initialDim projectedDim where IndexNil :: Index () () IndexAll :: Index init proj -> Index (init, Int) (proj, Int) IndexFixed :: Int -> Index init proj -> Index (init, Int) proj
The index type is similar to generalized selection in SaC. For example, the selection vector
which indexes the fourth element in the third subarray of the second matrix in a three dimensional array would correspond to the index value
IndexFixed 1 (IndexFixed 2 (IndexFixed 3 IndexNil)) :: Index ((((),Int), Int),,Int) ()
Where the type tells us that the index value describes a projection from a three dimensional array to a scalar value. More interestingly, the SaC selection
specifies a subvector (i.e., all the values in position (1,i,3) for all i's in the arrays range. This corresponds to
IndexFixed 1 (IndexAll (IndexFixed 3 IndexNil)):: Index ((((),Int), Int),,Int) ((),Int)
To demonstrate the use of the Index type, consider the following replicates expressed in terms of generalised replicate:
-- 'chunk replicate' - create a two dimensional array by replicating the one dimensional -- argument array n times replicateC:: Int -> Array DIM1 a -> Array DIM2 a replicateC n arr = RArray.replicate (IndexFixed n (IndexAll IndexNil)) arr -- create a two dimensional array by replicating each element n times -- 'replicateLifted' replicateL:: Int -> Array DIM1 a -> Array DIM2 a replicateL n arr = RArray.replicate (IndexAll (IndexFixed n IndexNil)) arr -- 'chunkreplicate' on a two dimensional array -- replicateC2:: Int -> Array DIM2 a -> Array DIM3 a replicateC2 n arr = RArray.replicate (IndexFixed n (IndexAll (IndexAll IndexNil))) arr replicateLL:: Int -> Array DIM2 a -> Array DIM3 a replicateLL n arr = RArray.replicate (IndexAll (IndexAll (IndexFixed n IndexNil))) arr
In the actual array language (user level) the DPH should provide a general selection-like notation for index expressions.
Comparison with SaC
We started out with the goal to provide support for SaC like array programming. In this section compares SaC's functionality with the approach described in this document.