Results 1 -
3 of
3
Algorithm + Strategy = Parallelism
- JOURNAL OF FUNCTIONAL PROGRAMMING
, 1998
"... The process of writing large parallel programs is complicated by the need to specify both the parallel behaviour of the program and the algorithm that is to be used to compute its result. This paper introduces evaluation strategies, lazy higher-order functions that control the parallel evaluation of ..."
Abstract
-
Cited by 51 (18 self)
- Add to MetaCart
The process of writing large parallel programs is complicated by the need to specify both the parallel behaviour of the program and the algorithm that is to be used to compute its result. This paper introduces evaluation strategies, lazy higher-order functions that control the parallel evaluation of non-strict functional languages. Using evaluation strategies, it is possible to achieve a clean separation between algorithmic and behavioural code. The result is enhanced clarity and shorter parallel programs. Evaluation strategies are a very general concept: this paper shows how they can be used to model a wide range of commonly used programming paradigms, including divideand -conquer, pipeline parallelism, producer/consumer parallelism, and data-oriented parallelism. Because they are based on unrestricted higher-order functions, they can also capture irregular parallel structures. Evaluation strategies are not just of theoretical interest: they have evolved out of our experience in parallelising several large-scale applications, where they have proved invaluable in helping to manage the complexities of parallel behaviour. These applications are described in detail here. The largest application we have studied to date, Lolita, is a 60,000 line natural language parser. Initial results show that for these applications we can achieve acceptable parallel performance, while incurring minimal overhead for using evaluation strategies.
Towards an Operational Semantics for a Parallel Non-strict Functional Language
, 1998
"... . Parallel programs must describe both computation and coordination, i.e. what to compute and how to organize the computation. In functional languages equational reasoning is often used to reason about computation. In contrast, there have been many different coordination constructs for functional la ..."
Abstract
-
Cited by 7 (2 self)
- Add to MetaCart
. Parallel programs must describe both computation and coordination, i.e. what to compute and how to organize the computation. In functional languages equational reasoning is often used to reason about computation. In contrast, there have been many different coordination constructs for functional languages, and far less work on reasoning about coordination. We present an initial semantics for GpH, a small extension of the Haskell language, that allows us to reason about coordination. In particular we can reason about work, average parallelism and runtime. The semantics captures the notions of limited (physical) resources, the preservation of sharing, and speculative evaluation. We show a consistency result with Launchbury's well-known lazy semantics. 1 Introduction One of the advantages of declarative languages is that it is relatively easy to reason about the values computed by programs, this being attributable to their preservation of referential transparency. Indeed, within the fun...
An Operational Semantics for Parallel Lazy Evaluation
, 1998
"... Parallel (lazy) functional programs must describe both computation and coordination, i.e., what to compute and how to arrange the computation in parallel. The formal manipulation of the behaviours of such programs requires a semantics which accurately captures lazy evaluation, and the dependence of ..."
Abstract
- Add to MetaCart
Parallel (lazy) functional programs must describe both computation and coordination, i.e., what to compute and how to arrange the computation in parallel. The formal manipulation of the behaviours of such programs requires a semantics which accurately captures lazy evaluation, and the dependence of execution on the availability of (physical) resources. In this paper we present a lockstep semantics as a first step towards this goal which, we hope, will allow us to reason about the coordination in a lazy setting. Version History Version 0.44(110998): From a comment by David Crowe, changed normalisation so that use of new closure is correctly noted in seq and par Version 0.43: Included Clem's relationship to other work section. Otherwise, just a minor polish for IFL'98 Version 0.42: Considered, but left unimplemented, Clem's tri-partite heap system. Random, speculative evaluation of dead threads remains a problem of the system. Partitioned rules into sequential and parallel rules. Hop...

