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.

Eden is a concurrent declarative language that aims at both the programming of reactive systems and parallel algorithms on distributed memory systems. In this paper, we explain the computation and coordination model of Eden. We show how lazy evaluation in the computation language is fruitfully combined with the coordination language that is specifically designed for multicomputers and that aims at maximum parallelism. The two-level structure of the programming language is reflected in its operational semantics, which is sketched shortly.

. Every now and then, a user of the Glasgow Haskell Compiler asks for a feature that requires specialised support from the storage manager. Memo functions, pointer equality, external pointers, nalizers, and weak pointers, are all examples. We take memo functions as our exemplar because they turn out to be the trickiest to support. We present no fewer than four distinct mechanisms that are needed to support memo tables, and that (in various combinations) satisfy a variety of other needs. The resulting set of primitives is undoubtedly powerful and useful. Whether they are too powerful is not yet clear. While the focus of our discussion is on Haskell, there is nothing Haskell-specic about most of the primitives, which could readily be used in other settings. 1 Introduction \Given an arbitrary function f, construct a memoised version of f; that is, construct a new function with the property that it returns exactly the same results as f, but if it is applied a second time to ...

. The explicitly parallel programming language Eden adds a coordination level to the lazy functional language Haskell. This paper describes how a compiler and runtime system for Eden can incrementally be built on the basis of a compiler and runtime system for the computation language. The modifications needed in the compiler are restricted to specific orthogonal extensions. We show that Eden's design for distributed memory systems proves beneficial for the construction of a lean parallel runtime system. 1 Introduction Due to the side effect freedom of the reduction semantics of functional languages it is possible to evaluate independent subexpressions in arbitrary order or in parallel. This implicit parallelism is semantically transparent and allows the automatic parallelization of functional programs. In available parallel functional systems like the Glasgow parallel Haskell (GpH) system [17] or the Nijmegen CLEAN system [19] the programmer is asked to place annotations in programs. ...

Purely functional programs should run well on parallel hardware because of the absence of side effects, but it has proved hard to realise this potential in practice. Plenty of papers describe promising ideas, but vastly fewer describe real implementations with good wall-clock performance. We describe just such an implementation, and quantitatively explore some of the complex design tradeoffs that make such implementations hard to build. Our measurements are necessarily detailed and specific, but they are reproducible, and we believe that they offer some general insights. 1.

This paper discusses an extension of Haskell by support for nested data-parallel programming in the style of the special-purpose language Nesl. More precisely, the extension consists of a parallel array type, array comprehensions, and a set of primitive parallel array operations. This extension brings a hitherto unsupported style of parallel programming to Haskell. Moreover, nested data parallelism should receive wider attention when available in a standardised language like Haskell. This paper outlines the language extension and demonstrates its usefulness with two case studies.

Abstract. Computational Grids potentially offer cheap large-scale high-performance systems, but are a very challenging architecture, being heterogeneous, shared and hierarchical. Rather than requiring a programmer to explicitly manage this complex environment, we recommend using a high-level parallel functional language, like GpH, with largely automatic management of parallel coordination. We present GRID-GUM, an initial port of the distributed virtual shared-memory implementation of GpH for computational Grids. We show that, GRID-GUM delivers acceptable speedups on relatively low latency homogeneous and heterogeneous computational Grids. Moreover, we find that for heterogeneous computational Grids, load management limits performance. We present the initial design of GRID-GUM2, that incorporates new load management mechanisms that cheaply and effectively combine static and dynamic information to adapt to heterogeneous Grids. The mechanisms are evaluated by measuring four non-trivial programs with different parallel properties. The measurements show that the new mechanisms improve load distribution over the original implementation, reducing runtime by factors ranging from 17 % to 57%, and the greatest improvement is obtained for the most dynamic program.

. In the last three years we have been working with persistence and distribution, in particular migration of higher-level objects (such as procedures) between autonomous persistent programs. In this paper we introduce persistence and the suitability of Napier88 --- the persistent system we have used for our experiments --- as an agent language. We then present a few examples of opportunities and many more challenges that exist in the combination of persistence with agents. 1 Introduction The main motivation for this paper is our perception that free variables and persistence have not been properly addressed by the agent research community. Persistence is important because many of the examples presented in the agent literature include local or remote database access. Free variables are also of interest --- and unavoidable in a persistent environment --- because data and code are highly and strongly inter-connected in the persistent store. This paper is based on our experience with pers...

: We investigate two similar but contrasting parallel functional language designs: Eden and GPH. Both languages use the non-strict functional language Haskell as a core expression language, both are implemented as extensions of the high performance Glasgow Haskell Compiler (GHC), and both implementations are available on the same distributed architecture: a Beowulf cluster. This allows an exceptionally pure comparison of the language design characteristics and their impact on parallel performance. The comparison is illustrated by two parallel symbolic computation benchmarks which expose differences in the communication, process creation, and work distribution mechanisms employed by Eden and GPH. Our results show that the explicit process model favoured by Eden gives good parallel performance for coarse-grained applications running on the Beowulf cluster. In comparison, the current GPH implementation of implicit parallelism yields poorer absolute speedup for these two applications. Further work is needed to determine whether this difference is an implementation artefact or a consequence of the different models employed in each case, though excessively fine thread granularity appears to be a contributing factor. 1 Department of Computing and Electrical Engineering, Heriot-Watt University, Scotland; Email: {hwloidl,trinder}@cee.hw.ac.uk 2 Department of Computer Science, Marburg University, Germany; Email: {klusik,loogen}@mathematik.uni-marburg.de 3 School of Computer Science, University of St Andrews, Scotland; Email: kh@dcs.st-andrews.ac.uk 39 4.1

. Interrupt handling is a tricky business in lazy functional languages: we have to make sure that thunks that are being evaluated can be halted and later restarted if and when they are required. This is a particular problem for implementations which use black-holing. Black-Holing deliberately makes it impossible to revert such thunks to their original state to avoid a serious space leak. Interactive Haskell implementations such as Hugs and hbi catch interrupts and avoid the problem by omitting or disabling black-holing. Batch mode Haskell implementations such as HBC and the Glasgow Haskell Compiler (GHC) avoid this problem by disabling black-holing or by providing no way to catch interrupts. This paper describes a modification to GHC's abstract machine (the Spineless Tagless G-Machine) which simultaneously supports both interrupts and black-holing. 1 Introduction Black-Holing [6] is an important technique for avoiding space leaks in lazy functional languages. When a program starts to ...