In this paper we present an automated way of using spare CPU resources within a shared memory multi-processor or multi-core machine. Our approach is (i) to profile the execution of a program, (ii) from this to identify pieces of work which are promising sources of parallelism, (iii) recompile the program with this work being performed speculatively via a work-stealing system and then (iv) to detect at run-time any attempt to perform operations that would reveal the presence of speculation. We assess the practicality of the approach through an implementation based on GHC 6.6 along with a limit study based on the execution profiles we gathered. We support the full Concurrent Haskell language compiled with traditional optimizations and including I/O operations and synchronization as well as pure computation. We use 20 of the larger programs from the ‘nofib ’ benchmark suite. The limit study shows that programs vary a lot in the parallelism we can identify: some have none, 16 have a potential 2x speed-up, 4 have 32x. In practice, on a 4-core processor, we get 10-80 % speed-ups on 7 programs. This is mainly achieved at the addition of a second core rather than beyond this. This approach is therefore not a replacement for manual parallelization, but rather a way of squeezing extra performance out of the threads of an already-parallel program or out of a program that has not yet been parallelized.

Lazy programs are beautiful, but they are slow because they build many thunks. Simple measurements show that most of these thunks are unnecessary: they are in fact always evaluated, or are always cheap. In this paper we describe Optimistic Evaluation --- an evaluation strategy that exploits this observation. Optimistic Evaluation complements compile-time analyses with run-time experiments: it evaluates a thunk speculatively, but has an abortion mechanism to back out if it makes a bad choice. A run-time adaption mechanism records expressions found to be unsuitable for speculative evaluation, and arranges for them to be evaluated more lazily in the future.

Speculative multithreading is a promising technique for automatic parallelization. However, our experience with a software implementation indicates that there is significant overhead involved in managing the heap memory internal to the speculative system and significant complexity in correctly managing the call stack memory used by speculative tasks. We first describe a specialized heap management system that allows the data structures necessary to support speculation to be quickly recycled. We take advantage of constraints imposed by our speculation model to reduce the complexity of this otherwise general producer/consumer memory problem. We next provide a call stack abstraction that allows the local variable requirements of in-order and out-of-order nested method level speculation to be expressed and hence implemented in a relatively simple fashion. We believe that heap and stack memory management issues are important to efficient speculative system design. We also believe that abstractions such as ours help provide a framework for understanding the requirements of different speculation models. 1

This is the final report on the GRASP project, carried out under SERC grants GR/F34671 and GR/F98444, at Glasgow University 1 2 . The project supported two Principal Investigators (Simon Peyton Jones and Phil Wadler), and three Research Assistants (Kevin Hammond, Cordelia Hall and Will Partain). Four research students have worked in close association with the project. 1 Summary The purpose of GRASP was to help get the technology of functional programming out of the lab and into the hands of practitioners, by producing robust and usable compilers and profilers for these languages, on both sequential and parallel systems. The main achievements of the project are as follows: ffl We have played a key role in the development of a common international non-strict functional language, Haskell (Hudak et al. [1992]). This standardisation effort has led directly to a considerable focussing of the international research community in these languages. More details about Haskell are given in Sect...