Design space

Design issue notes for Haskell MPI bindings.

Design goals

1. Support for dynamic sized types (eg recursively defined algebraic data types, such as lists, whose size is only known at runtime).
   • Emphasises convenience and safety over absolute performance.
   • May support a subset of all of the MPI communication functions.
2. Support for static sized data types (eg primitive types, and fixed size compounds, such as tuples with fixed size elements).
   • Emphasises performance over convenience and safety. For example, by avoiding data copying where possible.
   • Emphasises update-in-place where possible via mutable collections.
   • Tries to support all of the MPI communication functions, especially the collective ones.
3. Encourage idiomatic Haskell style.
   • May diverge from C API where necessary (break collectives into send and recv parts).
   • May have different arguments to functions, and in different order to maximise currying opportunity.
   • Try to use Haskell type system features where possible, such as distinguishing Rank and Tag from Int.
   • Try to be as general as possible with message types by overloading.

Note

The interface for dynamic sized types can also include types of static size (eg Ints). So a user may have to choose which approach is best for their needs.

Key implementation questions

1. What are the right collection types to use for collective communication functions?
2. What is the right way to overload message types?

Proposed technical solutions

1. Use Serializable class for message type representing dynamic sized types.
   • Use a persistent sequence type for collections of values (such as a list, or Data.Sequence or something overloaded).
2. Use Storable class for message type representing static sized types.
   • Use an array type for collections of values.

Open questions

1. What is the right way to overload the collection type for static sized types?
2. If we are using array types, do we want to support both mutable and immutable arrays?
   • Mutable arrays allow us to reuse previously allocated memory and are likely to be the most efficient solution, so they must be supported.
   • Destructive update is only needed for data being received. Send data is read only.
   • There could be three types of message collections: read only sent data, mutable received data, and immutable received data.