Changes between Version 4 and Version 5 of DataParallel/Library

Timestamp:

02/10/11 19:50:59 (2 years ago)

Author:

chak

Comment:

--

DataParallel/Library

@@ -7 +7 @@
 DPH comes with the following blobs of source code:
 
-  * `dph/dph-prim-seq` implements the DPH Primitive Interface for sequential machines.  Compiling it yields package `dph-prim-seq`.
+  * `dph/dph-prim-seq` implements the DPH Primitive Interface for sequential machines.  Compiling it yields package `dph-prim-seq`.  It depends on the packages `vector` and `primitive`.
 
   * `dph/dph-prim-par` implements the DPH Primitive Interface for parallel machines.  Compiling it yields package `dph-prim-seq`.
@@ -21 +21 @@
 == How the DPH packages are coupled to GHC ==
 
-GHC knows about DPH as follows.  A single flag `-dph` switches on the following:
+GHC knows about DPH as follows.
 
-  * 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.
+  * The flags `-fdph-seq` and `-fdph-par` add `-package dph-seq` and `-package-dph-par`, respectively, so that the user can `import Data.Array.Parallel` and friends.  And so that the right package gets linked in the link step.
 
-  * Runs a special pass called the '''vectoriser'''.  This generates a close coupling between the vectoriser and the library:
+  * The flag `-fvectorise` runs a special pass called the '''vectoriser'''. 
     * 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.
@@ -31 +31 @@
 
 
-
 '''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).
+'''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).  Here a dump of an old description of the library structure (which may be somewhat out of date):
+{{{
+Data.Array.Parallel.Lifted
+        ... the final user types ...
+
+Data.Array.Parallel.Unlifted
+  Re-exports Data.Array.Parallel.Unlifted.Parallel
+             Data.Array.Parallel.Unlifted.Distributed
+             Data.Array.Parallel.Unlifted.Segmented
+             Data.Array.Parallel.Unlifted.Flat
+
+Data.Array.Parallel.Unlifted.Parallel
+  Parallel operations over UArrs.  No new data types!
+  These operations each
+        - convert the incoming (UArr t) to a Dist (UArr t)
+        - run the operation in parallel using a gang
+        - convert the result back to a (UArr t')
+  Plus fusion rules, of course!
+
+Data.Array.Parallel.Unlifted.Distributed
+  Logically: type Dist a = Array GangMember a
+        That is, one 'a' per gang member
+  Mutable version: MDist
+
+  Element types: unboxed, and products, (), 
+                 *and* UArr, SUArr, Segd.
+ 
+Data.Array.Parallel.Unlifted.Segmented
+  Provides SUArr, which are segmented UArrs with exactly one nesting level
+  Logically: type SUArr a = UArr (UArr a)
+  Element types: unboxed, and products and ().
+
+  Again, a mutable version MSUArr is defined internally.
+
+Data.Array.Parallel.Unlifted.Flat
+  Provides immutable (UArr) arrays of unboxed
+  values, and strict products thereof.
+
+  Simply lifts BUArr to work over strict products (incl unit).
+  Internally to Flat, we also define mutable (MUArr) arrays, 
+  but they aren't exported.
+
+        .UArr: representation
+        .Loop: main loop combinator over UArr, loopU
+        .Fusion: fusion rules for loopU
+        .Combinators: instantiate loopU (to get fold, scan, map etc)
+  
+  The exported maps and folds over these arrays are 
+  purely sequential
+
+Data.Array.Parallel.Arr.BUArr
+  Arrays of *unboxed* values, immutable (BUArr t) and mutable (MBUArr
+  t), indexed by Int.  Supports slicing (= sub-segment) operations.
+
+  ToDo: combine with UArray and STUArray? (But they are indexed by Ix.)
+
+  ToDo: a common pattern (e.g. when filtering) is that we allocate a
+  big mutable array, *partially* fill it, and then want to shrink to
+  fixed size when freezing it. (This is needed in Don's ByteString
+  library too.)
+
+
+Data.Array.Parallel.Base.Fusion
+  Specialised combining functions that specialise loopU to be map, fold, etc
+  They are also useful for loopBU; hence not in Unlifted.Flat
+  
+Data.Array.Parallel.Arr.BBArr
+  Similar to BUArr, but for strict, boxed values.  
+  Representation: Array, STArray.
+  Main application: array of UArrs in Distibuted.Types
+}}}