. A parallel version of the LOLITA natural language engineering system is under construction. We believe that, at 47,000 lines of Haskell, LOLITA is the largest non-strict parallel functional program ever. In this paper we report on the ongoing parallelisation of LOLITA, which has the following interesting features common to real world applications of lazy languages: -- the code was not specifically designed for parallelism; -- laziness is essential for the efficiency in LOLITA; -- LOLITA interfaces to data structures outside the Haskell heap, using a foreign language interface; -- LOLITA was not written by those most closely involved in the parallelisation. Our expectations in parallelising the program were to achieve moderate speedups with small changes in the code. To date speedups of up to 2.4 have been achieved for LOLITA running under a realistic simulation of our 4 processor shared-memory target machine. We are currently tuning the program on the Sun SPARCserver ta...

The research presented in this thesis is about the design and implementation of Naira, a parallel, parallelising compiler for a rich, purely functional programming language. The source language of the compiler is a subset of Haskell 1.2. The front end of Naira is written entirely in the Haskell subset being compiled. Naira has been successfully parallelised and it is the largest successfully parallelised Haskell program having achieved good absolute speedups on a network of SUN workstations. Having the same basic structure as other production compilers of functional languages, Naira's parallelisation technology should carry forward to other functional language compilers. The back end of Naira is written in C and generates parallel code in the C language which is envisioned to be run on distributed-memory machines. The code generator is based on a novel compilation scheme specified using a restricted form of Milner's ß-calculus which achieves asynchronous communication. We present the f...

. This paper discusses the parallelisation and performance tuning of a typical computer algebra algorithm, LinSolv, using evaluation strategies. We present three steps in the parallelisation process starting with a naive parallel version. As this algorithm uses infinite data structures as intermediate values it is necessary to define very sophisticated strategies in order to improve parallel performance. We also compare the strategic parallel code with pre-strategy code. This comparison shows how evaluation strategies help to localise changes needed for parallelisation. In particular, the separation between algorithmic and parallel code makes the structure of the parallelism much clearer. 1 Introduction Tuning the performance of a parallel algorithm can be a long, tiresome process. A parallel programming model should aid the programmer especially in this stage, allowing him to experiment with different patterns of parallel behaviour. Based on our experiences with developing p...

Abstract. This paper demonstrates that it is possible to obtain good, scalable parallel performance by coordinating multiple instances of unaltered sequential computational algebra systems in order to deliver a single parallel system. The paper presents the first substantial parallel performance results for SymGrid-Par, a system that orchestrates computational algebra components into a high-performance parallel application. We show that SymGrid-Par is capable of exploiting different parallel/multicore architectures without any change to the computational algebra component. Ultimately, our intention is to extend our system so that it is capable of orchestrating heterogeneous computations across a high-performance computational Grid. For now, we illustrate our approach with a single, unmodified production computational algebra system, GAP, running on two common commodity architectures — a homogeneous cluster and an eight-core system. Computational algebra applications are large, specialised, and symbolic, rather than the more commonly studied numerical applications. They also exhibit high levels of irregularity, and multiple levels of irregularity. We demonstrate that for three small but representative algebraic computations, good parallel speedup is possible relative to a sequential GAP system running on a single processor/core. We compare the performance of the orchestrated system with that of parGAP, an established parallel implementation of GAP, demonstrating

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...

In this article we propose a basic set of concurrency abstractions for Concurrent Haskell based on our experiences with various applications.