Composable scheduler activations for Haskell

Sivaramakrishnan, KC; Harris, Tim; Marlow, Simon; Jones, Simon Peyton

doi:10.1017/s0956796816000071

Cited by 5 publications

(4 citation statements)

References 37 publications

(67 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Moreover, unlike our approach, the Par-monad is restricted to shared memory parallelism. Two separate lightweight implementations of concurrent Haskell have also been produced that lift scheduling and other concurrency features to the Haskell level (Li et al, 2007;Sivaramakrishnan et al, 2013). This complements our work, that instead focuses on the introduction and control of parallelism.…”

Section: Scheduling Support In Haskellmentioning

confidence: 76%

PAEAN: Portable and scalable runtime support for parallel Haskell dialects

Berthold

Loidl²,

Hammond

2016

J. Funct. Prog.

View full text Add to dashboard Cite

Over time, several competing approaches to parallel Haskell programming have emerged. Different approaches support parallelism at various different scales, ranging from small multicores to massively parallel high-performance computing systems. They also provide varying degrees of control, ranging from completely implicit approaches to ones providing full programmer control. Most current designs assume a shared memory model at the programmer, implementation and hardware levels. This is, however, becoming increasingly divorced from the reality at the hardware level. It also imposes significant unwanted runtime overheads in the form of garbage collection synchronisation etc. What is needed is an easy way to abstract over the implementation and hardware levels, while presenting a simple parallelism model to the programmer.The PAEAN (PArallEl shAred Nothing) runtime system design aims to provide a portable and high-level shared-nothing implementation platform for parallel Haskell dialects. It abstracts over major issues such as work distribution and data serialisation, consolidating existing, successful designs into a single framework. It also provides an optional virtual shared-memory programming abstraction for (possibly) shared-nothing parallel machines, such as modern multicore/manycore architectures or cluster/cloud computing systems. It builds on, unifies, and extends, existing well-developed support for shared-memory parallelism that is provided by the widely-used GHC Haskell compiler. This paper summarises the state-of-the-art in shared-nothing parallel Haskell implementations, introduces the PAEAN abstractions, shows how they can be used to implement three distinct parallel Haskell dialects, and demonstrates that good scalability can be obtained on recent parallel machines. * Corresponding author. Reported work performed while at the University of Copenhagen (DIKU).

show abstract

Section: Scheduling Support In Haskellmentioning

confidence: 76%

PAEAN: Portable and scalable runtime support for parallel Haskell dialects

Berthold

Loidl²,

Hammond

2016

J. Funct. Prog.

View full text Add to dashboard Cite

show abstract

“…In Multicore OCaml, the user-level thread schedulers themselves are expressed as OCaml libraries, thus minimising the secret sauce that gets baked into high-performance multicore runtime systems [31]. This modular design allows the scheduling policy to be changed by swapping out the scheduler library for a different one with the same interface.…”

Section: Motivationmentioning

confidence: 99%

“…However, implementing these features in the runtime system warrants that the scheduler itself be part of the runtime system, which is incompatible with our goal of writing thread schedulers in OCaml. Attempts to lift the scheduler from the runtime system to a library in the high-level language while retaining other features in the runtime system lead to further complications [31].…”

Section: Motivationmentioning

confidence: 99%

Concurrent System Programming with Effect Handlers

Dolan

Eliopoulos²,

Hillerström

et al. 2018

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

Algebraic effects and their handlers have been steadily gaining attention as a programming language feature for composably expressing user-defined computational effects. While several prototype implementations of languages incorporating algebraic effects exist, Multicore OCaml incorporates effect handlers as the primary means of expressing concurrency in the language. In this paper, we make the observation that effect handlers can elegantly express particularly difficult programs that combine system programming and concurrency without compromising performance. Our experimental results on a highly concurrent and scalable web server demonstrate that effect handlers perform on par with highly optimised monadic concurrency libraries, while retaining the simplicity of direct-style code.

show abstract

“…There has been much interest in lightweight threading models ranging from using runtime managed thread pools such as those found in C# (C# Language Specification, 2014) and the java.util.concurrent package (Lea, 1999), to continuation-based systems found in functional languages such as Scheme (Mohr et al, 1990;Kranz et al, 1989), CML (Reppy, 2007), Haskell (Sivaramakrishnan et al, 2013;Harris et al, 2005), and Erlang (Armstrong et al, 1996). Parasitic threads can be viewed as a form of lightweight threading, though there are a number of key differences.…”

Section: Lightweight Threadsmentioning

confidence: 99%

MultiMLton: A multicore-aware runtime for standard ML

Sivaramakrishnan¹,

Ziarek²,

Jagannathan³

2014

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

MultiMLton is an extension of the MLton compiler and runtime system that targets scalable, multicore architectures. It provides specific support for ACML, a derivative of Concurrent ML that allows for the construction of composable asynchronous events. To effectively manage asynchrony, we require the runtime to efficiently handle potentially large numbers of lightweight, short-lived threads, many of which are created specifically to deal with the implicit concurrency introduced by asynchronous events. Scalability demands also dictate that the runtime minimize global coordination. MultiMLton therefore implements a split-heap memory manager that allows mutators and collectors running on different cores to operate mostly independently. More significantly, MultiMLton exploits the premise that there is a surfeit of available concurrency in ACML programs to realize a new collector design that completely eliminates the need for read barriers, a source of significant overhead in other managed runtimes. These two symbiotic features - a thread design specifically tailored to support asynchronous communication, and a memory manager that exploits lightweight concurrency to greatly reduce barrier overheads - are MultiMLton's key novelties. In this article, we describe the rationale, design, and implementation of these features, and provide experimental results over a range of parallel benchmarks and different multicore architectures including an 864 core Azul Vega 3, and a 48 core non-coherent Intel SCC (Single-Cloud Computer), that justify our design decisions.

show abstract

Composable scheduler activations for Haskell

Cited by 5 publications

References 37 publications

PAEAN: Portable and scalable runtime support for parallel Haskell dialects

PAEAN: Portable and scalable runtime support for parallel Haskell dialects

Concurrent System Programming with Effect Handlers

MultiMLton: A multicore-aware runtime for standard ML

Contact Info

Product

Resources

About