|
|
| Line 1: |
Line 1: |
| − | Often in data parallel HPC applications the programmer wishes to split up data in some way, shape or form. This is often a difficult task, as the programmer must consider issues such as synchronisation and uneven distributions. Mesham provides types to allow for the partitioning and distribution of data, the programmer needs just to specify the correct type and then behind the scenes the compiler will deal with all the complexity via the type system. It has been found that this approach works well, not just because it simplifies the program, but also because some of the (reusable) codes associated with parallelization types are designed beforehand by expert system programmers. These types tend be better optimized by experts than the codes written directly by the end programmers.
| + | <metadesc>Mesham is a type oriented programming language allowing the writing of high performance parallel codes which are efficient yet simple to write and maintain</metadesc> |
| | + | A major idea for extension is to allow the programmer to create their own language types. In the current version of the language the programmer can only create new types at the compiler level, this is not a major issue at the moment due to generality of the type library however it does limit the language somewhat. Whilst it is relatively simple to create new types in this way, one can not expect the programmer to have to modify the compiler in order to support the codes they wish to write. There are a number of issues to consider however in relation to this aim. |
| | | | |
| − | When the programmer partitions data, the compiler splits it up into blocks (an internal type of the compiler.) The location of these blocks depends on the distribution type used - it is possible for all the blocks to be located on one process, on a few or on all and if there are more blocks than processes they can always ``wrap around.'' The whole idea is that the programmer can refer to separate blocks without needing to worry about exactly where they are located, this means that it's very easy to change the distribution method to something more efficient later down the line if required.
| + | * How to implement this efficiently? |
| − | | + | * How to maximise static analysis and optimisation? |
| − | The programmer can think of two types of partitioning - partitioning for distribution and partitioning for viewing. The partition type located inside the allocated type is the partition for distribution (and also the default view of the data.) However, if the programmer wishes to change the way they are viewing the blocks of data, then a different partition type can be coerced. This will modify the view of the data, but NOT the underlying way that the data is allocated and distributed amongst the processes. Of course, it is important to avoid an ambiguous combination of partition types. In order to access a certain block of a partition, simply use array access [ ] i.e. ''a[3]'' will access the 3rd block of variable a.
| + | * How to minimise memory footprint? |
| − | | + | * The ideal way of structuring the programming interface? |
| − | In the code ''var a:array[Int,10,20] :: allocated[A[m] :: single[D[]]]'', the variable ''a'' is declared to be a 2d array size 10 by 20, using partition type A and splitting the data into ''m'' blocks. These blocks are distributed amongst the processes via distribution method ''D''.
| |
| − | | |
| − | In the code fragment ''a:(a::B[])'', the partition type ''B'' is coerced with the type of variable ''a'', and the view of the data changes from that of ''A'' to 'B''.
| |
| − | | |
| − | | |
| − | [[Category:Compound Types]]
| |
A major idea for extension is to allow the programmer to create their own language types. In the current version of the language the programmer can only create new types at the compiler level, this is not a major issue at the moment due to generality of the type library however it does limit the language somewhat. Whilst it is relatively simple to create new types in this way, one can not expect the programmer to have to modify the compiler in order to support the codes they wish to write. There are a number of issues to consider however in relation to this aim.
- How to implement this efficiently?
- How to maximise static analysis and optimisation?
- How to minimise memory footprint?
- The ideal way of structuring the programming interface?
