... | ... | @@ -29,10 +29,22 @@ GHC knows about DPH as follows. A single flag `-dph` switches on the following: |
|
|
|
|
|
- Adds `-package dph` (**SLPJ: correct?**), so that the user can `import Data.Array.Parallel`. And so that the right package gets linked in the link step.
|
|
|
|
|
|
- Runs a special pass called the **vectoriser**. This pass generates code that mentions (by Original Name) various functions defined in `dph-prim-seq` or `dph-prim-par` (depending on the compiler flag used). So if you change where a function is defined in `dph-prim-*`, or the name of the function, you have to make a corresponding change in GHC.
|
|
|
- Runs a special pass called the **vectoriser**. This generates a close coupling between the vectoriser and the library:
|
|
|
|
|
|
- The vectoriser generates code that mentions (by Original Name) various functions defined in `dph-prim-seq` or `dph-prim-par` (depending on the compiler flag used). So if you change where a function is defined in `dph-prim-*`, or the name of the function, you have to make a corresponding change in GHC.
|
|
|
- The vectoriser knows quite a lot about the internal working of the library. For instance, it knows about the array representation.
|
|
|
- Parts of the library are vectorised and since these are low-level parts, they rely on being vectorised in particular ways. This means that a particular version of the library will only work correctly with a particular version of the vectoriser and vice versa. **SLPJ: can you be more precise here? Which packages are vectorised? What do you meean by "particular ways"?**
|
|
|
|
|
|
**SLPJ: is it correct that GHC only generates Names in dph-prim? If not, could it be made true?**
|
|
|
|
|
|
## DPH and ways
|
|
|
|
|
|
|
|
|
When compiling a module with `-dph`, its imported modules must also have been compiled with `-dph`. It's a bit like profiling; so maybe compiling with `-dph` should count as another "way". This is an unresolved issue. Compiling the entire `base` package (say) with `-dph` might well be overkill; for example, we don't want to vectorise the IO library.
|
|
|
|
|
|
|
|
|
At the moment, we finesse this problem by simply requiring that the user solves it; and hence we do not use any `base` package functions in vectorised code.
|
|
|
|
|
|
## Array library of flat and segmented operations
|
|
|
|
|
|
**TODO** Here we need to document the structure of the current implementation with subpages for the more complicated aspects (e.g., representation types, distributed types, and gangs). |