Costs, Transformations, and Parallel Programming

David Skillicorn

A programming model cannot be useful for designing programs unless it possesses a transformation system. A transformation system is not useful unless it possesses a cost model. A cost model maps functions to program texts (that is, implicit implementations) and transformation rules to rewrite rules.

It is useful to consider what we might expect of a cost-based transformation system. There are two properties of interest. The first is the degree of confluence. A rewriting system may be confluent, simply confluent (on components of programs), directed, or without costs altogether. The second property of interest is convexity: it is not possible to increase the cost of a piece of a program to decrease the cost of the whole.

Neither convexity or some degree of confluence are easy to get for parallel systems. Convexity is usually destroyed by congestion phenomena. It is possible to get a directed convex transformation system for homomorphic skeletons by the following process: start from a small fixed set of skeletons, form all short compositions, define a new skeleton for each composition with a cheaper than expected implementation, and add the defining equation as a new rewrite rule. It also seems possible to get simply confluent rewrite systems using variants of BSP such as miniBSP.