Abstract. The paper introduces Self-Replicating Objects (SROs), a new concurrent programming abstraction. An SRO is implemented and used much like an ordinary.NET object and can expose arbitrary user-defined APIs, but it is aggressive about automatically exploiting multicore CPUs. It does so by spontaneously and transparently partitioning its state into a set of replicas that handle method calls in parallel and automatically merging replicas before processing calls that cannot execute in the replicated state. Developers need not be concerned about protecting access to shared data; each replica is a monitor and has its own state. The runtime ensures proper synchronization, scheduling, decides when to split/merge, and can transparently migrate replicas to other processes to decrease contention. Compared to threads/locks or toolkits such as.NET Parallel Extensions, SROs offer a simpler, more versatile programming model while delivering comparable, and in some cases even higher performance.

ing out and studying those patterns of computation as useful objects in their own right leads to further insights into the nature of computation. The list operators studied later in these notes follow this approach. ffl Functional programs are usually an order of magnitude more concise than their imperative counterparts. Besides being shorter, they can be much more readable. The functional community like to cite studies that show the number of bugs per line is more or less constant, independent of the level of the language in use. Higher-level languages encode more concept per line, and therefore have relatively fewer bugs. ffl Functional programs are often more akin to formal specifications than their conventional counterparts. A good notation goes a long way towards solving the problem[47]. ffl Lazy evaluation permits a new approach to some algorithms. It is a simple but powerful idea that can remove the need for explicit backtracking, and can allow the programmer to manipulate in...

This paper presents Haskell# , a parallel functional language based on coordination. Haskell# supports lazy stream communication and facilities, at coordination level, to the specification of data parallel programs. Haskell# supports a clean and complete, semantic and syntactic, separation between coordination and computation levels of programming, with several benefits to parallel program engineering. The implementation of some well-known applications in Haskell# is presented, demonstrating its expressiveness, allowing for elegant, simple, and concise specification of any static pattern of parallel, concurrent or distributed computation.

This paper presents Haskell#, a parallel functional language based on coordination. Haskell# supports lazy stream communication and facilities, at coordination level, to the specification of data parallel programs. Haskell# supports a clean and complete, semantic and syntactic, separation between coordination and computation levels of programming, with several benefits to parallel program engineering. The implementation of some well-known applications in Haskell# is presented, demonstrating its expressiveness, allowing for elegant, simple, and concise specification of any static pattern of parallel, concurrent or distributed computation.

In this paper, we present the parallelization of a sequential functional implementation of a Monte Carlo Transport Problem, called MCP- Haskell[Hammes et al., 1995], using Haskell# . This experiment gave us important feedback for evaluating Haskell# features, helping us to answer some questions, like how expressive is Haskell# for representing known parallel computational patterns, how easy it is to build large scale parallel programs in an elegant and concise way, and how efficient are Haskell# programs. Based on our conclusions, we suggest new features to be incorporated in Haskell# to improve its expressiveness and performance. We also present the performance figures for the MCP-Haskell# benchmark.