| 1 | == Vectorisation: The lifted case example == |
| 2 | |
| 3 | This example is taken from http://www.cse.unsw.edu.au/~chak/papers/LCK06.html. |
| 4 | |
| 5 | == Flattening sums == |
| 6 | |
| 7 | We represent arrays of type |
| 8 | |
| 9 | {{{ |
| 10 | data Either a b = Left a | Right b |
| 11 | }}} |
| 12 | |
| 13 | essentially as |
| 14 | |
| 15 | {{{ |
| 16 | instance (ArrayElem a, ArrayElem b) => ArrayElem (Either a b) where |
| 17 | type [:Either a b:] = ([:Bool:], [:a:], [:b:]) |
| 18 | }}} |
| 19 | |
| 20 | For instance, `[:Left 5, Right 4, Left 2:]` will be represented by `([:True, False, True:], [:5,2:], [:4:])`. The boolean array (the ''selector'') indicates whether the corresponding element is a `Left` or a `Right` one; the actual data is stored in two separate arrays. |
| 21 | |
| 22 | == Case distinction (take 1) == |
| 23 | |
| 24 | For case distinction on `Either`, we have |
| 25 | |
| 26 | {{{ |
| 27 | either :: (a -> c) -> (b -> c) -> Either a b -> c |
| 28 | either f g (Left x) = f x |
| 29 | either f g (Right y) = g y |
| 30 | }}} |
| 31 | |
| 32 | The interesting question, of course, is how this works in a data-parallel context, i.e., what semantics something like `mapP (either f g) xs` has. For the moment, we assume that `[:a -> b:] = [:a:] -> [:b:]`. |
| 33 | |
| 34 | === Sometimes it works ... === |
| 35 | |
| 36 | Let us first consider |
| 37 | |
| 38 | {{{ |
| 39 | inc :: Int -> Int |
| 40 | inc n = n+1 |
| 41 | |
| 42 | good :: Either Int Int -> Int |
| 43 | good x = either inc id x |
| 44 | }}} |
| 45 | |
| 46 | The term `mapP good [:Left 5, Right 4, Left 2:]` translates to `good^ (EitherArr [:True, False, True:] [:5,2:] [:4:])`; to see how this is evaluated, we have to derive the lifted version of `good^`. This is easy (we ignore the tupling of functions here): |
| 47 | |
| 48 | {{{ |
| 49 | good^ :: [:Either Int Int:] -> [:Int:] |
| 50 | good^ xs = either^ inc^ id^ xs |
| 51 | }}} |
| 52 | |
| 53 | We need the lifted versions of `either`, `inc` and `id`. The latter is trivial: |
| 54 | |
| 55 | {{{ |
| 56 | id :: a -> a |
| 57 | id x = x |
| 58 | |
| 59 | id^ :: [:a:] -> [:a:] |
| 60 | id^ xs = xs |
| 61 | }}} |
| 62 | |
| 63 | We will omit the definition of `inc^` - it just increments every element in an array. The definition of `either^` is easily derived from its type: |
| 64 | |
| 65 | {{{ |
| 66 | either^ :: ([:a -> c:]) -> ([:b -> c:]) -> [:Either a b:] -> [:c:] |
| 67 | :: ([:a:] -> [:c:]) -> ([:b:] -> [:c:]) -> ([:Bool:], [:a:], [:b:]) -> [:c:] -- assuming [:a -> b:] = [:a:] -> [:b:] |
| 68 | either^ f g (bs, xs, ys) = combineP bs (f xs) (g ys) |
| 69 | }}} |
| 70 | |
| 71 | Here, we apply `f` and `g` to the respective data arrays and the combine the results according to the selector. For instance, we have |
| 72 | |
| 73 | {{{ |
| 74 | combineP [:True, False, True:] [:6,3:] [:4:] = [:6,4,3:] |
| 75 | }}} |
| 76 | |
| 77 | and therefore |
| 78 | |
| 79 | {{{ |
| 80 | mapP good [:Left 5, Right 4, Left 2:] |
| 81 | = good^ ([:True, False, True:], [:5,2:], [:4:]) |
| 82 | = either^ inc^ id^ ([:True, False, True:], [:5,2:], [:4:]) |
| 83 | = combineP [:True, False, True:] (inc^ [:5,2:]) (id^ [:4:]) |
| 84 | = combineP [:True, False, True:] [:6,3:] [:4:] |
| 85 | = [:6,4,3:] |
| 86 | }}} |
| 87 | |
| 88 | This is precisely the expected result. |
| 89 | |
| 90 | === ... but sometimes it doesn't === |
| 91 | |
| 92 | Now, let us consider a slightly more complex function: |
| 93 | |
| 94 | {{{ |
| 95 | bad :: (Either Int Int, Int) -> Int |
| 96 | bad x = either ((+) (snd x)) id (fst x) |
| 97 | }}} |
| 98 | |
| 99 | Again, we derive the lifted version of `bad`: |
| 100 | |
| 101 | {{{ |
| 102 | bad^ :: [:(Either Int Int, Int):] -> [:Int:] |
| 103 | bad^ xs = either^ ((+^) (snd^ x)) id^ (fst^ x) |
| 104 | }}} |
| 105 | |
| 106 | So, how is `mapP bad [:(Left 5, 1), (Right 4, 3), (Left 2, 7):]` evaluated? We have |
| 107 | |
| 108 | {{{ |
| 109 | mapP bad [:(Left 5, 1), (Right 4, 3), (Left 2, 7):] |
| 110 | = bad^ [:(Left 5, 1), (Right 4, 3), (Left 2, 7):] |
| 111 | = either^ ((+^) [:1,3,7:]) id^ [:Left 5, Right 4, Left 2:] |
| 112 | = either^ ((+^) [:1,3,7:]) id^ ([:True,False,True:], [:5,2:], [:4:]) |
| 113 | = combineP [:True,False,True:] ((+^) [:1,3,7:] [:5,2:]) (id^ [:4:]) |
| 114 | }}} |
| 115 | |
| 116 | This program diverges when trying to evaluate `(+^) [:1,3,7:] [:5,2:]` since `(+^)` only works with arrays of the same length. Note that it is not enough to just throw away the last element of the first array like Haskell's `zipWith` would do; we really want to evaluate `(+^) [:1,7:] [:5,2:]`, i.e. throw away the 3. |
| 117 | |
| 118 | == Case distinction (take 2) == |
| 119 | |
| 120 | So why doesn't it work? Simply because our definition of `either^` is wrong. In `either^ ((+^) [:1,3,7:]) id^ ([:True,False,True:], [:5,2:], [:4:])` two function arguments each contain one computation for ''each'' element of the `Either` array; it is the job of `either^` (and of case distinction in general) to select those which really should be applied. In particular, `either^` should filter the function arguments according to the selector. Without assuming `[:a -> b:] = [:a:] -> [:b:]`, it has the type |
| 121 | |
| 122 | {{{ |
| 123 | either^ :: [:a -> c:] -> [:b -> c:] -> [:Either a b:] -> [:c:] |
| 124 | }}} |
| 125 | |
| 126 | The real type is actually `[:a -> c:] -> [:(b -> c) -> Either a b -> c:]` but this is not important at the moment. So, `either^` has three array parameters; and since it is a lifted function, these arrays ''must have the same length''. The correct definition is |
| 127 | |
| 128 | {{{ |
| 129 | either^ fs gs (bs, xs, ys) = let fs' = packP bs fs |
| 130 | gs' = packP (not^ bs) gs |
| 131 | xs' = fs' $^ xs |
| 132 | ys' = gs' $^ ys |
| 133 | in |
| 134 | combineP bs xs' ys' |
| 135 | }}} |
| 136 | |
| 137 | Here, `$^` denotes the elementwise application of an array of functions to an array of arguments; `packP` filters an array according to a selector. |
| 138 | |
| 139 | Let us see how this works out for our example. Now, the type of `(+^)` is |
| 140 | |
| 141 | {{{ |
| 142 | (+^) :: [:Int:] -> [:Int -> Int:] |
| 143 | }}} |
| 144 | |
| 145 | and we will denote the result of `f^ [:x1, ..., xn:]` by `[:f x1, ..., f xn:]`. Moreover, `bad^` should really be defined as |
| 146 | |
| 147 | {{{ |
| 148 | bad^ :: [:(Either Int Int, Int):] -> [:Int:] |
| 149 | bad^ xs = either^ ((+^) (snd^ x)) (replicateP (lengthP xs) id) (fst^ x) |
| 150 | }}} |
| 151 | |
| 152 | Note that where we previously lifted `id` to `id^`, we now ''replicate'' it to get a function array. Then, we have |
| 153 | |
| 154 | {{{ |
| 155 | mapP bad [:(Left 5, 1), (Right 4, 3), (Left 2, 7):] |
| 156 | = bad^ [:(Left 5, 1), (Right 4, 3), (Left 2, 7):] |
| 157 | = either^ ((+^) [:1,3,7:]) (replicateP 3 id) [:Left 5, Right 4, Left 2:] |
| 158 | = either^ [:(+) 1, (+) 3, (+) 7:] [:id, id, id:] ([:True,False,True:], [:5,2:], [:4:]) |
| 159 | = let fs' = packP [:True,False,True:] [:(+) 1, (+) 3, (+) 7:] |
| 160 | gs' = packP [:False,True,False:] [:id,id,id:] |
| 161 | xs' = fs' $^ [:5,2:] |
| 162 | ys' = gs' $^ [:4:] |
| 163 | in |
| 164 | combineP [:True,False,True:] xs' ys' |
| 165 | = let fs' = [:(+) 1, (+) 7:] |
| 166 | gs' = [:id:] |
| 167 | xs' = fs' $^ [:5,2:] |
| 168 | ys' = gs' $^ [:4:] |
| 169 | in |
| 170 | combineP [:True,False,True:] xs' ys' |
| 171 | = let xs' = [:(+) 1, (+) 7:] $^ [:5,2:] |
| 172 | ys' = [:id:] $^ [:4:] |
| 173 | in |
| 174 | combineP [:True,False,True:] xs' ys' |
| 175 | = combineP [:True,False,True:] [:6,9:] [:4:] |
| 176 | = [:6,4,9:] |
| 177 | }}} |
| 178 | |
| 179 | This gives us the correct result. |
| 180 | |
| 181 | == Arrays of functions == |
| 182 | |
| 183 | The crucial mistake in our first approach was to assume that arrays of functions can be represented by functions over arrays. This does not work because the latter do not (and cannot) support array operations. Unfortunately, it is not enough to simply forbid `[:a -> b:]` as the transformation introduces such types and sometimes needs to manipulate these arrays (as in `packP` above - `either^` is just an example of how we would translate `case` expressions). |
| 184 | |
| 185 | So why can't we just use boxed arrays of functions? First, this kills performance. The main reason, however, is that this would break the semantics of the data-parallel model. The flattening transformation ensures that in the parallel case, all processes essentially execute the same code at the same time. This gives us very strong semantic guarantees; in particular, we can use collective operations for communication and synchronisation. This would not be the case if we could run unlifted code in a lifted context, which is necessarily the case with boxed function arrays. Explicit closures seem to be the only solution to this problem. |